On 9/10/13, Peter Rosin <p...@lysator.liu.se> wrote: > On 2013-09-10 00:34, JonY wrote: >> On 9/10/2013 02:12, Ozkan Sezer wrote: >>> >>> *** Warning: linker path does not have real file for library -lole32. >>> *** I have the capability to make that library automatically link in >>> when >>> *** you link to this library. But I can only do this if you have a >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libole32 but no candidates were found. (...for file magic test) >>> >>> *** Warning: linker path does not have real file for library -ldsound. >>> *** I have the capability to make that library automatically link in >>> when >>> *** you link to this library. But I can only do this if you have a >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libdsound but no candidates were found. (...for file magic >>> test) >>> >>> *** Warning: linker path does not have real file for library -lwinmm. >>> *** I have the capability to make that library automatically link in >>> when >>> *** you link to this library. But I can only do this if you have a >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libwinmm but no candidates were found. (...for file magic test) >>> *** The inter-library dependencies that have been dropped here will be >>> *** automatically added whenever a program is linked with this library >>> *** or is declared to -dlopen it. >>> >>> I am stuck with this. Can anyone see what I am doing wrong? >>> >> >> This needs to be taken up with the libtool developers. >> >> libtool is technically correct, but libole32.a is a mixed shared lib >> with static data inserted. >> >> libtool should use dlltool --identify when available. > > Just to clarify, sufficiently new libtools (since 2.4) do in fact make > use of dlltool --identify when available, and I do not have any problem > handling -lole32 -ldsound -lwinmm when I try. We need more context to > help. > > Wild guess, could it be a missing -L /lib/w32api at play?
The line just before it reports its failure is like this: libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I./include -I./include -DMIKMOD_BUILD=1 -g -O2 -finline-functions -funroll-loops -ffast-math -Wall -MT playercode/virtch_common.lo -MD -MP -MF playercode/.deps/virtch_common.Tpo -c playercode/virtch_common.c -o playercode/virtch_common.o >/dev/null 2>&1 /bin/sh ./libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -DMIKMOD_BUILD=1 -g -O2 -finline-functions -funroll-loops -ffast-math -Wall -no-undefined -version-info 4:0:1 -o libmikmod.la -rpath /usr/local/lib drivers/drv_AF.lo drivers/drv_aiff.lo drivers/drv_aix.lo drivers/drv_alsa.lo [many other *.lo] -ldsound -lwinmm -lm This is using a cross-toolchain on linux, /opt/cross_win64/bin is first in the $PATH, /opt/cross_win64/x86_64-w64-mingw32/lib does have lib*.a required, and if I compile using a lite Makefile without using libtool then all links fine. Background on the issue is like the following. The project in question is here: http://sourceforge.net/u/sezero/mikmod/ci/default/tree/ $ hg clone http://hg.code.sf.net/u/sezero/mikmod u-sezero-mikmod $ cd u-sezero-mikmod/libmikmod $ libtoolize -c && autoreconf -i $ (then run the attached lt_patch.sh if using libtool-1.5) $ export PATH=/opt/cross_win64/bin:$PATH $ ./configure --host=x86_64-w64-mingw32 $ make The mingw-w64 toolchain is one of my old, using gcc-4.5 and our stable-1.x branch (to be precise, this is the toolchain: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/ using mingw-w64-bin_i686-linux_20111101_sezero.tar.gz plus the update-rev.5747.zip thing.) Libtool is requested from configure.ac: - for libtool-1.5 AC_LIBTOOL_WIN32_DLL AC_PROG_LIBTOOL - for libtool-2.2.x and 2.4[.2] : either the sameas above, or simply LT_INIT([win32-dll]) With libtool-1.5.x (1.5.26 to be precise) there are no problems, I can create a dll (I have to use the attached lt_patch.sh to make it work, but then all are good.) With libtool-2.2.8, 2.2.10, 2.4, 2.4.2 and 2.4.2.393-5d4a (git), I hit the failure and it gives me only a static library. Tell me if you need anything else. > > Cheers, > Peter > > -- O.S.
lt_patch.sh
Description: Bourne shell script
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool