[gccsdk] Dynamic library path handling

[Peter Naulls]

Peter Naulls wrote:

> This is actually mentioned in the manual, although reporting an error
> about a blank symbol could be improved.  The real issue in this case was
> the library linking to static Chox11 and DeskLib.  It would make a lot
> more sense if the linker produced an error, rather than waiting until
> runtime, if that's at al possible.

Ok, I have checked in and tested with a small XLib program shared
versions of ChoX11 and DeskLib, which worked just fine.  Now, DeskLib
contains a considerable amount of assembler, and I couldn't say for
certain without review but I think that all, if not almost all of
it is purely SWI veneers and does not call other functions.   That
assembler is of course compiled with -fPIC for the benefit of the linker
but should there be any changes I need to make?  ChoX11 is purely C.

The other more pragmatic question is to do with packaging.  I know
we've discussed at some length both on and off list about what
to do here, and I apologize that I have not been able to follow
all of the details.   Assuming that Firefox with shared libraries
works (don't know yet), there are a number of components:

- Firefox application itself, which contains implicit and explicit
shared libraries - nothing really changes here, except in regards
to the variable path to find former ones (cf earlier in thread).

- !SharedLibs with the existing content

- Shared versions of DeskLib and CX11 - separate packages, but
   as part of the !SharedLibs application (perhaps in a separate
   directory).

- Tinct, SUL as packages

- Perhaps some insistence that it requires > RiscPC in the packaging -
   plus the small matter that RiscPkg doesn't like the current Firefox
   packages much.