On Tue, 17 Jun 2003, Jeremy C. Reed wrote:

: > "Sorry, not pkgsrc's fault."
: >
: > If the needed libraries aren't on the destination system, what guarantee do
: > you have that pulling in a pkgsrc-compiled version (for your FORCE_DEPENDS
: > proposal) is in any way ABI compatible with the base-system version found on
: > the build box?
:
: I don't see how that would happen.
:
: With the option defined, not only would it force the DEPENDS but it would
: build that dependency and use it. (So if the build system had an openssl
: in base system, then it would now get two installs of the openssl and the
: software would use the LOCALBASE version by building with buildlink2.)

Okay, so you actually want to build the dependency on the build box that
also has the dependency in the base system.  I didn't catch that particular
part.

You're treading on runtime linker thin water by proposing that there be a
blanket option for this purpose.  Think "same soname but different ABI and
accidentally linked from the wrong place thanks to rpath ordering".  Or
worse, "the rpath wasn't set in the same order as the -L options, so I
linked against the one in /usr/lib with its soname that is different from
the soname of the pkg".  These mismatches are rare, but possible (and has
happened in the past with openssl), since a blanket option means that people
won't check for this case on a per-package basis.

BTW, don't put all your faith in buildlink2, yet.  Not all the buildlink2.mk
files DTRT -- some exist that effectively set CPPFLAGS+=-I${PREFIX}/include
LDFLAGS+=-L${PREFIX}/lib [!!!].  See devel/gettext-lib for an example.

I still have to wonder why you are building packages on a system that has a
different set of base libraries installed from the target system.  That will
still bite you in the ass in other ways even if package registration is
forced (as there are still a few times that pkgsrc looks for /usr/something
as a conditional outside of buildlink2 files).

-- 
-- Todd Vierling <tv@pobox.com>