> Currently, the libc (for example) is compiled as a .o
> and hardlinked to every executable. This wastes memory,
> especially if I want to run collections of little C programs
> that may each rely on a lot of interesting library calls.
This is all true, however I might point out that a small program static linked
with uC-libc is _smaller_ than an ELF executable linked dynamic build with
glibc. This, BTW is why I'm still waiting to see what Uli can come up with
for EL/IA before we endorse it (here's hoping).
> Is there some semi-automatic way to ...
> ... compile a library two ways, generating the usual PIC version
> and a non-PIC version as separate files in two directories.
Library code for uClinux is actually PIC already.
> ... having the standard user linker look in a third directory
> before looking in the directory containing the relocatable version.
I have patches for that already. Wrote them when I wrote the code for the
PalmOS GNU gcc and binutils.
> ... having a script that links a specified library onto the end
> of the kernel image, then recovers the symbol table for where the
> symbols inside that library have ended up.
Handling this sort of thing is another issue. Have a look at the PalmOS
Glib shared libraries.
> ... writes a new stub library file that contains those symbol
> definitions as static values pointing into the correct locations.
I have code that can be reused to generate stub libs.
> ... stores this new library file in that third directory so
> that subsequent compilations of user programs will use the
> statically linked 'shared' library thereafter.
> ... some ploy taking the process list of a running uclinux,
> finding the relevant binaries, looking up which libraries each
> uses and determines which libraries are used three times to
> force them into the kernel and which libraries are used one
> time (or less) to kick them out of the kernel.
Well it's more likely that we would put shared libs in the filesystem
just like linux. Then what you do is have a chunk of code in crt0 map the
library file(s) and call an init routine collected into a list at link
time in a seperate section. Of course, you need to deal with private data and
that's an issue. On PalmOS Glib library data does not work the way
UN*X programmers expect.
Come to think of it, we can get library data and bss fairly easily if we
can get the linker to collect things in chunks for us. After the .data +
.bss of the program code, we collect the .data + .bss of the _entire_
shared lib. The executable will access this just as it does now and the
shared lib will offset a5 when it starts up...
Now that seems like something we can actually do...
> This message resent by the email@example.com list server http://www.uClinux.com/
This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST