Re: libtool woes

[Peter Rosin]

On 2013-09-17 10:23, Peter Rosin wrote:
> On 2013-09-17 09:50, Ozkan Sezer wrote:
>> Any chance that this patch, or a patch that fixes bug #15321 [1],
>> gets applied any time?
> 
> Yes, I'll push it in a bit.

Pushed.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-17 09:50, Ozkan Sezer wrote:
> Any chance that this patch, or a patch that fixes bug #15321 [1],
> gets applied any time?

Yes, I'll push it in a bit. It's been almost a week, and I suspect
that noone will take the time to review this, so I'm just going to
push it shortly without review.

Thanks for your patience.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On Wed, Sep 11, 2013 at 1:32 PM, Ozkan Sezer  wrote:
> On 9/11/13, Peter Rosin  wrote:
>> On 2013-09-10 16:10, Peter Rosin wrote:
>>> On 2013-09-10 15:56, Ozkan Sezer wrote:
 OK then, I'll keep an eye on mails from this list.

 (On an irrelevant note, the archive pages at
 http://lists.gnu.org/archive/html/libtool/2013-09/index.html
 http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
 doesn't list any mails from me, but the ones from you from this thread
 are there, so I don't know whether any of the mails I send arrive at
 the list..)
>>>
>>> That's strange, but you are correct in that all mails I have
>>> received from you have been coming directly too me, and none have
>>> arrived through the list. Maybe they are stuck in moderation, but
>>> I don't know the details of that???
>>>
>>> Anyway, I managed to dig up at least some background, see this thread
>>>
>>> http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html
>>
>> More background [1], [2]:
>>
>> Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2,
>> so that it nowadays automatically appends -print-multi-os-directory
>> for the applicable directories. I.e. it should no longer be necessary
>> for libtool to append a second ../lib64 when GCC has already done so.
>> Also, the multi-os appending crap seems to have been added specifically
>> for early (arguably broken) bi-arch enabled GCCs that printed -m32
>> directories even though -m64 was the default. So, my conclusion is
>> that we want any libtool magic to affect -print-search-dirs output from
>> contemporary GCCs as little as possible, while continuing to append
>> the -print-multi-os-directory for the legacy case.
>>
>> The thing to look out for could be if any of the -print-search-dirs
>> ends with /$lt_multi_os_dir and use that as an indicator that we have
>> a sufficiently new GCC, and all -print-search-dirs should be left as
>> is (we should probably continue prune those that don't exist, though).
>>
>> I have attached a version that implements the above idea.
>
> I can confirm that with this applied to libtool-git, I can build a dll
> using cross-toolchains on linux.  The `libtool --config` output for
> sys_lib_search_path_spec contains,
>
> - for a i686-pc-mingw32 toolchain with gcc-3.4.5:
> "/usr/local/cross-win32/i686-pc-mingw32/lib /usr/local/cross-win32/lib
> /usr/local/cross-win32/usr/lib "
>
> - for a i686-w64-mingw32 toolchain with gcc-4.5.4:
> "/opt/W32_180676/lib/gcc /opt/W32_180676/i686-w64-mingw32/lib32
> /opt/cross_win32/mingw/lib32 /opt/W32_180676/i686-w64-mingw32/lib
> /opt/cross_win32/mingw/lib "
>
> - for an x86_64-w64-mingw32 toolchain with gcc-4.5.4:
> "/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64
> /opt/cross_win64/mingw/lib64 /opt/W64_180676/x86_64-w64-mingw32/lib
> /opt/cross_win64/mingw/lib "
>
> Thanks for working on this.
>
>
>>  I feel
>> pretty good about that one actually, but would still like some
>> feedback from someone more familiar with multilib...
>>
>> Or should we just ditch support for those early, arguably broken,
>> bi-arch GCC versions and start trusting -print-search-dirs
>> unconditionally???
>>
>> Cheers,
>> Peter
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
>> [2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html
>>
>

Any chance that this patch, or a patch that fixes bug #15321 [1],
gets applied any time?

--
O.S.

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15321

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/11/13, Peter Rosin  wrote:
> On 2013-09-10 16:10, Peter Rosin wrote:
>> On 2013-09-10 15:56, Ozkan Sezer wrote:
>>> OK then, I'll keep an eye on mails from this list.
>>>
>>> (On an irrelevant note, the archive pages at
>>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
>>> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
>>> doesn't list any mails from me, but the ones from you from this thread
>>> are there, so I don't know whether any of the mails I send arrive at
>>> the list..)
>>
>> That's strange, but you are correct in that all mails I have
>> received from you have been coming directly too me, and none have
>> arrived through the list. Maybe they are stuck in moderation, but
>> I don't know the details of that???
>>
>> Anyway, I managed to dig up at least some background, see this thread
>>
>> http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html
>
> More background [1], [2]:
>
> Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2,
> so that it nowadays automatically appends -print-multi-os-directory
> for the applicable directories. I.e. it should no longer be necessary
> for libtool to append a second ../lib64 when GCC has already done so.
> Also, the multi-os appending crap seems to have been added specifically
> for early (arguably broken) bi-arch enabled GCCs that printed -m32
> directories even though -m64 was the default. So, my conclusion is
> that we want any libtool magic to affect -print-search-dirs output from
> contemporary GCCs as little as possible, while continuing to append
> the -print-multi-os-directory for the legacy case.
>
> The thing to look out for could be if any of the -print-search-dirs
> ends with /$lt_multi_os_dir and use that as an indicator that we have
> a sufficiently new GCC, and all -print-search-dirs should be left as
> is (we should probably continue prune those that don't exist, though).
>
> I have attached a version that implements the above idea.

I can confirm that with this applied to libtool-git, I can build a dll
using cross-toolchains on linux.  The `libtool --config` output for
sys_lib_search_path_spec contains,

- for a i686-pc-mingw32 toolchain with gcc-3.4.5:
"/usr/local/cross-win32/i686-pc-mingw32/lib /usr/local/cross-win32/lib
/usr/local/cross-win32/usr/lib "

- for a i686-w64-mingw32 toolchain with gcc-4.5.4:
"/opt/W32_180676/lib/gcc /opt/W32_180676/i686-w64-mingw32/lib32
/opt/cross_win32/mingw/lib32 /opt/W32_180676/i686-w64-mingw32/lib
/opt/cross_win32/mingw/lib "

- for an x86_64-w64-mingw32 toolchain with gcc-4.5.4:
"/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64
/opt/cross_win64/mingw/lib64 /opt/W64_180676/x86_64-w64-mingw32/lib
/opt/cross_win64/mingw/lib "

Thanks for working on this.


>  I feel
> pretty good about that one actually, but would still like some
> feedback from someone more familiar with multilib...
>
> Or should we just ditch support for those early, arguably broken,
> bi-arch GCC versions and start trusting -print-search-dirs
> unconditionally???
>
> Cheers,
> Peter
>
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
> [2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html
>

--
O.S.

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 16:10, Peter Rosin wrote:
> On 2013-09-10 15:56, Ozkan Sezer wrote:
>> OK then, I'll keep an eye on mails from this list.
>>
>> (On an irrelevant note, the archive pages at
>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
>> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
>> doesn't list any mails from me, but the ones from you from this thread
>> are there, so I don't know whether any of the mails I send arrive at
>> the list..)
> 
> That's strange, but you are correct in that all mails I have
> received from you have been coming directly too me, and none have
> arrived through the list. Maybe they are stuck in moderation, but
> I don't know the details of that???
> 
> Anyway, I managed to dig up at least some background, see this thread
> 
> http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html

More background [1], [2]:

Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2,
so that it nowadays automatically appends -print-multi-os-directory
for the applicable directories. I.e. it should no longer be necessary
for libtool to append a second ../lib64 when GCC has already done so.
Also, the multi-os appending crap seems to have been added specifically
for early (arguably broken) bi-arch enabled GCCs that printed -m32
directories even though -m64 was the default. So, my conclusion is
that we want any libtool magic to affect -print-search-dirs output from
contemporary GCCs as little as possible, while continuing to append
the -print-multi-os-directory for the legacy case.

The thing to look out for could be if any of the -print-search-dirs
ends with /$lt_multi_os_dir and use that as an indicator that we have
a sufficiently new GCC, and all -print-search-dirs should be left as
is (we should probably continue prune those that don't exist, though).

I have attached a version that implements the above idea. I feel
pretty good about that one actually, but would still like some
feedback from someone more familiar with multilib...

Or should we just ditch support for those early, arguably broken,
bi-arch GCC versions and start trusting -print-search-dirs
unconditionally???

Cheers,
Peter

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html

>From c3b6fb587942478acdb65f8a25725f51e61281f2 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Wed, 11 Sep 2013 11:56:56 +0200
Subject: [PATCH] libtool: trust -print-search-dirs from recent GCC

Alan Modra hints in [1] that -print-search-dirs was fixed in
GCC 4.2, so that it nowadays automatically appends
-print-multi-os-directory for the applicable directories. I.e.
it should no longer be necessary for libtool to append a second
../lib64 when GCC has already done so. Also, the multi-os
appending loop seems to have been added specifically for early
(arguably broken) bi-arch enabled GCCs that printed -m32
directories even though -m64 was the default [2]. So, my
conclusion is that we want any libtool magic to affect
-print-search-dirs output from contemporary GCCs as little as
possible, while continuing to append the
-print-multi-os-directory for the legacy case.

Fixes bug#15321 reported by Ozkan Sezer.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[2] http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html

* m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): If any of the
directories printed by -print-search-dirs ends with the
content of -print-multi-os-directory, then assume that
GCC adds the multi-os-directory where appropriate all by
itself and hence don't try to second guess when to add
it manually.
* THANKS: Update.
---
 THANKS|1 +
 m4/libtool.m4 |   17 -
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/THANKS b/THANKS
index f49e5d9..3c30f61 100644
--- a/THANKS
+++ b/THANKS
@@ -152,6 +152,7 @@
   Nixn...@esperi.org.uk
   Olaf Lenz			ol...@fias.uni-frankfurt.de
   Olly Betts			o...@muscat.co.uk
+  Ozkan Sezer			seze...@gmail.com
   Pádraig Brady			p...@draigbrady.com
   Patrice Fromy			patrice.fr...@u-psud.fr
   Patrick Welche		pr...@newn.cam.ac.uk
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..bdefd85 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2233,13 +2233,20 @@ if test yes = "$GCC"; then
 ;;
   esac
   # Ok, now we have the path, separated by spaces, we can step through it
-  # and add multilib dir if necessary.
+  # and add multilib dir if necessary...
   lt_tmp_lt_search_path_spec=
-  lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  lt_multi_os_dir=/`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  # ...but if some path already ends with the multilib dir we assume
+  # that all is fine and trust -print-search-dirs as is (GCC 4.2 or newer).
+  case "$lt_multi_os_dir; $lt_search_path_spec " in
+  "/; "* | "/.; "* | "/./; "* | *"$lt_multi_os_dir "* | *"$lt_multi_os_dir/ "*)
+lt_multi_os_dir=
+ 

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 15:29, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 15:00, Ozkan Sezer wrote:
 On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 12:52, Ozkan Sezer wrote:
>> That effectively cripples libtool for cross-compilers. Can the
>> behavior
>> be refined instead?  Can you contact Charles Wilson about this?
>
> He should be reading this list, if he has time...
>
> Anyway, does this work?
>

 No, it does not.  With this patch applied, I see
 sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
 ..  in the libtool --config output.
>>>
>>> Crap, I didn't do any final test and managed to exclude a couple
>>> of critical changes, and I did a couple of silly mistakes too. Sorry
>>> about that. Attached is what I should have sent the first time...
>>>
>>
>> Thanks, this one makes it to work. ./libtool --config output now has:
>>
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>> /opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib "
>>
>> which is suitable.
>
> *snip*
>
>> Is it hard to implement a way of directly respecting --print-search-dirs
>> output of the compiler though?
>
> Which is the crux of the matter, isn't it? The thing is, I'm not at all
> comfortable with applying this change, and have no clue if it breaks
> any existing setup. I mean, to me it seems obvious that if
> -print-search-dirs outputs *both* a .../lib64 and a .../lib variant, then
> someone really thought the tools should look in both places even if the
> -print-multi-os-directory is ../lib64. But at the same time, it is very
> likely that this loop in libtool (which is problematic for this case)
> solves a real problem somewhere. Since I do not know why the loop is
> there in the first place (the natural thing would be to simply trust
> -print-search-dirs, just as you say) I'm uneasy to change it.
>
> Peter O'Gorman (explicitly CC:ed) added the loop [1], hopefully he can
> fill in some blanks...
>
> Cheers,
> Peter
>
> [1] http://lists.gnu.org/archive/html/libtool-patches/2006-10/msg8.html
>

OK then, I'll keep an eye on mails from this list.

(On an irrelevant note, the archive pages at
http://lists.gnu.org/archive/html/libtool/2013-09/index.html
http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
doesn't list any mails from me, but the ones from you from this thread
are there, so I don't know whether any of the mails I send arrive at
the list..)

--
O.S.

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Ozkan Sezer  wrote:
> On 9/10/13, Peter Rosin  wrote:
> [...]
>>> @@ -2416,10 +2416,22 @@
>>>sys_lib_search_path_spec="$sys_lib_search_path_spec
>>> /usr/lib/w32api"])
>>>;;
>>>  mingw* | cegcc*)
>>># MinGW DLLs use traditional 'lib' prefix
>>>soname_spec='$libname`echo $release | $SED -e
>>> 's/[[.]]/-/g'`$versuffix$shared_ext'
>>> +  sys_lib_search_path_spec=`$CC -print-search-dirs | grep
>>> "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
>>> +  if echo "$sys_lib_search_path_spec" | [grep ';[c-zC-Z]:/'
 /dev/null]; then
>>> +# It is most probably a Windows format PATH printed by
>>> +# mingw gcc, but we are running on Cygwin. Gcc prints its
>>> search
>>> +# path with ; separators, and with drive letters. We can handle
>>> the
>>> +# drive letters (cygwin fileutils understands them), so leave
>>> them,
>>> +# especially as we might pass files found there to a mingw
>>> objdump,
>>> +# which wouldn't understand a cygwinified path. Ahh.
>>> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" |
>>> $SED -e 's/;/ /g'`
>>> +  else
>>> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" |
>>> $SED  -e "s/$PATH_SEPARATOR/ /g"`
>>> +  fi
>>>;;
>>>  pw32*)
>>># pw32 DLLs use 'pw' prefix rather than 'lib'
>>>library_names_spec='`echo $libname | sed -e 's/^lib/pw/'``echo
>>> $release | $SED -e 's/[[.]]/-/g'`$versuffix$shared_ext'
>>>;;
>>>
>>>
> [...]
>>> However, the last third hunk is the heart of it:  adding that fixes
>>> the issue.  That part was present in 2.2.6 but was removed in 2.2.8
>>> and later. What was the reason? (I couldn't find in the history using
>>> gitweb, but didn't try hard enugh either..)
>>
>> That last hunk will evade the multilib loop by redoing the
>> -print-search-dirs
>> thing one more time after that loop. However, it is severely broken on
>> native MinGW [1] and can definitely not be added as is. Sorry.
>>
>> [1]
>> http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00052.html
>>
>
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instead?  Can you contact Charles Wilson about this?
>

OK, I sent a message to bug-libtool about this (hopefully it arrives there.)

--
O.S.

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  wrote:
[...]
>> @@ -2416,10 +2416,22 @@
>>sys_lib_search_path_spec="$sys_lib_search_path_spec
>> /usr/lib/w32api"])
>>;;
>>  mingw* | cegcc*)
>># MinGW DLLs use traditional 'lib' prefix
>>soname_spec='$libname`echo $release | $SED -e
>> 's/[[.]]/-/g'`$versuffix$shared_ext'
>> +  sys_lib_search_path_spec=`$CC -print-search-dirs | grep
>> "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
>> +  if echo "$sys_lib_search_path_spec" | [grep ';[c-zC-Z]:/'
>>> /dev/null]; then
>> +# It is most probably a Windows format PATH printed by
>> +# mingw gcc, but we are running on Cygwin. Gcc prints its search
>> +# path with ; separators, and with drive letters. We can handle
>> the
>> +# drive letters (cygwin fileutils understands them), so leave
>> them,
>> +# especially as we might pass files found there to a mingw
>> objdump,
>> +# which wouldn't understand a cygwinified path. Ahh.
>> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" |
>> $SED -e 's/;/ /g'`
>> +  else
>> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" |
>> $SED  -e "s/$PATH_SEPARATOR/ /g"`
>> +  fi
>>;;
>>  pw32*)
>># pw32 DLLs use 'pw' prefix rather than 'lib'
>>library_names_spec='`echo $libname | sed -e 's/^lib/pw/'``echo
>> $release | $SED -e 's/[[.]]/-/g'`$versuffix$shared_ext'
>>;;
>>
>>
[...]
>> However, the last third hunk is the heart of it:  adding that fixes
>> the issue.  That part was present in 2.2.6 but was removed in 2.2.8
>> and later. What was the reason? (I couldn't find in the history using
>> gitweb, but didn't try hard enugh either..)
>
> That last hunk will evade the multilib loop by redoing the
> -print-search-dirs
> thing one more time after that loop. However, it is severely broken on
> native MinGW [1] and can definitely not be added as is. Sorry.
>
> [1] http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00052.html
>

That effectively cripples libtool for cross-compilers. Can the behavior
be refined instead?  Can you contact Charles Wilson about this?

--
O.S.

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 15:00, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 12:52, Ozkan Sezer wrote:
 That effectively cripples libtool for cross-compilers. Can the behavior
 be refined instead?  Can you contact Charles Wilson about this?
>>>
>>> He should be reading this list, if he has time...
>>>
>>> Anyway, does this work?
>>>
>>
>> No, it does not.  With this patch applied, I see
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
>> ..  in the libtool --config output.
>
> Crap, I didn't do any final test and managed to exclude a couple
> of critical changes, and I did a couple of silly mistakes too. Sorry
> about that. Attached is what I should have sent the first time...
>

Thanks, this one makes it to work. ./libtool --config output now has:

sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
/opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
/opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib "

which is suitable.

>> (Note that, this is not a multilib compiler: it targets only win64.)
>
> Even so, I believe that it outputs ../lib64 when you
> -print-multi-os-directory, right?
>

Well yeah, it does :)

Is it hard to implement a way of directly respecting --print-search-dirs
output of the compiler though?

--
O.S.

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Ozkan Sezer  wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
 On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
 On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.

 Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
 you.

 Can you provide the output from "libtool --config" and
 config.log? I'm not set up to easily duplicate your
 environment...

 Cheers,
 Peter


>>>
>>> Attached ./libtool --config output after configuration. Attached
>>> config.log.
>>
>> Your error messages indicate that libtool cannot find any files
>> matching the various things associated with -lole32 (and other
>> w32 libraries). I.e. it's not that the any files found are not
>> considered good enough, it's that libtool doesn't find them
>> at all. So, the dlltool --identify code path is in all likelihood
>> perfectly fine, it's just that nothing is being fed to dlltool
>> in the first place.
>>
>> So, something seems to be fishy with your library search path.
>> I notice this in your libtool --config:
>>
>> # Compile-time system search path for libraries.
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>> "
>>
>> Do you have any libole32.a (or something such) in any of those
>> places? If not, where are they? (and why didn't libtool pick
>> that up when it did $host-gcc --print-search-dirs?)
>>
>
> You are on the right track, and I think my new msg hasn't arrived yet.

 The messages crossed each other, yes. :-)

> See the attached new file libtool--config-1.5.out which is the output
> if I use libtool-1.5, and yes the the important difference is
> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
> "
>
> With 1.5, it is:
> sys_lib_search_path_spec="
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>
> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
> using /x86_64-w64-mingw32/lib64 instead for reasons
> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
> but it only holds gcc's libs, and as a result, the necessary libs
> aren't found.

 So, what output do you get from

x86_64-w64-mingw32-gcc --print-search-dirs

 I get:

 $ x86_64-w64-mingw32-gcc --print-search-dirs
 install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
 programs:
 =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
 libraries:
 =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/


>>>
>>> Mine says:
>>>
>>> $ x86_64-w64-mingw32-gcc --print-search-dirs
>>> install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>>> programs:
>>> =/opt/W64_180676/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/
>>> libraries:
>>> =/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/

Re: libtool woes

[Peter Rosin]

On 2013-09-10 15:56, Ozkan Sezer wrote:
> OK then, I'll keep an eye on mails from this list.
> 
> (On an irrelevant note, the archive pages at
> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
> doesn't list any mails from me, but the ones from you from this thread
> are there, so I don't know whether any of the mails I send arrive at
> the list..)

That's strange, but you are correct in that all mails I have
received from you have been coming directly too me, and none have
arrived through the list. Maybe they are stuck in moderation, but
I don't know the details of that???

Anyway, I managed to dig up at least some background, see this thread

http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 11:26, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
 On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 09:47, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
 Tell me if you need anything else.
>>>
>>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>>> you.
>>>
>>> Can you provide the output from "libtool --config" and
>>> config.log? I'm not set up to easily duplicate your
>>> environment...
>>>
>>> Cheers,
>>> Peter
>>>
>>>
>>
>> Attached ./libtool --config output after configuration. Attached
>> config.log.
>
> Your error messages indicate that libtool cannot find any files
> matching the various things associated with -lole32 (and other
> w32 libraries). I.e. it's not that the any files found are not
> considered good enough, it's that libtool doesn't find them
> at all. So, the dlltool --identify code path is in all likelihood
> perfectly fine, it's just that nothing is being fed to dlltool
> in the first place.
>
> So, something seems to be fishy with your library search path.
> I notice this in your libtool --config:
>
> # Compile-time system search path for libraries.
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
> "
>
> Do you have any libole32.a (or something such) in any of those
> places? If not, where are they? (and why didn't libtool pick
> that up when it did $host-gcc --print-search-dirs?)
>

 You are on the right track, and I think my new msg hasn't arrived yet.
>>>
>>> The messages crossed each other, yes. :-)
>>>
 See the attached new file libtool--config-1.5.out which is the output
 if I use libtool-1.5, and yes the the important difference is
 sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
 sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
 /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
 "

 With 1.5, it is:
 sys_lib_search_path_spec="
 /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
 /opt/W64_180676/bin/../lib/gcc/
 /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
 /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
 /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
 /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
 /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
 /opt/W64_180676/bin/../../cross_win64/mingw/lib/"

 The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
 i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
 using /x86_64-w64-mingw32/lib64 instead for reasons
 unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
 but it only holds gcc's libs, and as a result, the necessary libs
 aren't found.
>>>
>>> So, what output do you get from
>>>
>>> x86_64-w64-mingw32-gcc --print-search-dirs
>>>
>>> I get:
>>>
>>> $ x86_64-w64-mingw32-gcc --print-search-dirs
>>> install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
>>> programs:
>>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
>>> libraries:
>>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/
>>>
>>>
>>
>> Mine says:
>>
>> $ x86_64-w64-mingw32-gcc --print-search-dirs
>> install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>> programs:
>> =/opt/W64_180676/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/
>> libraries:
>> =/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Ozkan Sezer  wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>> Can you provide the output from "libtool --config" and
>> config.log? I'm not set up to easily duplicate your
>> environment...
>>
>> Cheers,
>> Peter
>>
>>
>
> Attached ./libtool --config output after configuration. Attached
> config.log.

OK, actually libtool --config output does give a clue. Attached new
file libtool--config-1.5.out which is the output if I use libtool-1.5

The important difference, I think, is sys_lib_search_path_spec
With 2.4.2.393-5d4a, it is:
sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
/opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
"

With 1.5, it is:
sys_lib_search_path_spec="
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
/opt/W64_180676/bin/../lib/gcc/
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
/opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
/opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
/opt/W64_180676/bin/../../cross_win64/mingw/lib/"

The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
but 2.4 is doing it and using lib64 instead for reasons unfathomable
to me.

--
O.S.


libtool--config-1.5.out
Description: Binary data
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 10:55, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
 On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 09:08, Ozkan Sezer wrote:
>> Tell me if you need anything else.
>
> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
> you.
>
> Can you provide the output from "libtool --config" and
> config.log? I'm not set up to easily duplicate your
> environment...
>
> Cheers,
> Peter
>
>

 Attached ./libtool --config output after configuration. Attached
 config.log.
>>>
>>> Your error messages indicate that libtool cannot find any files
>>> matching the various things associated with -lole32 (and other
>>> w32 libraries). I.e. it's not that the any files found are not
>>> considered good enough, it's that libtool doesn't find them
>>> at all. So, the dlltool --identify code path is in all likelihood
>>> perfectly fine, it's just that nothing is being fed to dlltool
>>> in the first place.
>>>
>>> So, something seems to be fishy with your library search path.
>>> I notice this in your libtool --config:
>>>
>>> # Compile-time system search path for libraries.
>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "
>>>
>>> Do you have any libole32.a (or something such) in any of those
>>> places? If not, where are they? (and why didn't libtool pick
>>> that up when it did $host-gcc --print-search-dirs?)
>>>
>>
>> You are on the right track, and I think my new msg hasn't arrived yet.
>
> The messages crossed each other, yes. :-)
>
>> See the attached new file libtool--config-1.5.out which is the output
>> if I use libtool-1.5, and yes the the important difference is
>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>> "
>>
>> With 1.5, it is:
>> sys_lib_search_path_spec="
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>> /opt/W64_180676/bin/../lib/gcc/
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>>
>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
>> using /x86_64-w64-mingw32/lib64 instead for reasons
>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
>> but it only holds gcc's libs, and as a result, the necessary libs
>> aren't found.
>
> So, what output do you get from
>
>   x86_64-w64-mingw32-gcc --print-search-dirs
>
> I get:
>
> $ x86_64-w64-mingw32-gcc --print-search-dirs
> install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
> programs:
> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
> libraries:
> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/
>
>

Mine says:

$ x86_64-w64-mingw32-gcc --print-search-dirs
install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
programs: 
=/opt/W64_180676/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/
libraries: 
=/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/:/opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/:/opt/W64_180676/bin/../lib/gcc/x86_64-

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 09:47, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
 Tell me if you need anything else.
>>>
>>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>>> you.
>>>
>>> Can you provide the output from "libtool --config" and
>>> config.log? I'm not set up to easily duplicate your
>>> environment...
>>>
>>> Cheers,
>>> Peter
>>>
>>>
>>
>> Attached ./libtool --config output after configuration. Attached
>> config.log.
>
> Your error messages indicate that libtool cannot find any files
> matching the various things associated with -lole32 (and other
> w32 libraries). I.e. it's not that the any files found are not
> considered good enough, it's that libtool doesn't find them
> at all. So, the dlltool --identify code path is in all likelihood
> perfectly fine, it's just that nothing is being fed to dlltool
> in the first place.
>
> So, something seems to be fishy with your library search path.
> I notice this in your libtool --config:
>
> # Compile-time system search path for libraries.
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "
>
> Do you have any libole32.a (or something such) in any of those
> places? If not, where are they? (and why didn't libtool pick
> that up when it did $host-gcc --print-search-dirs?)
>

You are on the right track, and I think my new msg hasn't arrived yet.
See the attached new file libtool--config-1.5.out which is the output
if I use libtool-1.5, and yes the the important difference is
sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
/opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
"

With 1.5, it is:
sys_lib_search_path_spec="
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
/opt/W64_180676/bin/../lib/gcc/
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
/opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
/opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
/opt/W64_180676/bin/../../cross_win64/mingw/lib/"

The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
using /x86_64-w64-mingw32/lib64 instead for reasons
unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
but it only holds gcc's libs, and as a result, the necessary libs
aren't found.

--
O.S.


libtool--config-1.5.out
Description: Binary data
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 12:52, Ozkan Sezer wrote:
>> That effectively cripples libtool for cross-compilers. Can the behavior
>> be refined instead?  Can you contact Charles Wilson about this?
>
> He should be reading this list, if he has time...
>
> Anyway, does this work?
>

No, it does not.  With this patch applied, I see
sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
..  in the libtool --config output.

(Note that, this is not a multilib compiler: it targets only win64.)


> Cheers,
> Peter
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 4418a1c..59953d1 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -2246,23 +2246,38 @@ if test yes = "$GCC"; then
>done
>lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
>  BEGIN {RS = " "; FS = "/|\n";} {
> -  lt_foo = "";
> -  lt_count = 0;
> +  lt_canon_foo = "";
> +  lt_canon_count = 0;
> +  lt_multi_foo = "";
> +  lt_multi_count = 0;
> +  lt_multi = 1;
>for (lt_i = NF; lt_i > 0; lt_i--) {
> -if ($lt_i != "" && $lt_i != ".") {
> +if ($lt_i == ";") {
> +  lt_multi = 0;
> +  continue;
> +}
> +if ($lt_i == "" || $lt_i == ".") continue;
> +if (!lt_multi) {
>if ($lt_i == "..") {
> -lt_count++;
> +lt_canon_count++;
> +  } else if (lt_canon_count == 0) {
> +lt_canon_foo = "/" $lt_i lt_canon_foo;
>} else {
> -if (lt_count == 0) {
> -  lt_foo = "/" $lt_i lt_foo;
> -} else {
> -  lt_count--;
> -}
> +lt_canon_count--;
>}
>  }
> +if ($lt_i == "..") {
> +  lt_multi_count++;
> +} else if (lt_multi_count == 0) {
> +  lt_multi_foo = "/" $lt_i lt_multi_foo;
> +} else {
> +  lt_multi_count--;
> +}
>}
> -  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
> -  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
> +  if (lt_canon_foo != "") { lt_canon_freq[lt_canon_foo]++; }
> +  if (lt_canon_freq[lt_multi_foo]) { lt_multi_foo = lt_canon_foo; }
> +  if (lt_multi_foo != "") { lt_multi_freq[lt_multi_foo]++; }
> +  if (lt_multi_freq[lt_multi_foo] == 1) { print lt_multi_foo; }
>  }'`
># AWK program above erroneously prepends '/' to C:/dos/paths
># for these hosts.
>

--
O.S.

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, Peter Rosin  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_2001/
using mingw-w64-bin_i686-linux_2001_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

Re: libtool woes

[Ozkan Sezer]

On 9/10/13, JonY <10wa...@gmail.com> 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.

The thing is, libole32.a is _not_ mixed: it is generated only from
ole32.def.  My first thought was like yours when I first hit the issue with
libws2_32.a, which _is_ mixed, but then saw it with others which are
let's say _pure_

>
> libtool should use dlltool --identify when available.
>

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 15:29, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 15:00, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
 On 2013-09-10 12:52, Ozkan Sezer wrote:
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instead?  Can you contact Charles Wilson about this?

 He should be reading this list, if he has time...

 Anyway, does this work?

>>>
>>> No, it does not.  With this patch applied, I see
>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
>>> ..  in the libtool --config output.
>>
>> Crap, I didn't do any final test and managed to exclude a couple
>> of critical changes, and I did a couple of silly mistakes too. Sorry
>> about that. Attached is what I should have sent the first time...
>>
> 
> Thanks, this one makes it to work. ./libtool --config output now has:
> 
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
> /opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib "
> 
> which is suitable.

*snip*

> Is it hard to implement a way of directly respecting --print-search-dirs
> output of the compiler though?

Which is the crux of the matter, isn't it? The thing is, I'm not at all
comfortable with applying this change, and have no clue if it breaks
any existing setup. I mean, to me it seems obvious that if
-print-search-dirs outputs *both* a .../lib64 and a .../lib variant, then
someone really thought the tools should look in both places even if the
-print-multi-os-directory is ../lib64. But at the same time, it is very
likely that this loop in libtool (which is problematic for this case)
solves a real problem somewhere. Since I do not know why the loop is
there in the first place (the natural thing would be to simply trust
-print-search-dirs, just as you say) I'm uneasy to change it.

Peter O'Gorman (explicitly CC:ed) added the loop [1], hopefully he can
fill in some blanks...

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/libtool-patches/2006-10/msg8.html

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 15:00, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>> That effectively cripples libtool for cross-compilers. Can the behavior
>>> be refined instead?  Can you contact Charles Wilson about this?
>>
>> He should be reading this list, if he has time...
>>
>> Anyway, does this work?
>>
> 
> No, it does not.  With this patch applied, I see
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
> ..  in the libtool --config output.

Crap, I didn't do any final test and managed to exclude a couple
of critical changes, and I did a couple of silly mistakes too. Sorry
about that. Attached is what I should have sent the first time...

> (Note that, this is not a multilib compiler: it targets only win64.)

Even so, I believe that it outputs ../lib64 when you
-print-multi-os-directory, right?

Cheers,
Peter


diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..b0ec76a 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2238,31 +2238,46 @@ if test yes = "$GCC"; then
   lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
   for lt_sys_path in $lt_search_path_spec; do
 if test -d "$lt_sys_path/$lt_multi_os_dir"; then
-  lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/$lt_multi_os_dir"
+  lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/;/$lt_multi_os_dir"
 else
   test -d "$lt_sys_path" && \
-	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path"
+	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/;"
 fi
   done
   lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
 BEGIN {RS = " "; FS = "/|\n";} {
-  lt_foo = "";
-  lt_count = 0;
+  lt_canon_foo = "";
+  lt_canon_count = 0;
+  lt_multi_foo = "";
+  lt_multi_count = 0;
+  lt_multi = 1;
   for (lt_i = NF; lt_i > 0; lt_i--) {
-if ($lt_i != "" && $lt_i != ".") {
+if ($lt_i == ";") {
+  lt_multi = 0;
+  continue;
+}
+if ($lt_i == "" || $lt_i == ".") continue;
+if (!lt_multi) {
   if ($lt_i == "..") {
-lt_count++;
+lt_canon_count++;
+  } else if (lt_canon_count == 0) {
+lt_canon_foo = "/" $lt_i lt_canon_foo;
   } else {
-if (lt_count == 0) {
-  lt_foo = "/" $lt_i lt_foo;
-} else {
-  lt_count--;
-}
+lt_canon_count--;
   }
 }
+if ($lt_i == "..") {
+  lt_multi_count++;
+} else if (lt_multi_count == 0) {
+  lt_multi_foo = "/" $lt_i lt_multi_foo;
+} else {
+  lt_multi_count--;
+}
   }
-  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
-  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+  if (lt_canon_foo != "") { lt_canon_freq[[lt_canon_foo]]++; }
+  if (lt_canon_freq[[lt_multi_foo]]) { lt_multi_foo = lt_canon_foo; }
+  if (lt_multi_foo != "") { lt_multi_freq[[lt_multi_foo]]++; }
+  if (lt_multi_freq[[lt_multi_foo]] == 1) { print lt_multi_foo; }
 }'`
   # AWK program above erroneously prepends '/' to C:/dos/paths
   # for these hosts.
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 12:52, Ozkan Sezer wrote:
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instead?  Can you contact Charles Wilson about this?

He should be reading this list, if he has time...

Anyway, does this work?

Cheers,
Peter

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..59953d1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2246,23 +2246,38 @@ if test yes = "$GCC"; then
   done
   lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
 BEGIN {RS = " "; FS = "/|\n";} {
-  lt_foo = "";
-  lt_count = 0;
+  lt_canon_foo = "";
+  lt_canon_count = 0;
+  lt_multi_foo = "";
+  lt_multi_count = 0;
+  lt_multi = 1;
   for (lt_i = NF; lt_i > 0; lt_i--) {
-if ($lt_i != "" && $lt_i != ".") {
+if ($lt_i == ";") {
+  lt_multi = 0;
+  continue;
+}
+if ($lt_i == "" || $lt_i == ".") continue;
+if (!lt_multi) {
   if ($lt_i == "..") {
-lt_count++;
+lt_canon_count++;
+  } else if (lt_canon_count == 0) {
+lt_canon_foo = "/" $lt_i lt_canon_foo;
   } else {
-if (lt_count == 0) {
-  lt_foo = "/" $lt_i lt_foo;
-} else {
-  lt_count--;
-}
+lt_canon_count--;
   }
 }
+if ($lt_i == "..") {
+  lt_multi_count++;
+} else if (lt_multi_count == 0) {
+  lt_multi_foo = "/" $lt_i lt_multi_foo;
+} else {
+  lt_multi_count--;
+}
   }
-  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
-  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+  if (lt_canon_foo != "") { lt_canon_freq[lt_canon_foo]++; }
+  if (lt_canon_freq[lt_multi_foo]) { lt_multi_foo = lt_canon_foo; }
+  if (lt_multi_foo != "") { lt_multi_freq[lt_multi_foo]++; }
+  if (lt_multi_freq[lt_multi_foo] == 1) { print lt_multi_foo; }
 }'`
   # AWK program above erroneously prepends '/' to C:/dos/paths
   # for these hosts.


diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4418a1c..59953d1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2246,23 +2246,38 @@ if test yes = "$GCC"; then
   done
   lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
 BEGIN {RS = " "; FS = "/|\n";} {
-  lt_foo = "";
-  lt_count = 0;
+  lt_canon_foo = "";
+  lt_canon_count = 0;
+  lt_multi_foo = "";
+  lt_multi_count = 0;
+  lt_multi = 1;
   for (lt_i = NF; lt_i > 0; lt_i--) {
-if ($lt_i != "" && $lt_i != ".") {
+if ($lt_i == ";") {
+  lt_multi = 0;
+  continue;
+}
+if ($lt_i == "" || $lt_i == ".") continue;
+if (!lt_multi) {
   if ($lt_i == "..") {
-lt_count++;
+lt_canon_count++;
+  } else if (lt_canon_count == 0) {
+lt_canon_foo = "/" $lt_i lt_canon_foo;
   } else {
-if (lt_count == 0) {
-  lt_foo = "/" $lt_i lt_foo;
-} else {
-  lt_count--;
-}
+lt_canon_count--;
   }
 }
+if ($lt_i == "..") {
+  lt_multi_count++;
+} else if (lt_multi_count == 0) {
+  lt_multi_foo = "/" $lt_i lt_multi_foo;
+} else {
+  lt_multi_count--;
+}
   }
-  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
-  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+  if (lt_canon_foo != "") { lt_canon_freq[lt_canon_foo]++; }
+  if (lt_canon_freq[lt_multi_foo]) { lt_multi_foo = lt_canon_foo; }
+  if (lt_multi_foo != "") { lt_multi_freq[lt_multi_foo]++; }
+  if (lt_multi_freq[lt_multi_foo] == 1) { print lt_multi_foo; }
 }'`
   # AWK program above erroneously prepends '/' to C:/dos/paths
   # for these hosts.
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 12:25, Ozkan Sezer wrote:
> On 9/10/13, Ozkan Sezer  wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 11:26, Ozkan Sezer wrote:
 On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 10:55, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin  wrote:
>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
 On 9/10/13, Peter Rosin  wrote:
> On 2013-09-10 09:08, Ozkan Sezer wrote:
>> Tell me if you need anything else.
>
> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
> you.
>
> Can you provide the output from "libtool --config" and
> config.log? I'm not set up to easily duplicate your
> environment...
>
> Cheers,
> Peter
>
>

 Attached ./libtool --config output after configuration. Attached
 config.log.
>>>
>>> Your error messages indicate that libtool cannot find any files
>>> matching the various things associated with -lole32 (and other
>>> w32 libraries). I.e. it's not that the any files found are not
>>> considered good enough, it's that libtool doesn't find them
>>> at all. So, the dlltool --identify code path is in all likelihood
>>> perfectly fine, it's just that nothing is being fed to dlltool
>>> in the first place.
>>>
>>> So, something seems to be fishy with your library search path.
>>> I notice this in your libtool --config:
>>>
>>> # Compile-time system search path for libraries.
>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>> "
>>>
>>> Do you have any libole32.a (or something such) in any of those
>>> places? If not, where are they? (and why didn't libtool pick
>>> that up when it did $host-gcc --print-search-dirs?)
>>>
>>
>> You are on the right track, and I think my new msg hasn't arrived yet.
>
> The messages crossed each other, yes. :-)
>
>> See the attached new file libtool--config-1.5.out which is the output
>> if I use libtool-1.5, and yes the the important difference is
>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>> "
>>
>> With 1.5, it is:
>> sys_lib_search_path_spec="
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>> /opt/W64_180676/bin/../lib/gcc/
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>>
>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
>> using /x86_64-w64-mingw32/lib64 instead for reasons
>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
>> but it only holds gcc's libs, and as a result, the necessary libs
>> aren't found.
>
> So, what output do you get from
>
>   x86_64-w64-mingw32-gcc --print-search-dirs
>
> I get:
>
> $ x86_64-w64-mingw32-gcc --print-search-dirs
> install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
> programs:
> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
> libraries:
> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/
>
>

 Mine says:

 $ x86_64-w64-mingw32-gcc --print-search-dirs
 install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
 programs:
 =/opt/W64_180676/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw3

Re: libtool woes

[Peter Rosin]

On 2013-09-10 11:50, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
 On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
 On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.

 Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
 you.

 Can you provide the output from "libtool --config" and
 config.log? I'm not set up to easily duplicate your
 environment...

 Cheers,
 Peter


>>>
>>> Attached ./libtool --config output after configuration. Attached
>>> config.log.
>>
>> Your error messages indicate that libtool cannot find any files
>> matching the various things associated with -lole32 (and other
>> w32 libraries). I.e. it's not that the any files found are not
>> considered good enough, it's that libtool doesn't find them
>> at all. So, the dlltool --identify code path is in all likelihood
>> perfectly fine, it's just that nothing is being fed to dlltool
>> in the first place.
>>
>> So, something seems to be fishy with your library search path.
>> I notice this in your libtool --config:
>>
>> # Compile-time system search path for libraries.
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>> "
>>
>> Do you have any libole32.a (or something such) in any of those
>> places? If not, where are they? (and why didn't libtool pick
>> that up when it did $host-gcc --print-search-dirs?)
>>
>
> You are on the right track, and I think my new msg hasn't arrived yet.

 The messages crossed each other, yes. :-)

> See the attached new file libtool--config-1.5.out which is the output
> if I use libtool-1.5, and yes the the important difference is
> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
> "
>
> With 1.5, it is:
> sys_lib_search_path_spec="
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>
> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
> using /x86_64-w64-mingw32/lib64 instead for reasons
> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
> but it only holds gcc's libs, and as a result, the necessary libs
> aren't found.

 So, what output do you get from

x86_64-w64-mingw32-gcc --print-search-dirs

 I get:

 $ x86_64-w64-mingw32-gcc --print-search-dirs
 install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
 programs:
 =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
 libraries:
 =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/


>>>
>>> Mine says:
>>>
>>> $ x86_64-w64-mingw32-gcc --print-search-dirs
>>> install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>>> programs:
>>> =/opt/W64_180676/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/
>>> libraries:
>>> =/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64

Re: libtool woes

[Peter Rosin]

On 2013-09-10 11:26, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
 On 2013-09-10 09:47, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>> Can you provide the output from "libtool --config" and
>> config.log? I'm not set up to easily duplicate your
>> environment...
>>
>> Cheers,
>> Peter
>>
>>
>
> Attached ./libtool --config output after configuration. Attached
> config.log.

 Your error messages indicate that libtool cannot find any files
 matching the various things associated with -lole32 (and other
 w32 libraries). I.e. it's not that the any files found are not
 considered good enough, it's that libtool doesn't find them
 at all. So, the dlltool --identify code path is in all likelihood
 perfectly fine, it's just that nothing is being fed to dlltool
 in the first place.

 So, something seems to be fishy with your library search path.
 I notice this in your libtool --config:

 # Compile-time system search path for libraries.
 sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
 /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "

 Do you have any libole32.a (or something such) in any of those
 places? If not, where are they? (and why didn't libtool pick
 that up when it did $host-gcc --print-search-dirs?)

>>>
>>> You are on the right track, and I think my new msg hasn't arrived yet.
>>
>> The messages crossed each other, yes. :-)
>>
>>> See the attached new file libtool--config-1.5.out which is the output
>>> if I use libtool-1.5, and yes the the important difference is
>>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
>>> "
>>>
>>> With 1.5, it is:
>>> sys_lib_search_path_spec="
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../lib/gcc/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
>>>
>>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
>>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
>>> using /x86_64-w64-mingw32/lib64 instead for reasons
>>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
>>> but it only holds gcc's libs, and as a result, the necessary libs
>>> aren't found.
>>
>> So, what output do you get from
>>
>>  x86_64-w64-mingw32-gcc --print-search-dirs
>>
>> I get:
>>
>> $ x86_64-w64-mingw32-gcc --print-search-dirs
>> install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
>> programs:
>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
>> libraries:
>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/
>>
>>
> 
> Mine says:
> 
> $ x86_64-w64-mingw32-gcc --print-search-dirs
> install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
> programs: 
> =/opt/W64_180676/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/
> libraries: 
> =/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/:/opt/W64_180676/bin/../../

Re: libtool woes

[Peter Rosin]

On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin  wrote:
 On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.

 Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
 you.

 Can you provide the output from "libtool --config" and
 config.log? I'm not set up to easily duplicate your
 environment...

 Cheers,
 Peter


>>>
>>> Attached ./libtool --config output after configuration. Attached
>>> config.log.
>>
>> Your error messages indicate that libtool cannot find any files
>> matching the various things associated with -lole32 (and other
>> w32 libraries). I.e. it's not that the any files found are not
>> considered good enough, it's that libtool doesn't find them
>> at all. So, the dlltool --identify code path is in all likelihood
>> perfectly fine, it's just that nothing is being fed to dlltool
>> in the first place.
>>
>> So, something seems to be fishy with your library search path.
>> I notice this in your libtool --config:
>>
>> # Compile-time system search path for libraries.
>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "
>>
>> Do you have any libole32.a (or something such) in any of those
>> places? If not, where are they? (and why didn't libtool pick
>> that up when it did $host-gcc --print-search-dirs?)
>>
> 
> You are on the right track, and I think my new msg hasn't arrived yet.

The messages crossed each other, yes. :-)

> See the attached new file libtool--config-1.5.out which is the output
> if I use libtool-1.5, and yes the the important difference is
> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is:
> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc
> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64
> "
> 
> With 1.5, it is:
> sys_lib_search_path_spec="
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/
> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/
> /opt/W64_180676/bin/../../cross_win64/mingw/lib/"
> 
> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib
> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and
> using /x86_64-w64-mingw32/lib64 instead for reasons
> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist,
> but it only holds gcc's libs, and as a result, the necessary libs
> aren't found.

So, what output do you get from

x86_64-w64-mingw32-gcc --print-search-dirs

I get:

$ x86_64-w64-mingw32-gcc --print-search-dirs
install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/
programs: 
=/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/
libraries: 
=/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 09:47, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin  wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>> Can you provide the output from "libtool --config" and
>> config.log? I'm not set up to easily duplicate your
>> environment...
>>
>> Cheers,
>> Peter
>>
>>
> 
> Attached ./libtool --config output after configuration. Attached
> config.log.

Your error messages indicate that libtool cannot find any files
matching the various things associated with -lole32 (and other
w32 libraries). I.e. it's not that the any files found are not
considered good enough, it's that libtool doesn't find them
at all. So, the dlltool --identify code path is in all likelihood
perfectly fine, it's just that nothing is being fed to dlltool
in the first place.

So, something seems to be fishy with your library search path.
I notice this in your libtool --config:

# Compile-time system search path for libraries.
sys_lib_search_path_spec="/opt/W64_180676/lib/gcc 
/opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 "

Do you have any libole32.a (or something such) in any of those
places? If not, where are they? (and why didn't libtool pick
that up when it did $host-gcc --print-search-dirs?)

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.

Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.

Can you provide the output from "libtool --config" and
config.log? I'm not set up to easily duplicate your
environment...

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[Peter Rosin]

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?

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool woes

[JonY]

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.




signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool woes

[Ralf Wildenhues]

Hello Jason, Brian, all,

* Jason Curl wrote on Mon, Aug 20, 2007 at 11:41:03AM CEST:
> Brian Dessent wrote:
>>
[ snip nice, concise and well-written explanations ]
>>
> Brian - thanks for the concise description. Ralf - any way to may be
> add an addendum to the libtool docs for this, just for info?

Here's your (and by this I intend to address both of you alike ;-)
chance to get involved in Libtool development -- check out CVS Libtool
as explained on , read on how to
, and start turning
it into a chapter of the manual.

For short platform-specific configuration notes, see the node "Configure
notes" with sources in doc/notes.texi.  Longer stuff could be put under
"Platform quirks" in doc/libtool.texi; I would not mind if there were a
new section about w32-specific issues.

Expect to have to revise your patch a couple of times.  ;-)

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool woes

