#54553 closed defect (fixed)
clang effectively ignores the LIBRARY_PATH env. variable
Reported by: | RJVB (René Bertin) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | larryv (Lawrence Velázquez) | |
Port: | clang-4.0 |
Description
Clang has a subtly different way than GCC of handling the LIBRARY_PATH env. variable which can have significant implications for libraries that are present on the default (system) search path as well as in $prefix
.
With GCC, LIBRARY_PATH=${prefix}/lib
will translate into a link editor command (collect2) that has -L${prefix}/lib
*BEFORE* all -lfoo
libspecs. Clang translates the variable to the same -L
expression but puts this *AFTER* all -lfoo
libspecs it was invoked with. In other words, clang applies LIBRARY_PATH
only to libraries that are added automatically:
> env LIBRARY_PATH=/opt/local/lib gcc -v test.o -lA -lB ... collect2 [...] test.o -L/opt/local/lib -lA -lB [standard libraries] [...]
vs.
> env LIBRARY_PATH=/opt/local/lib clang-mp-4.0 -v test.o -lA -lB ... dyld [...] test.o -lA -lB -L/opt/local/lib [standard libraries] [...]
I'll admit that I discovered this (= it bit me) on Linux, and even there only with cmake-based projects (recent CMake versions will rewrite absolute libspecs /opt/local/lib/libfoo.dylib
into the shorthand libspecs -lfoo
if it thinks the library ought to be found on the search path).
Still, I think it's a bug, or at least something that would be good to set straight in a MacPorts context. My query about it on the clang ML remains unanswered after 3 weeks so I'm signalling the issue here. I'll leave it up to port maintainers to decide if and how they'll address it here or upstream.
Change History (6)
comment:1 Changed 7 years ago by mf2k (Frank Schima)
Cc: | jeremyhu removed |
---|---|
Owner: | set to jeremyhu |
Status: | new → assigned |
comment:2 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)
comment:3 Changed 7 years ago by RJVB (René Bertin)
I was hoping a port maintainer would already have an LLVM bugzilla account and something of a track record on it. The (even) larger community on the ML hasn't been showing any interest in discussing this at all. I did look into filing a ticket before I filed one here but wasn't myself particularly keen on following the account creation procedure (ask nicely and then wait until someone creates the account).
comment:4 Changed 7 years ago by RJVB (René Bertin)
Actually, it turns out this is a longstanding bug and someone even wrote a patch:
comment:5 Changed 5 years ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
This isn't something that I would want to change in MacPorts. We should discuss this with the larger community. Can you file a bug at llvm.org and reference it from here?