rtld enhancement to add osversion sub-directory search
ambrisko at ambrisko.com
Thu Feb 12 13:19:26 PST 2009
Kostik Belousov writes:
| On Thu, Feb 12, 2009 at 10:59:36AM -0800, Doug Ambrisko wrote:
| > Hi folks,
| > I'd like to discuss the idea of adding an automatic directory search
| > feature to rtld. At work we need to run 3rd party code that we get
| > as objects or even binaries that are compiled by other groups. This
| > works okay when our base OS is the same as the 3rd party but not so
| > good when we upgrade our base OS and we don't want to force th 3rd
| > party code to upgrade at the same time. Sometimes they can't since
| > legacy systems that needs to run the 3rd party code run the older
| > OS. Now WRT to FreeBSD's base libraries this isn't much of a problem
| > since the OS's lib's general bump version between releases so just
| > via the name we have unique lib's and the loader can get the correct
| > one. However, once you start to link to stuff in ports (ie.
| > /usr/local/lib) then these names are no longer unique and something
| > built for FreeBSD 4 through 7 (as part of FreeBSD's release, ie
| > pre-built packages) end up with the same name. This is a problem since
| > sticking the old version in /usr/lib/compat is a problem since it
| > looks based on name (ie. /usr/local/lib/libiconv.so.3). Things can
| > get interesting when the /usr/local/lib pulls in libc. So now your
| > FreeBSD 4 binary could pull in a libiconv.so.3 for FreeBSD 7 and
| > libc from FreeBSD 7. Interesting things start to happen!
| > What I've done for work is to teach the rtld to look for the
| > .note.ABI-tag and extract the osversion. I then put that and the
| > osversion major number (ie. 6 instead of 603000) into a "try" list.
| > Then whenever an object/lib is attemped to be accessed I look in the
| > osversion sub-directory then the osversion major and finally the
| > standard location. I even extended this to LD_PRELOAD and
| > insert this try into the path just before the object/lib if fully
| > qualified. Actually, I do it for all fully qualified things.
| > Now I can stick most things into /usr/lib/compat/6 and it just
| > works. For fully qualified LD_PRELOAD I "mv" things on boot
| > into the sub-directory for that OS. Also I had to change LD_PRELOAD
| > to accept failure if the thing wasn't found since children in herit
| > that and if it a different version that LD_PRELOAD might not be
| > applicable.
| > I don't really see a maintain for rtld since jdp when I worked with
| > him to add LD_PRELOAD. I'd like to get feed back on this idea and
| > get it into FreeBSD. It would help solve some of these issues for
| > other people as well. It definitely, made my life easier at work.
| > It would also make things easier on my FreeBSD machines, when I
| > upgrade the OS and ports but have legacy compiled things that I
| > don't want to recompile again. I could move all of my /usr/local/libs
| > into /usr/local/lib/compat/<osversion major), upgrade packages and
| > still run my old stuff. I've had issues before when OO was cross-linked
| > with libc from 6 and 7 due to this. Rebuilding OO was not fun and
| > I shouldn't have needed to.
| > There is one glitch in atleast FreeBSD 6.1 didn't put the .note.ABI-tag
| > into binaries so for now if not specified I assume FreeBSD 6. That
| > is good enough for work but I could add an env. variable to hold
| > the default. If not set then it wouldn't do the sub-directory thing
| > on binaries that are not known.
| > Loading of objects will slow done a bit since it adds extra
| > searches. It might be good enough to just do the os version major
| > and not for the complete osversion.
| > BTW, I also added a feature to look at LD32_ first then LD_
| > when running 32bit on 64bit. Legacy SW doesn't know about
| > LD32_ and just sets LD_. This way that stuff doesn't need
| > to be taught about LD32_ when it shouldn't really need to.
| There is a popular feature, unfortunately, not supported by FreeBSD
| ld.so, called Dynamic String Tokens, see
| I have almost abandoned patch that adds support for $ORIGIN, $OSREL,
| $OSNAME, and $PLATFORM. Quite amazingly, it merged with today CURRENT
| without serious conflicts.
That is an interesting feature, however, it almost seems backwards for
me if I understand it correctly. I need old binaries to find the library
it was built with and not new ones based on the base OS. The plus that
I see with their feature is for a library that has been optimized for a
specific type of CPU etc.
More information about the freebsd-arch