On Mon, 7 Jul 2003, Todd Vierling wrote:

> The issue I'm pointing out is not upgrading from pkgsrc to src/. It's
> upgrading from one pkg version to another.

I believe it's likely that a lot of users *are* going to upgrade from
pkgsrc libstdc++.so.5 to src libstdc++.so.5, so we ignore the issue at
our peril.

> 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.

> 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? That could work,
if we're allowed to drop support for a.out. I wonder about Darwin.
Does Darwin have ELF-like symlinks?

> : Maybe it would be wiser to make /usr/lib/libstdc++.so.5 a symlink
> : into ${PREFIX}/lib (same for libgcc_s.so.1)?
>
> I'm a little afraid that a libstdc++ build from src/ may not be perfectly
> ABI compatible with one built from pkgsrc because of compile-time autoconf
> detection differences -- so this is probably *not* a good idea.  (This
> happened, for instance, with openssl, where the pkgsrc version was NOT ABI
> compatible with the src/ version once the src/ version was updated.)

The OpenSSL schism was due to a deliberate decision to remove IDEA and
RC5 from base, yet no-one bothered to do so in "pkgsrc". I didn't see
the need myself, at the time, but in hindsight, we should have tried
to keep them synced from the beginning. (Currently, base and pkgsrc
OpenSSL do have the exact same codebase.)

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. 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?

Frederick