Re: Organization and symbol lookup for shared libraries

[Bryce McKinlay <mckinlay at redhat dot com>]

Per Bothner wrote:

> Bryce McKinlay wrote:
>
> > Its also important to remember that all of this only happens if an 
> > attempt is made to resolve a class that wasn't explicitly linked. 
> > "hello world", nor any app that only uses libgcj or other libraries 
> > that are explicitly linked with "-l", will not incur any of this 
> > overhead.
>
>
> Also, if at compile-time we reference class T using L.jar, at run-time
> we ahould only look in L.so.


I can see how this behaviour would be an advantage in some situations, 
but I'm not sure how well it would work in practice. Some issues to 
consider:

1. This forces .so names at runtime to match .jar names at compile time. 
That might not always be true, for example, .jar file names often 
reflect version numbers - you might want to use a newer version of the 
.so at runtime without recompiling the application.

2. How does the compiler express (to the runtime) that T should only be 
loaded from L.so?

3. What if T isn't compiled? Classpath behaviour would potentially be 
different depending on whether a bytecode or native version were run.

I guess all of these have possible work-arounds, but I wonder if the 
benefits are worth the potential hassles...

Regards

Bryce