static executable w/DLL's

[Godmar Back]

> 
> For a number of reasons (primarily space and to simplify support), I'd
> like to have a staticly linked "native" libraries (ie configure using
> --with-staticlib) but still allow native libraries to be loaded.
> 
> This doesn't look possible in either the current custom or open
> versions. The --with-staticlib option appears to muddle the notion of
> pre-linked native functions and whether DLL's are actually supported
> by the underlying O/S.
> 
> I'm assuming that there's no technical reason this can't be done (right?)
> It would appear that I simply need to..
> 
> 	(a) have configure set a new variable e.g. STATIC_NATIVE_LIBRARIES
> 	    (which is effective !NO_SHARED_LIBRARIES)
> 
> 	(b) Provide macros such as SHARED_LIBRARYLOAD. If STATIC_NATIVE_LIBRARIES
> 	    is not set, simply become LIBRARYLOAD, etc.
> 
> 	(c) change the appropriate code in external.c and slib.h
> 

There is no technical reason why it shouldn't work and indeed it's on
our wishlist of things to have.

It is my understanding that Michael Koehne (kraehe at bakunin.north.de) 
submitted patches for an earlier version of kaffe to allow this;
although I frankly admit I do not know how they worked; in particular,
I do not know whether they required GNU/DLD (whatever that is).
You might want to check the mailing list archives.

If you would want to implement this, it would be very welcome.
In the extreme, you would want to be able to specify for every single
library whether it should be linked statically or not.  Grouping 
zip, net, native, io, etc. in "native libraries" may be too coarse-grained.

Of course,  most important is the ability to load dynamic libraries into
a statically linked binary that has all the native libs that are part of 
the run-time library.  So I think coming up with one or two configure
options that make the most sense would be important.

I should also point out that the "--with-staticlib" option is confusing
in that it may make people think that you get a static binary, when
in fact only kaffe's libraries (but not libc or libm) are linked statically.

> Also, at the same time, I noticed that symbol lookup in the "static
> native" libraries is done by a simple loop and strcmp. How often is
> this used, assuming you're using "static native" libraries and either
> (a) intrp or (b) jit?  Is the value looked up once per call site (and
> cached) or once per call? If it's once per call, I'll use a hashtable
> to speedup the lookup.
> 

It's done once the first time this method is called, both for intr and jit.  
Here's the relevant code for the interpreter in support.c (see
jit/machine.c for the translator):

        if (meth->accflags & ACC_NATIVE) {
                if (METHOD_NATIVECODE(meth) == 0) {
                        errorInfo info;
                        if (native(meth, &info) == false) {
                                throwError(&info);
                        }
                }
                call.function = METHOD_NATIVECODE(meth);
        }

That means it may not be worth optimizing, except to reduce startup time.
I would use gperf to create a perfect hashtable since all entries are known
at compile-time.

	- Godmar