[...more pkgsrc dreamland...]

On Mon, 7 Jul 2003, Frederick Bruckman wrote:

: > Because the libstdc++ ABI
: > changes from major release to major release of gcc, it's useful to be able
: > to have the runtime libs for an older version stick around -- and even *be
: > installable from binaries* even if a newer version is installed.
:
: I am (naively?) hoping that that *won't* be the case, and that
: libstdc++.so.5 will have some staying power, but I realize that
: there are no guarantees.

I'll just sit back and watch the fireworks.  8-)

I should add that I'm probably FUD'ing at myself, because libstdc++ v2 was
much more ABI-unstable if the "configure" script detected the slightest
system level differences.  libstdc++ v3, which is what is included in GCC3,
may be more resilient to this effect -- I sure hope it is.

: > This is where the runtime/devel split excels.  And it bites way too much in
: > pkgsrc:  how many times have you had to rebuild a crapload of dependencies
: > all at once because of a major version bump in some low-level package?
: > Wouldn't it have been nicer to be able to do the rebuilds in phases?
:
: Do you mean to allow two different run-times to be installed,
: reserving the ".so" symlink for the devel package?

Yes.  Several people, myself included, proposed this a while back, but the
general response is typically that pkgsrc isn't robust enough to do it yet.
The issues:

* multiple pkg registrations per pkgsrc directory (this would be nice in may
  ways, e.g. with info, libtool, gtar, where we would no longer need a
  separate build tree for "-base" and "-doc")

* ability to install more than one version of a pkg (libfoo-1.0, libfoo-2.0)
  without the implicit CONFLICTS (=libfoo-[0-9]*)

One workaround suggested was a pkg_delete/"pkg_add -u" additional flag that
would leave any .so.major and .so.major.minor[.teeny] in place.  This
doesn't help installing a binary package dependent on the older libs on
another machine, but it at least allows code to keep running.

And all this somewhat relates, again, to the fact that pkgsrc doesn't
address dependencies against shlibs -- i.e. "Which major version of this
shlib do I need?  Which package version has that?  Oops, this newer version
of my dewey dependency has the wrong major version; I'll crash now."

: That could work, if we're allowed to drop support for a.out.

You don't have to do that, because a.out doesn't care about .so symlinks --
only that the major number is monotonically increasing (i.e. the devel
package headers that are installed correspond to the highest installed major
number).

If someone on a.out were to install a newer runtime and older devel, "you
get what you deserve".  Although this case could be handled by implementing
dewey CONFLICTS (with >, not >= in this case) -- and making an implicit
conflict on devel packages:

CONFLICTS+=	${PKGBASE:C/-devel$//}>${PKGVERSION}

This would disallow installing any newer runtime without deinstalling the
older devel package first.  It would be useful even on ELF, to indicate
exactly why it's best to have a devel package that is at least as new as the
newest installed runtime.

Come to think of it, there's several places in pkgsrc Right Now where this
dewey CONFLICTS would be useful.  "postgresql-lib" vs. "postgresql-server"
comes to mind.

: I wonder about Darwin. Does Darwin have ELF-like symlinks?

I don't have experience with this -- although I've been meaning to find a
reason to install Darwin under VMware for comparison.  8-P

: Oh, I see we're not vulnerable to the same lossage that affected
: OpenSSL -- package links against base libssl, gets run-path of
: ${PREFIX}/lib for some other package, OpenSSL package gets installed,
: package now runs against package OpenSSL -- because libstdc++ isn't
: installed to ${PREFIX}/lib.

Thank goodness we have buildlink2, which, I've found, does indeed work
around this issue happily.  (Ignore all my previous comments about it "not
working"; it does.  It's just some programs here and there which try to
"reach outside the buildlink2 box" in the pkgsrc bits.)

: It'll still be a mess if a package links against a library that runs
: against package libstc++, and also another library that runs against base
: libstdc++, won't it?

That depends on whether the two dependencies are exporting C++ APIs to the
thing liking to them.  Yes, this particular case is a bad problem.  But,
you're likely to know it at link time because of symbol conflicts.

Ideally, pretty much all C++ code on a system needs to be recompiled after
src/ switches to GCC3 -- though the GCC & CodeSourcery people are trying
Hard to get it to an ABI-stable state.  It's close, but no cigar (gcc-3.4
uses major number 6).

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