Date: Sat, 03 Oct 1998 01:38:09 +0800 From: Peter Wemm <peter@netplex.com.au> To: John Polstra <jdp@polstra.com> Cc: kent@iastate.edu, current@FreeBSD.ORG Subject: Re: ELF library questions (building and linking) Message-ID: <199810021738.BAA24087@spinner.netplex.com.au> In-Reply-To: Your message of "Fri, 02 Oct 1998 08:53:59 MST." <199810021553.IAA09440@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote:
> In article <199809300121.UAA04701@isua5.iastate.edu>,
> Kent Vander Velden <kent@iastate.edu> wrote:
> >
> > Building an ELF library questions:
> >
> > I have been trying to rebuild a few of the libraries that I use to
> > be in elf format. Is the following the correct way to build an elf library
?
> >
> > for every file:
> > cc -c -fpic file.c
> > ld -o shared/file.o -x -r file.o
> >
> > cc -shared -Wl,-x -o libA.so.1 -Wl,-soname,libA.so.1 `lorder file1 file2
... | tsort`
>
> Yes, that looks OK. A good reference is "/usr/share/mk/bsd.lib.mk"
> (if you can stand to read it).
Yep, and replace "-Wl,-soname,libA.so.1" with "-h libA.so.1", it's simpler.
> Technicallly speaking, the name can be anything. However, the
> standard ELF convention is to use just one version number. Using two
> version numbers can lull you into thinking that the dynamic linker
> will do something intelligent with them. It won't.
.. But that's an implementation issue. We *could* reimplement directory
searching and 'always use minor version >= the one built with' semantics
within the runtime linker by interpreting the encoded DT_SONAME.
The value of doing that is questionable and often hotly debated.
On one hand, doing it the current way (and the usual ELF practice) means
that you never have to directory scan or look up hints files. The named
file is either there or it isn't. You can't get much quicker than that
without static linking.
People say "but how do I use libc.so.3.0 and libc.so.3.1 on the system at
the same time"? - the answer is that a.out never ever used libc.so.3.0 in
this scenario. The old version is just wasting disk space.
And then there's the problem of people compiling with newer minor revisons
but running on a slightly older system. As an example, libc.so.2.1 -> 2.2
was caused by the addition of an obscure function called strhash().
Nobody much used it, it's not in the freebsd sources except (I think)
sysinstall. However, people building binaries with 2.2 got warnings about
the old version (2.1) whenever they ran it. And it ran anyway. If you
tried to run a program that used strhash() on a libc.so.2.1 system, it
started up, gave the warning, then got a link failure right at startup.
IMHO, the warning is useless and just causes heartache for developers and
users. Incidently, I still run some old binaries linked against
libc.so.2.x on -current systems by making a symlink from libc.so.2.3 ->
libc.so.3.1. So much for major incompatability.
And then there's the 'at most one bump per release' policy. Vendors (free
and commercial) already list things like ``Tested on FreeBSD 2.2.5, 2.2.6,
2.2.7 and 3.0-current-at-yymmdd''. We try to keep the minor revisions
approximately compatable across minor releases, so theoretically a 2.2.1
binary should run on 2.2.7, and vice versa (or that was the aim anyway).
So, the run-time warning is again less useful. The README files are
already stating the bleeding obvious - if you try and run it on 2.1.x,
then you are on your own.. There's no need for ld.so to rub this in again
and again and again and again. It's either going to work or it isn't.
Take symbol versioning in ELF. We could (in theory) avoid most of the need
for major version bumps down the track. For example, glob(3) is or was
going to cause a 3.x -> 4.x bump of libc in order to make an incompatable
change to the glob struct. With symbol versioning, we can fix it and make
a backwards compatability stub so that programs linked against an old
libc.so.3 will still work just the same. That's a small price to pay when
considering that alternative is to have both libc.so.3 and libc.so.4
mmap()ed into memory in different processes. That's a far worse VM cost.
Granted, there would have to be discipline in doing this or it could get
out of control, but the capability is there to all but avoid bumps *at all*
in the future. The only thing to justify a bump then would be a really
major interface change (eg: changing errno from an int to a #define :-),
or replacing libcurses with an ncurses implementation.
[watch the cc: list!]
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810021738.BAA24087>