[Jason Curl]

Brian Dessent wrote:

.dll.a is the import library.  .dll is the actual library.  Both should
be produced.  The import library is used when linking against the
library, but it is not needed at runtime and contains no code.  It's
typically distributed in the same context as headers -- it is needed by
developers who want to build against your library, but not users who
simply want to run software that uses your library.  In some cases it is
also named just "libfoo.a", or perhaps "foo.lib" if you want
compatibility with users of the MS toolchain.  As its name suggests this
is actaully an "ar" archive.

It looks like you may be getting confused because the linker outputs a
message along the lines of "creating file libfoo.dll.a" when the
--out-implib linker switch is used, but this really means "in addition
to the normal output libfoo.dll I'm also producing an import library
libfoo.dll.a as a side effect of creating the library" not that the
library would actually be named libfoo.dll.a.

The concept of an import library is a bit of a hold-back to days past. 
Using the GNU linker at least, you can link directly to a DLL without

any import library.  However, there is one function of an import library
that cannot be duplicated otherwise, and that is the ability to provide
aliases for symbol names.  This allows you to do things like rename
functions in the actual library without affecting callers/users that use
the old name.  It also comes in very handy when reconciling differences
in stdcall function decoration when trying to mix code between different
vendors' toolchains.

PE has no means of explicit symbol versioning.  Shared library
versioning works on the basis of choosing an appropriate filename for
the library, i.e. libfoo-n.dll.  This should happen automatically when
you use -version-info appropriately.

