Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Aug 2001 12:44:55 -0500
From:      Mike Meyer <mwm@mired.org>
To:        <joup@bigfoot.com>
Cc:        questions@freebsd.org
Subject:   Re: managing libraries
Message-ID:  <15226.46359.749829.315002@guru.mired.org>
In-Reply-To: <25199823@toto.iv>

next in thread | previous in thread | raw e-mail | index | archive | help
joup@bigfoot.com types:
> Is there any sort of general advice one should follow when dealing with
> multiple versions of libraries?  For instance, it seems like there are
> plenty of symbolic *.so links to the most up-to-date *.so.# file, but most
> applications tend to specify a specific number.  (Is there a reason for
> this?)

Yes, there's a reason that libraries link to a specific number. It's
to make sure the binary uses the version of the library that works, as
opposed to one that may have a different ABI, and thus fail in
unexpected ways. Generally, this happens when the binary is linked,
and the number isn't specified by the application author.

> My particular trouble tonight was a libGL.so.1 file that was referencing
> several undefined pthread functions-- I found the pthread library, added
> it to my $ldconfig_paths in rc.conf, reran ldconfig -R, and tried the
> build again (qt-linguist).  Same error.  I finally mv'ed libGL.so.1 to a
> backup file, made a symbolic link to libGL.so in its place (which in turn
> points to libGL.so.14).
> 
> Am I going to have problems later on because of this?  Is there something
> else I can do that isn't so kludgy?

Something very strange is going on here.  Where did you get
libGL.so.14? I've just got libGL.so.1.

Second, how much did you clean before trying the build again?
In particular, did you rerun the config, making sure not to use any
old values? It's normal for a config to snoop library files to figure
out what functions are available, so changing the library used may
well change the configuration for the program.

Normally, the include files used for the compile and the library are
paired, and changing the library is asking for problems. Do you know
whether the include files used by programs that want to use libGL.so
are the ones that go with .1, or .14? That will make a difference.

Oh, that general advice you asked for - try to avoid it. Rebuild
binaries to use the latest version when you update libraries across a
version number. If you can't do that, keep both versions around, but
make sure the versionless symlinks point to the version described by
the include files installed on the system.

	<mike
--
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15226.46359.749829.315002>