Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin <address@hidden> 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