Re: Pkgsrc on linux, defective by design ?

[Ross Cameron <abalour%gmail.com@localhost>]

Out of total curiosity (and I know I shouldn't be asking this but
anyhow) WHY are you trying to use PKGSRC on CentOS?
    There is little sense to be made of that.

CentOS by choice ships older (known stable and secure) code and PKGSRC
by comparisson (in many cases not all) ships newer releases. There are
conflicting ideals at work here and you will have issues as a result.

You will find that PKGSRC works much more happily on something like
Fedora 13 for example.
    Although I find a Slackware derivative like a very minimal Slax
the most comfortable with PKGSRC

And to add to it.... almost anything you could possibly need you will
find in a binary form compiled for CentOS/RHEL/OracleEL in a repo.
thats what the package manager is there for and in any case you can
quite easily build RPMs against CentOS and host you're own repo quite
easily.

What is it that you are trying to accomplish?



"Opportunity is most often missed by people because it is dressed in
overalls and looks like work."
    Thomas Alva Edison
    Inventor of 1093 patents, including:
        The light bulb, phonogram and motion pictures.




On Wed, May 19, 2010 at 4:53 PM, Youssef Ghorbal <djo%pasteur.fr@localhost> 
wrote:
> 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)