Re: Fwd: Fwd: android support

[Brooks Moses]

On Tue, Sep 10, 2013 at 1:05 AM, David Turner  wrote:
> For the record, I've kept the $release to keep the structure similar to the
> glibc one. I admit I don't really know what that corresponds to, but I could
> successfully build working shared libraries for a few projects with my
> patch. Good enough for me.

The $release variable gets set by the -release option; see:
http://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode

That  defines the option as "Specify that the library was generated by
release release of your package, so that users can easily tell which
versions are newer than others. Be warned that no two releases of your
package will be binary compatible if you use this flag."  Given that,
I agree it makes sense to use it in the name as in Linux, though as
far as I can tell it seems pretty rarely used.

> Also, in case you're interested, I've an updated patch that also prevents
> adding a DT_RUNPATH in the .dynamic section (the Android system linker
> doesn't support it). This is purely cosmetic though, the initial patch is ok
> too. Just let me know if you want the update.

Might as well put in the most recent version while I'm doing it!

- Brooks

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

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: Fwd: Fwd: android support

[David Turner]

Hello,

Glad seeing this being addressed :-)

On Tue, Sep 10, 2013 at 12:41 AM, Brooks Moses  wrote:

> Hello, Marco,
>
> Thanks for pinging this -- I'm trying to work through some of the libtool
> patch backlog, and I'll have a look at this in the next few days.
>
> I note that David Turner also posted a patch for Android support in
> libtool more recently:
> http://lists.gnu.org/archive/**html/libtool-patches/2013-06/**
> msg2.html
>
> The patches are fairly similar, although I think the organization of
> David's patch (which keeps the "Android" and "glibc/ELF" blocks entirely
> separate) is a bit better since Android is not glibc-based.
>
> The one key difference here is that your patch uses $libname$shared_ext
> for library_names_spec and soname_spec, whereas David's uses
> $libname$release$shared_ext.  Is there a particular argument in favor of
> one or the other of these?
>
> For the record, I've kept the $release to keep the structure similar to
the glibc one. I admit I don't really know what that corresponds to, but I
could successfully build working shared libraries for a few projects with
my patch. Good enough for me.
Also, in case you're interested, I've an updated patch that also prevents
adding a DT_RUNPATH in the .dynamic section (the Android system linker
doesn't support it). This is purely cosmetic though, the initial patch is
ok too. Just let me know if you want the update.

- David


> - Brooks
>
>
>
> On 09/04/2013 09:53 AM, Marco Bernasocchi wrote:
>
>> I try again, lets see if this patch can be applied.
>> ciao
>> Marco
>>
>>
>>  Original Message 
>> Subject: Fwd: android support
>> Date: Fri, 04 May 2012 16:48:51 +0200
>> From: Marco Bernasocchi 
>> Organization: bernawebdesign.ch
>> To: libtool-patc...@gnu.org
>>
>> Hi guys, I never heard back, did this make it throug?
>> thanks
>>
>>  Original Message 
>> Subject: android support
>> Date: Wed, 23 Nov 2011 02:23:46 +0100
>> From: Marco Bernasocchi 
>> To: libtool-patc...@gnu.org
>>
>> Hi all,
>> I hope i'm writing to the right list. In the process of poring QGIS to
>> android I encountred a big limitation. The android system does not
>> support versioned shared libs. I wrote the attached patch and used it in
>> the configure scripts of 6 different libs (geos, proj, gsl, expat, gdal,
>> libiconv) with success.
>> I think more and more people will start soon porting more libs to
>> android, so it would be nice to have this in libtool. the crosscompiler
>> host call to use is: --host=arm-linux-androideabi
>>
>> Thanks a lot for the great tool
>> Marco Bernasocchi
>>
>> www.opengis.ch
>>
>>
>>
>>
>>
>
___
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

./libs directory is not creating automatically

[starz]

I have used thic command 
libtool --mode=compile gcc -g -o -c foo.c

The .o file is creating in the current directory. .libs in not creating.

Actual output should be like this after the command:
$libtool --mode=compile gcc -g -O -c foo.c
 mkdir .libs
 gcc -g -O -c foo.c  -fPIC -DPIC -o .libs/foo.o
 gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1

but observed output is 
$libtool --mode=compile gcc -g -O -c foo.c
 gcc -g -O -c foo.c  -fPIC -DPIC -o .libs/foo.o
 gcc -g -O -c foo.c -o foo.o >/dev/null 2>&1.

Is there any correction i have to be done?




-- 
View this message in context: 
http://old.nabble.com/.-libs-directory-is-not-creating-automatically-tp35926491p35926491.html
Sent from the Gnu - Libtool - Discuss mailing list archive at Nabble.com.


___
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