[PLUG] RPM/lib question - solved

Terry Griffin griffint at pobox.com
Sun Mar 20 17:34:04 UTC 2005


On Sunday 20 March 2005 9:06 am, Terry Griffin wrote:
> On Saturday 19 March 2005 10:15 pm, Paul Heinlein wrote:
> > On Sat, 19 Mar 2005, Terry Griffin wrote:
> > > On Saturday 19 March 2005 5:24 pm, Paul Heinlein wrote:
> > >> On Sat, 19 Mar 2005, Terry Griffin wrote:
> > >>> I don't know where you get that. If you say:
> > >>>
> > >>>   gcc somefile.c -lsomelib
> > >>>
> > >>> then ld is going to look for libsomelib.so. If it finds it then
> > >>> that's the reference that will go in the binary even if
> > >>> libsomelib.so is a symbolic link to libsomelib.so.X (which it
> > >>> often is).
> > >>
> > >> Without trying to sound like I know what's *supposed* to happen,
> > >> that's not the way it works on my box (CentOS 4.0, gcc 3.4.3,
> > >> glibc 2.3.4). If I do a general -lz, it appears to me that the
> > >> linker unravels the symlinks. Or is this a bad test?
> > >
> > > Curious. I get that with libz also (FC3). But if I build my own
> > > .so library then gcc behaves in the way I described. In fact I
> > > can mix libz and my shared library in a single app and get the
> > > two different types of references in the app's binary.
> > >
> > > The possibility that it's following the symlinks doesn't make
> > > sense. My libz symlinks are:
> > >
> > >  /usr/lib/libz.so -> libz.so.1.2.1.2
> > >  /usr/lib/libz.so.1 -> libz.so.1.2.1.2
> > >
> > > The -lz switch would take you to libz.so. From there gcc could
> > > easily hop to libz.so.1.2.1.2, but getting from there back to
> > > libz.so.1 would be very weird and very inefficient. But somehow
> > > that's what ends up in the app binary.
> > >
> > > There's some magic going on under the hood I think.
> >
> > What do you bet it's the "-soname" option passed to the linker when
> > building the library? From the ld(1) man page:
> >
> >    When an executable is linked with a shared object which has a
> >    DT_SONAME field, then when the executable is run the dynamic
> > linker will attempt to load the shared object specified by the
> > DT_SONAME field rather than the using the file name given to the
> > linker.
> >
> > -- Paul Heinlein <heinlein at madboa.com>
>
> Bingo. If I build my shared library with the -soname option and then
> link my app to that library, the name given by -soname is what ends
> up in the app's binary, not the actual name of the library file.
>
> Now back to the original RPM question, the answer is the infamous
> "it depends."
>
> 1) If the library is built without the -soname option, then the .so
> file must go in to the library's main binary package, not the -devel
> package.
>
> 2) If it is built using -soname, then a file or symlink matching the
> name given by -soname must go in the main binary package. The
> original .so file may go in to the -devel package instead of the main
> package.
>
> 3) If you're not sure how the library was built then follow #1.
>
> Terry

Following up on myself...

I figured there had to be a easy way to determine if -soname was
used to build the library, and there is.

   objdump -p /path/to/binary-lib-file.so | grep SONAME

You'll get nothing if -soname was not used or the SONAME value
if -soname was used. With this you can figure out what needs to
go in the main RPM and what can go in the -devel RPM instead.

Terry



More information about the PLUG mailing list