Relinking binaries to new .so libs when versions change?
Andrew J Caines
A.J.Caines at halplant.com
Fri Sep 19 11:10:15 PDT 2003
Dan,
Thanks for your reply.
> > Again, a port update of a library has bumped a .so version [in this case
> > libatk-1.0.so.200 -> libatk-1.0.so.400].
> how did you update the port? ... Or you could run portupgrade -R, which
> will upgrade all the packages dependent on the one you list.
# portupgrade --new --upward-recursive --recursive --sudo --verbose --all
That tends to get everything.
> Portupgrade moves old libraries into /usr/local/lib/compat/pkg
Sometimes it does, however in cases like this one (ie. atk), it didn't.
> > Is there an elegant and quick way to relink a given binary to a
> > different version of a particular .so, eg. "mvld foo foo.so.1
> > foo.so.2"?
> Version numbers get bumped for a reason :) Running the wrong version
> library will usually result in a coredump or runtime linking error.
You snipped this bit in my message where I addressed this:
>> I'm aware that rebuilding is the right thing to do since stuff can change
>> in the libs, however experience from symlinking .so.N to .so.N-n shows
>> that this almost never results in problems.
Also,
>> Is the fact that some libs don't follow the major/minor rules[1] a/the
>> problem?
>> [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policies-shlib.html
So, I'm still interested in knowing how to do the wrong thing.
-Andrew-
--
_______________________________________________________________________
| -Andrew J. Caines- Unix Systems Engineer A.J.Caines at halplant.com |
| "They that can give up essential liberty to obtain a little temporary |
| safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 |
More information about the freebsd-hackers
mailing list