Hi libtoolers, I've just re-implemented a part of kaffe's native shared library loading mechanism to use LTDL_SHLIB_EXT when possible with libtool in GNU Classpath. That was fun, and actually seems to work fine now. So, I figured I could maybe offload a larger part of that onto libtool:
The Java API spec includes a method that allows programs written in the java programming language to map shared library names to system-dependant full library names, and get that name back. So 'something' would be mapped to 'libsomething.so' or 'cygsomething.dll', depending on the environment. Some larger free software applications written in the Java programming language, like Eclipse 3.1, depend on correctly mapping the library names to load their plugins, that in turn contain native shared libraries. (That was the reason why Eclipse 3.1 had refused to start up properly on Kaffe for a while, and thanks to Tom Tromey, I hunted down the cause and fixed it.) It would be nice if libtool provided a way to either map a short dynamic library name to a full name (say, something -> libsomething.so) or offered an autoconfish way to get the platform-specifc shared library prefix, like it does for the suffix. I've seen that a similar problem occured for GNU readline on cygwin[1], and they went for a platform-specific set of properties in the makefiles. I guess it would be more efficient if libtool provided a central API for that, rather than to see projects reinventing the wheel. It also seems that ltdl.c uses the "lib" prefix specifically in one case [2] , where it may or may not make sense to use a hypothetical LTDL_SHLIB_PRE. cheers, dalibor topic [1] http://lists.gnu.org/archive/html/bug-bash/2005-08/msg00007.html [2] ltdl.c from HEAD: 812 if (strncmp(p, "-l", 2) == 0) 813 { 814 size_t name_len = 3+ /* "lib" */ LT_STRLEN (p + 2); 815 name = MALLOC (char, 1+ name_len); 816 if (name) 817 sprintf (name, "lib%s", p+2); 818 } _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
