Sidebar on linkers detecting mismatches (started with Failed to set
David.Collier-Brown at canada.sun.com
Fri Sep 8 13:12:09 GMT 2000
Peter Samuelson wrote:
> It sounds like you want the Linux dynamic linker to check available
> system calls and fail at load time.
No, just library calls.
> So -- you are suggesting that every function that wouldn't have worked
> properly on Linux 1.0 has to have a little init stub that loads at
> library init time, checks for proper support for itself and squawks if
> you try to link it in without a new enough kernel?
No, the library **doesn't** have any stubs for functions
that can't work on the current kernel.
I guess this could
> be done, but I'd think the runtime startup cost would be significant.
> NOT that Linux really shines there anyway, because although it uses ELF
> it does *not* pull any tricks like IRIX does to "pre-link" binaries (to
> optimize the common case of no custom LD_LIBRARY_PATH, no preloading).
That's good: it's the "lazy" linking which allows
applications to run so long as they don't call
missing library functions.
> Recent versions of glibc have been using symbol versioning, but I don't
> know how it's implemented. I do know it lets you run a glibc-2.0 ABI
> program with glibc-2.1 (assuming you didn't do undocumented things of
> course). And the Linux kernel tends to keep old syscalls around for
> quite some time (though not *forever*) so that's functionally almost a
> form of versioning too.
Sounds good to me!
> All in all I think cross-version compatibility works about as well as
> one can expect, given that the kernel and libc *are* going to go out of
> sync. Take the umount(2) syscall. A couple years ago Linux got a new
> syscall for umount() that takes an extra argument to let you
> force-umount a busy filesystem. If you have a new kernel, new libc, it
> uses the new umount call. New kernel, old libc, it uses the old umount
> call. New libc, old kernel, it tries the new umount, gets ENOSYS, uses
> the old umount. Meanwhile the application is none the wiser because
> the libc umount() function hasn't changed. (I think there's a separate
> libc function exposing the additional funtionality.)
That's basically the "next step" after versioning:
dealing with back-level OSs via "updaters". In the
Multics days, I got told to write an updater and a
downdater for my new struct... which puzzled me immensely,
and started me researching what they were doing (;-))
> The only way around it that I can see would be to implement some sort
> of fast method of looking up the exact ABI of the running kernel.
> Perhaps a bitmap of features present, like you mentioned earlier,
> available for mmap from /dev or something. And there could potentially
> be a *lot* of said features, and I could foresee a lot of arguments in
> the development community over exactly how big of an ABI
> change/addition is worthy of a new status bit....
I'm luck in Solaris: you don't get to change
system calls much (;-)) If you try, my evil twin*
comes and whacks you on the head.
[* David J. Brown, head of binary computability]
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
More information about the samba-technical