[gobolinux-users] Source repositories and other suggestions
gobo-users-dufus at wotfun.com
Wed Nov 29 00:24:17 UTC 2006
On 11/29/06, Martin Baldan <martinobal at gmail.com> wrote:
> Let's see if I got it: "linked against" libraries are the ones the
> executable will "ask for" when run; that is, the program will search for a
> file in a specific location, and this is embedded in the program's object
> code. But in this location there is a link pointing somewhere.
> SymlinkProgram decides where this link should point to (the "linked in"
> library) and creates the link.
On another system, the /usr/lib/foo.so.0 file would just be overwritten.
> For instance, you say:
> > For example my firefox links against
> > /System/Links/Libraries/libpangocairo-1.0.so.0 (part of
> Pango), so I can
> > use any version of Pango that has that library version and the one linked
> > in atm is which firefox would use, as the link
> > /System/Links/Libraries/libpangocairo-1.0.so.0 is updated
> to reflect which
> > version of Pango that is active. So far I can select which version to use.
> So, /System/Links/Libraries/libpangocairo- 1.0.so.0 , the
> "linked against" library, is just a link, regularly updated to the "active"
> version, the real library that will be used, right? For instance, in my
> system it now points to
> , which in turn points to libpangocairo-1.0.so.0.1302.0 , which I guess is
> the actual library that will be loaded.
> Now my point is, even if Firefox does not require a specific version of
> libpangocairo (such as libpangocairo-1.0.so.0.1302.0) but only a version
> range (such as libpangocairo-1.0.so.0 ), I think there could be a file (or a
> database) with updated information about which specific versions of the
> libpangocairo-1.0.so.0 version range have been actually tested (even users
> could automatically help with the tests, and create a shared pool of
> knowledge about actual, tested compatibilities). So, if
> libpangocairo-1.0.so.0.1302.0 has been tested with firefox, it can be
> automatically "linked in" by SymlinkProgram . If none of the available
> versions have been tested, the system may warn the user, who would decide
> what to do (try untested libraries or wait until they are tested). The
> update manager would check for newly tested library versions from time to
> time, and either update the links automatically or ask the user. I think
> your XChat example illustrates, rather than contradict, this concept.
> In other words, what SymlinkProgram would do is that, instead of just
> "linking in" the libpango version found in /Programs/Pango/current , it
> would also check that this version is present in, say,
> (if you are compiling Firefox2.0)
So you're envisaging a system where you have to re-run SymlinkProgram,
for every installed program, every time you run or compile something?
I don't see how else you can effect this (on Linux; Plan9 and possibly
Hurd could do it).
On another (i.e. non-Gobo) system, /usr/lib/libpangocairo-1.0.so.0
would just be overwritten with a new symlink to
libpangocairo-1.0.so.0.1302.0 when you installed this version. There
should be guaranteed compatibility for all versions holding that
symlink; if not, it's the library that's broken and it needs to be
fixed. Libraries with the same name should hold ABI compatibility.
XChat fails in that case because OpenSSL imposes stringent versioning;
there's a new library version for every numbered release. I believe
there are security concerns involved with that. When you compile
XChat, it finds the current version of OpenSSL and links against it.
Minor versions (0.9.8c/d/e) do maintain compatibility, I think, but
0.9.9 would not. There's an additional level of paranoia there that
you don't get with others.
It mightn't be a bad idea for Compile or SymlinkProgram to give a
warning, and possibly run a check on what linked against the old
version when OpenSSL is upgraded. That would avoid people accidentally
breaking things by uninstalling old versions that were still in use.
More information about the gobolinux-users