[MacPorts] #54553: clang effectively ignores the LIBRARY_PATH env. variable

[MacPorts]

#54553: clang effectively ignores the LIBRARY_PATH env. variable
--------------------+-----------------------
 Reporter:  RJVB    |      Owner:
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  ports   |    Version:
 Keywords:          |       Port:  clang-4.0
--------------------+-----------------------
 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.

--
Ticket URL: <https://trac.macports.org/ticket/54553>
MacPorts <https://www.macports.org/>
Ports system for macOS