[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27866: Handle clang's internal libraries when finding compiler's int
From: |
Manoj Gupta |
Subject: |
bug#27866: Handle clang's internal libraries when finding compiler's internal libraries |
Date: |
Mon, 23 Jul 2018 09:15:55 -0700 |
Mike,
Do you know who can commit this?
On Mon, Jul 23, 2018 at 8:33 AM, Martin Storsjö <address@hidden> wrote:
> Mike and Manoj,
>
> Another gentle ping on this subject...
>
> // Martin
>
>
> On Sat, 17 Mar 2018, Manoj Gupta wrote:
>
>> Mike,
>> Any ideas who can commit this to upstream libtool?
>>
>> On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsjö
>> <address@hidden> wrote:
>> On Fri, 19 Jan 2018, Mike Frysinger wrote:
>>
>> On 19 Jan 2018 17:34, Manoj
>> Gupta wrote:
>> I think that both .a
>> and .so libraries
>> should be handled
>> here. Will
>> *.${libext}
>> handle both cases?
>>
>>
>> libext is only "a". for shared
>> libs, it can be calculated from
>> shrext_cmds.
>> eval
>> std_shrext=\"$shrext_cmds\"
>> -L* | -R* | -l* | *.${libext} |
>> *${std_shrext})
>>
>> that would only support libs
>> that end in ".so". but maybe
>> that's OK.
>>
>>
>> Gentle ping - I'm also running into this
>> issue, and would like to have a canonical
>> fix for it upstream.
>>
>> // Martin
>>
>>
>>
>