bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Manoj Gupta <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <CAAMbb06yH+mQZkCu4RNbo+1XDZWrG2J1VmF6d2pDFpqnR=X8Kw@mail.gmail.com> |
Mike, Do you know who can commit this? On Mon, Jul 23, 2018 at 8:33 AM, Martin Storsjö <[email protected]> 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ö >> <[email protected]> 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 >> >> >> > _______________________________________________ Bug-libtool mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-libtool