octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool and mkoctfile


From: John W. Eaton
Subject: Re: libtool and mkoctfile
Date: Wed, 4 Nov 2009 17:07:37 -0500

On  4-Nov-2009, Benjamin Lindner wrote:

| With all due respect, but at this point I'd like to re-raise the 
| question, why are you trying to switch to libtool in the first
| place?

In part because it makes it simpler to use gnulib, and I think that
replacing parts of Octave with gnulib equivalents will be helpful and
make Octave more portable and more reliable.

| What's so complex about compiling a source file and linking a library 
| supposing for simplicity one is using the gnu compiler/linker suite? 

If we were only using GCC on say, GNU/Linux x86 systems, the task
would be far simpler.  But we are not, and I think using libtool is
better than rediscovering all the possible options and methods for
building share libraries on all the systems Octave can run on.

| (Does libtool even support different compilers?)

Yes.  One of the points of libtool is to hide the complexity of
building shared libraries on different systems.

| You have to tell libtool which additional libraries to link to, you have 
| to tell libtool which {C|CPP|CXX|LD}FLAGS to use,

The only options I think that you need to specify are the -L, -I, and
-l options (i.e., where are the header files and libraries, and what
are the names of the libraries).  You don't have to know whether the
compiler taks +Z or -fPIC or -Bshareable or -bundle -bundle_loader
or wether the libraries are named .dll or .so or .sl or whatever.
Libtool hides all of those details.  I think that's a good thing.

| you end up with makefile rules which are fairly more complex and hard to 
|   reason.

But I shouldn't need to look at those because they are generated by
automake.  The files I edit are the input files for automake, which
are somewhat simpler.

| don't need to lo
| Besides, did you actually take a look at the code in libtool?
| I find it utterly confusing, complex, hard to understand and even harder 
| to use. If I compare it to octave's current makefiles, then these are 
| much cleaner, clearer and easier to adapt and maintain. They do not 
| require any of the confusing logic embedded in libtool. And - most 
| important of all - they work!

I'm sorry that you have such a negative attitude about this change.

I have offered to help with the transition, but to do that, I will
need some precise instructions about how to construct the same build
environment that you have on a Windows system.  So far, no one has
posted any instructions that would help me do that, or pointed me to
an existing document that clearly describes how to build Octave on a
Windows system.

| Libtool actually complicates matters, not simplifies them.

>From my point of view, it does simplify things, because it will allow
us to remove some fragile code from Octave's configuration script.

| The mingw port of the gnu compiler is resposible for taking care of 
| providing the correct flags to GNU ld, collecting the right crt 
| libraries and system-specific object files.

All the compiler front ends I know of do this job.

| There is no extra compiler flag necesary to build a shared library, and 
| there is no extra link flag execpt for "-shared". The gcc/binutils suite 
|   does a good job at this.

Yet we still have

  *-*-mingw*)
    CPICFLAG=
    CXXPICFLAG=
    FPICFLAG=
    SHLEXT=dll
    SHLLIB=dll.a
    SHLBIN=dll
    DL_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import 
-Wl,--enable-runtime-pseudo-reloc"
    SH_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import 
-Wl,--enable-auto-image-base"
    SONAME_FLAGS='-Wl,address@hidden'
    library_path_var=PATH
    SCRIPTS_EXE_SUFFIX='$(EXEEXT)'
  ;;

and 

  *-*-msdosmsvc)
    DL_LDFLAGS="-shared"
    CPICFLAG=
    CXXPICFLAG=
    FPICFLAG=
    SHLEXT=dll
    SHLLIB=lib
    SHLBIN=dll
    LIBPRE=
    SHLPRE=
    SHLLIBPRE=
    SHLBINPRE=
    SH_LDFLAGS="-shared"
      if test -n "`echo $CFLAGS | grep -e '-g'`" -o -n "`echo $CXXFLAGS | grep 
-e '-g'`"; then
      DL_LDFLAGS="$DL_LDFLAGS -g"
      SH_LDFLAGS="$SH_LDFLAGS -g"
    fi
    NO_OCT_FILE_STRIP=true
    library_path_var=PATH
    NO_OCT_FILE_STRIP=true
    ## Extra compilation flags.
    CRUFT_DLL_DEFS="-DCRUFT_DLL"
    OCTAVE_DLL_DEFS="-DOCTAVE_DLL"
    OCTINTERP_DLL_DEFS="-DOCTINTERP_DLL"
    OCTGRAPHICS_DLL_DEFS="-DOCTGRAPHICS_DLL"
    SCRIPTS_EXE_SUFFIX='$(EXEEXT)'

in the Octave configure script.  All of this complexity would be gone.

In a recent message, you said that you were able to build some parts
of Octave with libtool, but that some things were still not working.
What is not working?

Again, I am willing to help with the transition, but I need to have
some precise directions for setting up a build environment that is the
same as yours so I can try to build Octave and see what the problems
are.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]