Pkgsrc on linux, defective by design ?

[Youssef Ghorbal <djo%pasteur.fr@localhost>]

Hello pkgsrc users,

        I'm trying to set up pkgsrc on a CentOS (5.4) and I came across some 
issues regarding linking against the native library VS the pkgsrc one. A 
typical exemple is libxml2.
        After some digging I found out that, no matter what happens, BUILDLINK3 
framework always add -L /usr/lib64 -Wl,-R/usr/lib64 to the gcc command line 
option. For exemple when we try to compile converters/py-libxml2 (LibXML2 
bindings for Python) the gcc line will be something like :

        gcc -pthread -shared -L/opt/pkg/tmp/lang/python26/work/Python-2.6.4 
-L/usr/lib64 -Wl,-R/usr/lib64 [....]  -L/opt/pkg/lib -lpython2.6 -o 
build/lib.linux-x86_64-2.6-debug/Ft/Lib/EscapeQuotesc.so

         The GNU ld looks for libraries in a search path specified by -L 
options in the order of appearence. In my case, the EscapeQuotesc.so will 
always be linked against the native libxml2 lib beacause of the precedence of 
-L/usr/lib64 in the command line.

        What I can't understand, is why the BUILDLINK3 framwork keeps appending 
a default path (/usr/lib64) while it's completely useless and leads to bogus 
beahaviour like the one I explained. For me a sane way of doing will be to only 
append pkgsrc specific paths using -L option. GNU ld looks for libs in priority 
in the search path specified by  -L options and will fail back to system 
"default" paths.

        Appending of -L/usr/lib64 will alwas lead to linking against native 
libs when they are present on the system which not always desired.

Youssef Ghorbal

PS : the /usr/lib64 is added in the pkgsrc/mk/buildlink3/bsd.buildlink3.mk file 
(line 350 for the creation of "lib64" based on the ABI  and line 379 for the 
appending of /urs/lib64 to the BUILDLINK_LDFLAGS variable)