Yes if the lib is not shared.
Even if it's shared it's not a problem -- each client app
use its own pointers and these are passed to server LDG. Of
course, the LDG module can't store / reuse it in other places,
it must be everytime input data pointer - an operation on it
in LDG - output data.
Forget
Mintlib there is too much work! It should be better to adapt
newlib (http://sourceware.org/newlib/)
it is fully reentrant I think
Reentrancy is only one problem of many when it comes to
linking LDG+libc, for example WongCK's problem with MagiC will
be still here.
Yes probably the best, but not universal (can't work on Magic
or TOS), but in fact it could be simply an real ldg sharable!
Yes, kernel LDG support would be interesting thing to see.
But as you see, TOS/MagiC are out then, then it's maybe better
to use SLB which offer more or less the same and are already
available for all 3 of them.
we could in
fact create 2 or 3 libc.ldg for each format the choice could
be simply done in the client lib. Yes I think this could be an
elegant way to solve the problem but we need a reentrant libc.
See above. The problem with MagiC and TOS is in using "dead
code". It's described in the (yet unpublished) document I've
mentioned, mintlib/newlib/whateverlib is terminated as soon as
LDG's main() is done and this leads to all kind of strange
problems.