[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib and automake
From: |
John W. Eaton |
Subject: |
Re: gnulib and automake |
Date: |
Fri, 30 Oct 2009 15:22:25 -0400 |
On 30-Oct-2009, Benjamin Lindner wrote:
| On msys-1.0.11, with
|
| $ libtool --version
| libtool (GNU libtool 1.3110 2009-07-01) 2.2.7a
| $ autoconf --version
| autoconf (GNU Autoconf) 2.63
| $ automake --version
| automake (GNU automake) 1.11
|
| running ./autogen.sh completes without errors.
|
| I then tried to build with the current tip and ran into the following
| issues:
|
| gawk: /octmgw32/octave/octave-tip-automake/liboctave/mk-ops.awk:185:
| (FILENAME=/octmgw32/octave/octave-tip-automake/liboctave/mx-ops FNR=296)
| fatal: can't redirect to `mx-ui32nda-i8.cc' (Permission denied)
I have no idea why this would happen.
| starting "make" once again, then continued beyond this point, but then
nn| fails at
|
| rm -f DLD-FUNCTIONS/__contourc__.oct
| ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" <
| DLD-FUNCTIONS/lib__contourc__.la` DLD-FUNCTIONS/__contourc__.oct
| ln: creating symbolic link `DLD-FUNCTIONS/__contourc__.oct' to `.libs':
| No such file or directory
| make[3]: *** [DLD-FUNCTIONS/__contourc__.oct] Error 1
| make[3]: *** Waiting for unfinished jobs....
| libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32
| shared libraries
| make[3]: Leaving directory
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
| `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2'
| make: *** [all] Error 2
|
| This error persists when restarting "make".
|
| The next issue is that no shared libraries are built, only static ones,
| although octave is configured with "--enable-shared".
|
| Additionally, no .oct files are built, the directory DLD-FUNCTIONS/.libs
| only contains .o and .a files, no dlls.
|
| looking into the file DLD-FUNCTIONS/lib__contourc__.la, it reads
| "dlname=''", which would explain ln's commandline which fails with the
| above error.
That all makes sense if libtool was somehow told not to build shared
libraries. Maybe there is a problem with the way --enable-shared is
handled. We currently have the old AC_ARG_ENABLE for --enable-shared
AND the libtool macros in configure.ac. Maybe there is some conflict?
Since the default is to build shared libraries and not static
libraries, can you try running configure without any --enable-shared
--disable-static or --enable-dl options and see what happens? What
does the output from configure tell you about the configuration of
libtool? I would expect something like
...
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for dlfcn.h... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking how to run the C++ preprocessor... g++ -E
checking whether we are using the GNU Fortran 77 compiler... (cached) yes
checking whether gfortran accepts -g... (cached) yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared
libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared
libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for gfortran option to produce PIC... -fPIC
checking if gfortran PIC flag -fPIC works... yes
checking if gfortran static flag -static works... yes
checking if gfortran supports -c -o file.o... yes
checking whether the gfortran linker (/usr/bin/ld -m elf_x86_64) supports
shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
...
What results do you see? If configure is not finding that your system
can create shared libraries, can you try to find out why that happens?
jwe
- Re: gnulib and automake, (continued)
Re: gnulib and automake, Marco Atzeri, 2009/10/28
Re: gnulib and automake, Søren Hauberg, 2009/10/28
Re: gnulib and automake, Benjamin Lindner, 2009/10/30
- Re: gnulib and automake,
John W. Eaton <=
- Re: gnulib and automake, Benjamin Lindner, 2009/10/30
- Re: gnulib and automake, John W. Eaton, 2009/10/30
- Re: gnulib and automake, Benjamin Lindner, 2009/10/30
- Re: gnulib and automake, John W. Eaton, 2009/10/30
- Re: gnulib and automake, Benjamin Lindner, 2009/10/31
- Re: gnulib and automake, Benjamin Lindner, 2009/10/31
- Re: gnulib and automake, John W. Eaton, 2009/10/31
- Re: gnulib and automake, Benjamin Lindner, 2009/10/31
Re: gnulib and automake, John W. Eaton, 2009/10/31
Re: gnulib and automake, Benjamin Lindner, 2009/10/31