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