[Gllug] pimping my elf

[Alex Sayle]

On 18 Jun 2006, at 12:50BDT, Nix wrote:

> On Wed, 14 Jun 2006, Alex Sayle stated:
>> it looks a bit like <somepath>/bar/<version>/{lib,include,share} so
>> we can have multiple libbar's co-existing.
>
> I do this, roughly, using GNU stow. epkg, DEPOT, STORE and other  
> systems
> do much the same (with ever-increasing degrees of flexibility and
> byzantineness).

I'm aware of stow and it works nicely when you have <somepath>/bar/
where bar is your package, as we have version in the path this poses a
problem :-/

>> For simplicity we then take bar/<version>/lib/libbar.so.<version> and
>> install into a central LIB directory. For some historic reason when
>> we do this the libraries are renamed to libbar-<version>.so.
>
> The first part should be a matter of course, with every active  
> thing in
> the installed tree being symlinked into the stow tree (/usr/local or
> whatever). Arrange for apps to look into the stow tree instead of the
> installed tree for everything, and you're home free.

True. this however does relay on only one version of each package
being present in any given stow tree. One of the biggest reasons we
have the full version in the library name is so that we can distinguish
and allow co-habitation of minor revision changes in libraries.

Which in fact the show stopper for stow.

<snip />

> Note that at no point here are libraries hex-edited! The soname of a
> library is part of its published ABI and should *not* be changed.  You
> can rename the library all you like and ldconfig will create  
> appropriate
> symlinks for you if they're missing (although because those symlinks
> aren't stowed, I'd recommend against it; it'll cause you problems when
> next you upgrade when the symlinks break).

what I'm after is the explicitly and not the warm fuzzy feeling of  
ldconfig.
Two minor version needs to be linked against separately and  
explicitly so
ldconfig-ing them again doesn't work :-/


>> this name change can be an issue and rather than going against the  
>> grain
>> I'd like to get it working as is. So, here's the question, does  
>> anyone
>> know a non hexedit or binary sed hackery way to change link  
>> targets  in a an elf binary.
>
> You could do it with libelf, but it would be annoying. Among other
> things, if the new name is longer than the old you may have quite a  
> lot
> of work to do if the DT_NEEDED tag value needs expanding.
>
> There's never a need to do this unless the library doesn't bother to
> maintain its sonames properly (and virtually all of them do), and by
> doing this you *destroy* any chance of interoperability with other  
> Linux
> systems. ELF handles this stuff for you; don't make your life  
> difficult
> by shooting it in the foot.

correct. interoperability isn't, hasn't been and never will our goal  
tho.
As for shooting myself in the foot... well that's the great part about
unix isn't it :) Its always got a bit rope for me to hang myself.

The entertaining bit about the environment I'm on is that this semi
madness has so far prevailed and has flourished, somehow with out never
having to link FOSS to FOSS. A lot of software has been written in-house
which people write linker scripts for and thus are happy to link against
the name changed version of libbar-<version>.so.

As far as I can tell,this is the first time that there has been a  
need to
do build code that uses pkg-config and friends to determine linker flags
(which of course spits out libbar.so.<version> which the originals  
are called)

<snip />

>
> libelf, and pray. Hard.

I was more thinking of libbed and objcopy to re-compose the libraries
from its chunks. The field which hold the names in .dynstr section
aren't long enough in many cases so that the elf header needs updating.

--
[----------------------------------------------------------------------]
  Alex Sayle                                     alexs at alphacomplex.info


-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug