Re: A better ICQ client for Java (fwd)

["Robert G. Brown" <bob@xxxxxxx>]

Mr. Chio has asked some questions hat are good for FAQ lists, since they 
touch on issues that are very poorly understood by most people. At risk of 
exposing my own poor understanding, I'll share a few bits and maybe tell a
story or two.

>>> As far as the library discussions go, I have some pretty basic
>>> questions:
>>> Which libraries are being discussed here? 
>> libc (i.e libc5) or glibc (i.e libc6)
>These are the libraries I need if I want to compile source.  How do
>these relate to the *.so libraries (go ahead and laugh if they are one
>and the same!)  Are there compatibility issues with the shared libraries
>also?
These are the same... "libc" is short for a name like libc.so.5.3.12,
which the verison of libc I have in /lib
 
>>> Why do different libraries exist?
>>libc5 contains some "not totally free" code and I've been told is not thread
>>safe.  glibc (libc6) is completely GNU and is thread safe.
>Ok, so if all the distributions move to glibc, then everything will be
>cool and groovy.  Is that all there is too it?
Sort of. the issue here is that the libraries, along with everything else,
keep on evolving, either becasue of bug fixes, or becasue the needs of the
users keep changing. Hardware also changes, and so on. Now, these things
change slowly, only about as fast as the linux kernel changes (which is warp 
spped compared to most commericial OS'es, but not as fast as most apps or
error patches.  Otherwise, we'd have 10-15 versions of libc out there, and
no one could compile anything with confidence.

I've built shared libraries for families of applications, and after a while it 
got very hard to add anything to the library, and almost impossible to change;
we ended up forming something like a jury to decide whether or not we would
or could add (or, heaven forfend, CHANGE) something in a shared library, and
that was with a user base of about 12, not 12 million. It was easier to build
another shared library. I think you'll find that the stuff in /lib and /usr/lib
are well organized according to some discipline into different kinds of 
operations; this is probably not the result of some grand design, but rather
a repitition of what we went through on our shared library projects.

>>>Why don't they have the same functions in them? 
>>They do but the linking may be diffrent.  Thus a program "compiled" on one may
>>not run with the other but source code should "compile" cleanly on either. 
>So if I don't mind compiling, and the source is available, I'm still in
>the game.  But this situation makes the packaging systems worthless,
>right?
Well, not worthless, that's a strong term... I'd go with "a lot less valuable".
Various packaging system do a lot more for ya that just archive a bunch
of executables. They also have configuration files, documentation, HOWTOs,
man pages, and so on. Most of this ain't gonna change if you recompile the 
source with a different lib. often you can recompile and simply put the
new executable where the old one was, and you're in business.

But do you want to be FORCED to do this? How about doing it for about 300
programs, or maybe more?

>>> If the same functions are present, are they called in different ways? 
>> Yes,  but linking is a compilcating thing the average user/programmer doesn't
>> really have to concern oneself with.
>>> If so, why? 
>> Ask Bob.
>Funny!  Like he isn't busy enough (and as if I would understand
>linking)!
I'm never too busy to answer these questions, for lots of reasons.... it may
just take some to for me to get around to them. Just remember, I have never
taken any computer classes in my life, but I've taught a few....

Linking does one of two things:

  1. DYNAMIC linking fuses all the executable machine instruction files (the
     .o or object files) together to form a single stream of executable in-
     structions, EXCEPT for calls to library functions. The address of these
     function calls are placed in a table, so that they can be dealt with
     at run time. The resulting executable does not include the instructions
     of the library functions themselves, but where the library function is
     called, there's a couple of bytes that say "don't execute this, execute
     the address in the library pointed to by the following table entry"...
     now the program goes to the library and resumes execution.

  2. STATIC linking takes everything that is used by the program and links it
     all together in one executable.  This sometimes results in VERY LARGE
     executables (I've seen 85 Mb executables), but every bit of code that's
     needed is there someplace.

There are advantages and disadvantages to each, both for technical and business
reasons. I can go into these if you like.

Since linking is done at a very low level, different linkers and libraries 
exist to do some very basic things, like exploit the features of new process-
ors, or different processor architectures. A lot of the work involved in moving
Linux to a different processor ( the Alpha, the Sparc, or the StrongArm) is in
making sure that libraries like libc support everything in just the right
format and layout consistant with the actual operations done by the chip,
since if they aren't one could have disasterous results. This is one of those
cases where you wish it fails sooner than later, as some very subtle bugs can 
persist for a longtime in ported systems before they rear their ugly little
heads, and since we're talking about an OS, they may create intractable con-
ditions.

>>>I'm assuming that the professionals must have had good reasons for
>>>doing something at one time that now seems so incredibly wasteful and
>>>counterproductive.  What were those reasons?  If they are truly good
>>>reasons, how can the LSB prevent it from happening again?
Remember that computer system designers and software people do not usually 
work together intensely. Nor do we especially want them to do so. Libraries
are another tool for keeping systems efficient, yet not closely tied to the
choices made by the chip designers, who have completely different problems
to solve.

The LSB will tend to prevent this from happening in the future precisely 
because there will be a compliance standard at that point; the next version
of libc can be released in a way that allows everyone to switch over in a
more orderly way.

I'd like to see libraries handled the same way the kernel is done. We have 
experimental kernels, and stable pre releases, why not do this with libraries?
One of the answers is that the libraries are lkess glamourous and require fine
grain and broad cooperation from developers across many products, and that 
emerges slowly. Note also that there's only ONE kernel, and people like Alan
Cox and Linus Torvalds have been really persistant about quality and focus.
That's harder to do with libraries.

>>Mostly legal reasons, and sometimes they just didn't have a means to locate or
>>communicate with each other.  Creating libraries is a great idea as it saves
>>from re-inventing the wheel with each program (how do I open a file?).  But a
>>library can't contain every possible function or it would be HUGE,  so you get
>>diffrent sets of libraries.
This is true as well; If you and I can't talk (let's say we work for competitive
companies), you and I might come up with the same design in principle, but cer-
tain details may be quite different, so much so that our software is not com-
patible.  I've been to conferences where two guys are working on the same
thing, and one is at Digital, and the other is at IBM, and they may be on that
topic, but then discussion sort of peters out... they know what the limits of 
their NDA's are.

Yes, this point speaks in part to what I wrote above about how different 
libraries are evolved. You'll get a library for different things (data 
communications, terminal handling, graphics of one sort or another, and
so on).

>Are the concerns addressed by the LSB related only to the system
>libraries, or is there more?
There are more topics, such as the use of directories, and the use of
pareticular configuration files.  Again, I'll sugest that you read those LSB
editorials on freshmeat, and follow some of the links that deal with LSB in 
more detail.

I hope this has clarified things, and there aren't TOO many mistakes.

                                                         Regards,
                                                         ---> RGB <---