Re: libtool woes

[Peter Rosin]

On 2013-09-10 15:29, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin <address@hidden> wrote:
>> On 2013-09-10 15:00, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin <address@hidden> 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/msg00008.html