The import library thus also provides one further function that makes it
very handy -- it functions analogously to the "foo.so -> foo.so.1"
symlink on POSIX systems.  The import library is always named just
libfoo.dll.a without any version numbers, and so the linker finds it
when you specify -lfoo.  However, the actual name of the library may be
libfoo-2.dll (or cygfoo-2.dll if you're using Cygwin) and hence the
import library is the thing that selects which version of the library to
link against.

For example on Cygwin:

$ ls -l /usr/bin/cygintl* /usr/lib/libintl*
-rwxr-x---+ 1 brian Users 22K Dec 13  2001 /usr/bin/cygintl-1.dll
-rwxr-x---+ 1 brian Users 37K Aug 10  2003 /usr/bin/cygintl-2.dll
-rwxr-x---+ 1 brian Users 31K Nov 19  2005 /usr/bin/cygintl-3.dll
-rwxr-x---+ 1 brian Users 31K Oct 22  2006 /usr/bin/cygintl-8.dll
-rwxr-x---+ 1 brian Users 48K Oct 22  2006 /usr/lib/libintl.a
-rwxr-x---+ 1 brian Users 30K Oct 22  2006 /usr/lib/libintl.dll.a
-rwxr-x---+ 1 brian Users 800 Oct 22  2006 /usr/lib/libintl.la

Here you see that there are four versions of the libintl library
installed, however there is just the one import library.  The name of
the DLL is encoded into the import library, so this means any new code
that is compiled today with -lintl will find /usr/lib/libintl.dll.a
which internally specifies the filename corresponding to ABI version 8
of the library.  But the other versions can still exist on disk for the
sake of supporting existing binary packages of the previous ABI
versions.  So this works just like the symlink on POSIX that selects
which version of the library all new binaries should link against (which
is almost always the newest.)

  
Brian - thanks for the concise description. Ralf - any way to may be add 
an addendum to the libtool docs for this, just for info?

Brian

  




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool woes

[Brian Dessent]

Jason Curl wrote:

> I guess what happens if I don't say this the build will fail. I've

It should produce static libraries if it cannot produce shared ones.

> turned it on and it looks good. I'll try and search more info later, but
> while I'm at it:
> - Why is it .dll.a and not .dll?
> - How is versioning information embedded in the DLL, or is the basis of
> the DLL hell?

.dll.a is the import library.  .dll is the actual library.  Both should
be produced.  The import library is used when linking against the
library, but it is not needed at runtime and contains no code.  It's
typically distributed in the same context as headers -- it is needed by
developers who want to build against your library, but not users who
simply want to run software that uses your library.  In some cases it is
also named just "libfoo.a", or perhaps "foo.lib" if you want
compatibility with users of the MS toolchain.  As its name suggests this
is actaully an "ar" archive.

It looks like you may be getting confused because the linker outputs a
message along the lines of "creating file libfoo.dll.a" when the
--out-implib linker switch is used, but this really means "in addition
to the normal output libfoo.dll I'm also producing an import library
libfoo.dll.a as a side effect of creating the library" not that the
library would actually be named libfoo.dll.a.

The concept of an import library is a bit of a hold-back to days past. 
Using the GNU linker at least, you can link directly to a DLL without
any import library.  However, there is one function of an import library
that cannot be duplicated otherwise, and that is the ability to provide
aliases for symbol names.  This allows you to do things like rename
functions in the actual library without affecting callers/users that use
the old name.  It also comes in very handy when reconciling differences
in stdcall function decoration when trying to mix code between different
vendors' toolchains.

PE has no means of explicit symbol versioning.  Shared library
versioning works on the basis of choosing an appropriate filename for
the library, i.e. libfoo-n.dll.  This should happen automatically when
you use -version-info appropriately.

The import library thus also provides one further function that makes it
very handy -- it functions analogously to the "foo.so -> foo.so.1"
symlink on POSIX systems.  The import library is always named just
libfoo.dll.a without any version numbers, and so the linker finds it
when you specify -lfoo.  However, the actual name of the library may be
libfoo-2.dll (or cygfoo-2.dll if you're using Cygwin) and hence the
import library is the thing that selects which version of the library to
link against.

For example on Cygwin:

$ ls -l /usr/bin/cygintl* /usr/lib/libintl*
-rwxr-x---+ 1 brian Users 22K Dec 13  2001 /usr/bin/cygintl-1.dll
-rwxr-x---+ 1 brian Users 37K Aug 10  2003 /usr/bin/cygintl-2.dll
-rwxr-x---+ 1 brian Users 31K Nov 19  2005 /usr/bin/cygintl-3.dll
-rwxr-x---+ 1 brian Users 31K Oct 22  2006 /usr/bin/cygintl-8.dll
-rwxr-x---+ 1 brian Users 48K Oct 22  2006 /usr/lib/libintl.a
-rwxr-x---+ 1 brian Users 30K Oct 22  2006 /usr/lib/libintl.dll.a
-rwxr-x---+ 1 brian Users 800 Oct 22  2006 /usr/lib/libintl.la

Here you see that there are four versions of the libintl library
installed, however there is just the one import library.  The name of
the DLL is encoded into the import library, so this means any new code
that is compiled today with -lintl will find /usr/lib/libintl.dll.a
which internally specifies the filename corresponding to ABI version 8
of the library.  But the other versions can still exist on disk for the
sake of supporting existing binary packages of the previous ABI
versions.  So this works just like the symlink on POSIX that selects
which version of the library all new binaries should link against (which
is almost always the newest.)

Brian


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool woes

[Jason Curl]

Brian Dessent wrote:

Jason Curl wrote:

  

/bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2 -version-info
0:0:0  -o libtp.la -rpath /usr/local/lib version.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries



Libtool won't build shared libraries on Win32/PE targets without
-no-undefined in *_LDFLAGS.  The text of this warning message could
perhaps be clearer, because it's not telling you that you necessarily
have any undefined symbols, it's telling you that you didn't assure
libtool that you don't.
  


I guess what happens if I don't say this the build will fail. I've 
turned it on and it looks good. I'll try and search more info later, but 
while I'm at it:

- Why is it .dll.a and not .dll?
- How is versioning information embedded in the DLL, or is the basis of 
the DLL hell?


  

lib -OUT:.libs/libtp.lib  version.o
../libtool: line 5973: lib: command not found



I'm not sure why it's trying to use lib here, that seems wrong if you're
using gcc/binutils.  Possibly a configure problem?
  


It was a configure problem. My shame! Trying to work around a Solaris 10 
issue, where the "ld" is not found automatically I wrote an AC_PROG_LD. 
Unfortunately this gets used instead of the original and I never noticed 
if there were any conflicts. That's why it didn't matter if I used it or 
not in my configure.ac script, I actually had to delete it first before 
everything came back to normal.


Sorry for the noise. It looks like I'll have to read up a lot more about 
shared library concepts in general to understand libtool better. Only 
one more problem I know of to go!




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool woes

[Ralf Wildenhues]

* Brian Dessent wrote on Fri, Aug 17, 2007 at 09:49:48PM CEST:
> Jason Curl wrote:
> 
> > lib -OUT:.libs/libtp.lib  version.o
> > ../libtool: line 5973: lib: command not found
> 
> I'm not sure why it's trying to use lib here, that seems wrong if you're
> using gcc/binutils.  Possibly a configure problem?

Hmm.  libtool.m4 sets this on mingw when $GCC is not yes, or it
otherwise thinks the linker isn't the GNU binutils one.  Can you
find out why/where it does that?  If config.log doesn't make it
clear, then you may have to run
  /bin/sh -x configure [...]  >log 2>&1

and search in log for 'GCC=' or 'with_gnu_ld'.

Hope that helps.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool woes

[Brian Dessent]

Jason Curl wrote:

> /bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2 -version-info
> 0:0:0  -o libtp.la -rpath /usr/local/lib version.lo
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> shared libraries

Libtool won't build shared libraries on Win32/PE targets without
-no-undefined in *_LDFLAGS.  The text of this warning message could
perhaps be clearer, because it's not telling you that you necessarily
have any undefined symbols, it's telling you that you didn't assure
libtool that you don't.

> lib -OUT:.libs/libtp.lib  version.o
> ../libtool: line 5973: lib: command not found

I'm not sure why it's trying to use lib here, that seems wrong if you're
using gcc/binutils.  Possibly a configure problem?

Brian


___
http://lists.gnu.org/mailman/listinfo/libtool