Subject: Re: PKGCONFIG_OVERRIDE only for buildlinking (not for installed *.pc
To: None <tech-pkg@NetBSD.org>
From: Jeremy C. Reed <email@example.com>
Date: 03/03/2006 18:09:30
Thanks for the emails Greg and Todd. I have some responses below to both
On Fri, 3 Mar 2006, Greg Troxel wrote:
> It would help in the example to explain what prefixes are used for
> what; I'm guessing /home/reed/pkg is the PREFIX for pkgsrc, and that
> instead of /usr/pkg/xorg you are using /home/reed/xorg, but I'm not
> confident. Or do you have an entirely separate pkgsrc installation
> there with X11_TYPE=xorg.
Sorry. Yes, /home/reed/pkg/ is the PREFIX for pkgsrc.
/home/reed/xorg/ is not related to pkgsrc at all. It is the destination of
building the Xorg CVS without using pkgsrc framework.
Note that building Xorg needs outside software, like Mesa, fontconfig,
freetype2, libtool, pkg-config, autoconfig (and friends), for example. And
yes, I am getting them from my pkgsrc install (/home/reed/pkg/).
I also have modular xorg packages installed from pkgsrc-wip. These install
direct to /home/reed/pkg/ and not to any specific subdirectory.
That is my problem :) I am trying to work on two different projects at the
same time. Both using the same tools/dependencies (freetype2, libtool,
pkg-config, autoconfig, etc).
> Are you trying to use libraries built from pkgsrc but use dependencies
> other than the ones they were built with? That seems at least
No, I am not. I am attempting to build non-pkgsrc related code without
using pkgsrc infrastructure ... but still using some components as
installed previously with pkgsrc.
> I agree with Thomas and believe that the .pc file installed by pkgsrc
> should be sufficient for a random non-pkgsrc program to build against
> the pkg libs by including the usual pkg-config invocations on the
> command lines. So that pretty much requires -R in the libs line in
> pc, unless we instead choose to teach pkg-config to output -R
> automatically for all -L lines.
That sounds like an interesting idea.
> It would be cool if the linker could have a way to record RPATH for
> particular libraries, instead of one global path. I suspect this is
> really at the root of your problem.
> > I want the above to use fontconfig and freetype as installed via pkgsrc
> > (/home/reed/pkg/lib). And for all X libraries use my new versions
> > (/home/reed/xorg/lib). Any ideas on how the above should be ordered? (I
> > have tried a few different ways with no luck. The only way that does work
> > for me is to remove the "-Wl,-R/home/reed/pkg/lib".)
> If I understand (which I'm not sure I do), I think what you are doing
> is wrong from the pkgsrc orthodoxy viewpoint - you are trying swap out
> a library that you know is ABI compatible from the one the pkg was
> built with.
I am not meaning to do that. I do not want to use the wrong library. I
want to use the correct library.
> Or, if you aren't trying to do that, you're perhaps losing because of
> the global RPATH limitation where a library other than what the pkg
> was built with is getting picked up.
> > My workaround is to remove all the libraries and pc files for the
> > identical software. But I prefer not having to do that. And I prefer not
> > having two installations of pkgconfig, freetype2, fontconfig.
> It might help to provide ldd output of the 'correct' and 'incorrect'
> builds, and also a top-level ddescription of what you are trying to
The ldd for the correct build points to my /home/reed/xorg/lib/libX11.so
for example. The incorrect build points to my
/home/reed/pkg/lib/libX11.so. (Sorry I don't provide an example.)
> I'm starting to move towards running xorg servers (915 chipset,
> pci-e in 955, not sure about 945 chipset) and beginning to struggle
> with this, and wonder if I'll run into the same issues. But so far
> I'm inclined to use the server only, and not the client libs - to
> avoid dealing with these issues.
My situation is probably rare. And I should probably just ignore it. Using
pkgsrc to build and install Xorg works just fine :)
On Fri, 3 Mar 2006, Todd Vierling wrote:
> Unfortunately, there is no such thing as a per-library rpath -- either you
> have an rpath, or you don't, and it applies to all libraries directly loaded
> by the binary (shlib or application) being built with the -R option.
> The rpath, while global in the built binary, *is* ordered, which is why
> removing the -R for /home/reed/pkg/lib worked; the ELF runtime linker is now
> searching in /home/reed/xorg/lib first, as it's the only one left in the
> rpath. However, that is not an argument in support of removing the -Rs
> from pkgsrc's .pc files.
As a workaround, I manually added -Wl,-R/home/reed/xorg/lib to be earlier
that the rest of the library flags. I wonder if there is someway to get
configure or libtool or pkg-config to always do that for me.
> I think what you really want here is the ability to detect "builtin"s in
> more than just the default /usr location. That way you can build xorg
> directly, then rebuild pkgsrc packages to use that rather than one in the
> pkg tree.
I am not sure I understand.
For now, I will just move or remove my "pkgsrc" modular Xorg work when
doing xorg work not using pkgsrc. Or use two different pkgsrc installs
Jeremy C. Reed
BSD News, BSD tutorials, BSD links