library compat for FreeBSD7x
mad at madpilot.net
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 foo.so.1, but program A was recompiled and itself depends
on library foo.so.2 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
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 madpilot.net>
More information about the freebsd-current