Sidebar on linkers detecting mismatches (started with Failed to set gid privileges)

[David Collier-Brown]

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.


--dave
[* 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