library compat for FreeBSD7x

Guido Falsi mad at
Thu Jul 23 12:15:24 UTC 2009

On Thu, Jul 23, 2009 at 01:40:57PM +0200, Ruben de Groot wrote:
> > > 
> > > Erm, doesn't that defeat the whole point of having compat* libraries?
> > 

BTW, why don't you just let the old libraries lie in your system, or use
libmap.conf just to map them to the newer ones? As long as there is no
ABI breakage this will work.

> > The problem is that while a single port directly depending on a compat
> > library may work indefinitely this way, you'll have many problems when
> > you mix and match ports depending on libraries from other ports, mixing
> > ld and new libraries dependancies.
> Can you give a concrete example of this? I've never had any such problems.

If port A depends on library from port B which itself depends on library
in base system, but program A was recompiled and itself depends
on library ld could have an hard time linking them at runtime I

Anyway, I think someone with better uderstanding of the internals of ld
can give better explanations.

Anyway this is academic, for yhow I understand it, symbol versioning
will solve this in a not too far future...

> > I never used the compat bits, but I really think they are there for
> > software you have just in binary form, and no way to recompile.
> That may be the main reason, but there can be many others.
> For example, I'm still using the subversion 1.5 client compiled on 6.x
> because the newer version from ports (1.6) doesn't play nice with eclipse
> (subclipse).

You have the sources, you could anyway recompile an old version.

> > If recompiling all ports is problematic just wait a few days and uupdate
> > using packages...
> Updating using packages might not be an option at all. Example: mod_php5

If you manage many servers you should anyway have a machine to make your
own packages too and roll those ones out to production machines, I

Guido Falsi <mad at>

More information about the freebsd-current mailing list