[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Pkgsrc on linux, defective by design ?
Am 31.05.2010 um 21:45 schrieb Ross Cameron:
> 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.
Do you mean that pkgsrc is not the best choice for servers where packages must
be only updated for stability/security reasons?
I use pkgsrc because of extra control on the programs I install (compilation
I also find amazing to be able to do:
$ pkg_admin fetch-pkg-vulnerabilities
$ pkg_admin audit
I would like to know if people find pkgsrc not suitable for such scenario.
Was that one of the reasons for OpenBSD to make a fork?
So far pkgsrc is my first choice to build/control open-source software in
Linux/Mac/Windows/BSD and I want to understand better where it fails
> 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
> 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>
>> 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 "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)
Main Index |
Thread Index |