Re: [patch #8254] AX_BOOST_BASE: fix lib detection on multi-arch systems
Peter Johansson <[email protected]>
| Newsgroups | gmane.comp.sysutils.autoconf.archive-maintainers |
|---|---|
| Message-ID | <[email protected]> |
Hi Cory, On 12/13/2013 07:51 PM, Cory Fields wrote: > (Subscribed to the list to reply, sorry for the formatting kludge here) > >> Libtool has code to figure out which dirs are in linkers search path. Perhaps we should borrow that code and let the linker tell us where to look for boost rather than patching for every packager. >> >> I don't mind this patch. On the contrary, but I'm just sharing what I though might be a better idea. Any thoughts? > Sure, that would be much more reasonable than the current approach by > the module. A more comprehensive fix, though, would require more time > than I am able to spend on this. As far as I can tell, this patch > guards against the only big change distro packagers are likely to make > any time soon, so it should suffice for us. > > Fwiw, I've done an implementation of what you mentioned above before, > which pretty much consists of invoking the linker with some dump > option (-Wl,--print-map, -Wl,--trace, etc) and grepping the output, or > probing the resulting object. I found it to be pretty sensitive to the > compiler/linker used. Maybe libtool has a saner approach? Yeah, I will look into the libtool code in more detail. It won't be on this side of the holidays though. > > Seems to me a simpler route would be to avoid trying to find the path > entirely, and just link-test with -lboost_foo, -lboost_foo_mt, etc, > until one hits. I assume there's some need for the path that precludes > this more typical approach? I was working on a patch like that early this year when I realized the library can be named all kind of funny things including compiler build triplets in the name. The combinations were just too many to enumerate, so I guess that's why original author chose the wild-card solution. > > Thanks for the quick and helpful response! Thanks for catching this and taking the time to submit a patch. Cheers, Peter