Re: dynamic linker (Win32)
* Florian Schricker wrote on Mon, May 22, 2006 at 12:11:50PM CEST: > > Von: Ralf Wildenhues <[EMAIL PROTECTED]> > > > > Our projects here use libtool/g++ to build DLLs which works fine > > > (now); > ltmain.sh (GNU libtool) 1.4e (1.1162 2002/11/22 22:36:25) > > (which is rather old, isn't it? But upgrading MinGW/MSys packages > unfortunately is *not* as easy as "emerge -u" :-/) Keith already answered this. The canned response is: upgrade first. The issue is rather obvious though: *snip* > checking for g77... no *snip* > checking for gfortran... no > checking whether we are using the GNU Fortran 77 compiler... no > checking whether accepts -g... no *snip* > appending configuration tag "F77" to libtool > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking for option to produce PIC... -DDLL_EXPORT > checking if PIC flag -DDLL_EXPORT works... no > checking if supports -c -o file.o... no > checking whether the linker (d:/eyerq/MSYS/1.0/mingw/mingw32/bin/ld.exe) > supports shared libraries... yes > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking dynamic linker characteristics... ./configure: -print-search-dirs: > command not found > ./configure: -print-search-dirs: command not found > Win32 ld.exe > I got this fixed. My bad. But all the above still remains. This is all due to nonexisting Fortran compiler. The requirement for AC_PROG_F77 is due to a limitation in Libtool-1.4.x which is also present in 1.5.x but not in CVS HEAD, the non-fatal-failure of AC_PROG_F77 if not called before all other AC_PROG_* is due to how current Autoconf implements AC_PROG_* and is bound to change at some point in the future because it is inconsistent and does not match the documentation fully, but there are packages out there (Libtool being one but not the only of them) that expect differing and conflicting behaviors of these macros. We have agreed to attack this issue only after Autoconf-2.60. You can simply ignore the errors you are seeing for now. Or install a Fortran compiler, if you like. :-) Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: dynamic linker (Win32)
Hi Ralf, hi bug-libtool-list! > Von: Ralf Wildenhues <[EMAIL PROTECTED]> > > Our projects here use libtool/g++ to build DLLs which works fine > > (now); but when configuring I get > > This is a Libtool issue. Please print the Libtool version that you use > (either "./libtool --version", or look at the beginning of the ltmain.sh ltmain.sh (GNU libtool) 1.4e (1.1162 2002/11/22 22:36:25) (which is rather old, isn't it? But upgrading MinGW/MSys packages unfortunately is *not* as easy as "emerge -u" :-/) > file), and post the complete output of the configure run to bug-libtool $ ./configure --prefix=/home/eyerq/local checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... gcc3 checking for egrep... grep -E checking for ld used by GCC... d:/eyerq/MSYS/1.0/mingw/mingw32/bin/ld.exe checking if the linker (d:/eyerq/MSYS/1.0/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for d:/eyerq/MSYS/1.0/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /mingw/bin/nm checking for a sed that does not truncate output... /bin/sed checking whether ln -s works... yes checking how to recognise dependent libraries... file_magic ^x86 archive import|^x86 DLL checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 8192 checking command to parse /mingw/bin/nm output from gcc object... ok checking for objdir... .libs checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (d:/eyerq/MSYS/1.0/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... Win32 ld.exe checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking whether the g++ linker (d:/eyerq/MSYS/1.0/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT checking if g++ PIC flag -DDLL_EXPORT works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (d:/eyerq/MSYS/1.0/mingw/mingw32/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... Win32 ld.exe appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libra
Re: dynamic linker (Win32)
Hi Florian, * [EMAIL PROTECTED] wrote on Mon, May 22, 2006 at 11:00:51AM CEST: > > I recently stumbled some weird behaviour I'd like to report. > > Our projects here use libtool/g++ to build DLLs which works fine > (now); but when configuring I get This is a Libtool issue. Please print the Libtool version that you use (either "./libtool --version", or look at the beginning of the ltmain.sh file), and post the complete output of the configure run to bug-libtool (which I've Cc:ed). Also post config.log (packed). Maybe also helpful if you post relevant parts of configure.ac. > [...] > checking dynamic linker characteristics... Win32 ld.exe > [...] > checking dynamic linker characteristics... ./configure: -print-search-dirs: > command not found > ./configure: -print-search-dirs: command not found > Win32 ld.exe Weird. Something unsets $CC. > 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 > ./configure: yes=yes: command not found Some other command is missing here, but I can't easily tell which. > So the test is re-run butit seems to fail with the error above. And > the last line of the snippet above seems to be quite strange, too. > Is this something bad? ;-) > configure continues to run, though, so it seems to work somehow... > Versions: > autoconf (GNU Autoconf) 2.59 > automake (GNU automake) 1.7.1 > running on MinGW/MSys Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
