Shared libraries linker error

[Guy Harris]

>[[ On this topic, I have noticed that the old select kernel call was
>retained for backward compatibility.

No, it wasn't.  "select" in 3.x was system call number 93, and "select" in
4.0 is system call number 93.  There is no "old select kernel call" in
4.0.

>A program that uses "select" and that is compiled and linked on a 3.x
>machine will, under most circumstances, still work correctly under 4.x
>(because it's using the old select kernel call).

A program that uses "select" "properly" and that is compiled and linked on
a 3.x machine will, assuming no other binary compatibility problems occur,
still work correctly under 4.x under *any* circumstances (modulo bugs in
4.x).

A program that uses "select" "improperly" - i.e., passes in pointers to
"int"s rather than "fd_set"s, but passes the result of "getdtablesize()"
as the first argument under the assumption that it will always return a
number less than or equal to the number of bits in an "int" - is quite
likely to fail under 4.x. 

Replace "3.x" with "4.2BSD", and "4.x" with 4.3BSD, and the above
statements are pretty much correct; the change to "select" from 3.x to 4.0
is a change from the 4.2BSD version to the 4.3BSD version.  I don't know
whether the 4.2BSD or SunOS 3.x documentation made it clear that it was a
bad idea to use "getdtablesize" - or, at least, to use it without cutting
its value off at 32 - because the system might be changed to support more
than (# of bits per "int") file descriptors, or not; it may well have
*encouraged* the use of "getdtablesize()", which is unfortunate. 

>But before you can compile it on a 4.x machine, you *must* make some
>changes.

Only if you've been using "select" "improperly", as indicated.

[[ I realized that there didn't need to be two separate kernel calls just
the other day while tracking down yet another select related bug.  When I
saw the described behavior (a 3.x executable that uses select still
working under 4.0) I assumed that they had just retained the old call.
After delving into things deeper, I know *exactly* why things work the way
they do.  An fd_set is an array of longs holding the bitmask.  The first
long corresponds to the *lowest* numbered file descriptors.  Therefore, if
you never use a "width" greater than 31, your program stands a very good
chance of working under 3.x (also 4.2BSD) as well as 4.x (also 4.3BSD),
because the kernel will never need anything beyond the first long.  Neat,
huh?  As for using select "properly" under 3.x, please tell me where in
the 3.x documentation it is stated that one must use a fd_set pointer in a
select call.  The manual page sure doesn't say anything about it.  It also
encouraged the use of "getdtablesize", unfortunately.  Although fd_set was
defined in <sys/types.h>, none of the macros associated with it were
defined anywhere (much less documented).  This all made it rather hard to
use select "properly" under 3.x.  --wnl ]]