[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Pkgsrc on linux, defective by design ?
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
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
Appending of -L/usr/lib64 will alwas lead to linking against native
libs when they are present on the system which not always desired.
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)
Main Index |
Thread Index |