Sun's Java seem to be bundling some libraries with itself like libzip and libjpeg. But the rest of the libraries like X11, ALSA, probably other are taken from the system.
As far as I know, RI uses dlopen approach, at least in some cases, see, e.g. [1].
This means that we should either bundle in all the required libraries, or use dynamic linking with the libraries installed in the system.
Bundling in X11 and mesa? :) Isn't dlopen/dlsym approach a dynamic linking? Again, some API could be missing in some systems (opengl extensions, for example), what would you suggest to do in this case? [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5011992 On 11/29/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Oleg Khaschansky wrote: > I think we should fix this problem for all libraries loaded with > dlopen on linux (i.e. for all autogenerated linux native wrappers). As > far as I recall, this problem already appeared for liblcms and libXmu. > I'd suggest to wait until we know if we'll have a generator of native > wrappers in harmony and, probably, fix it instead of making temporary > fixes in the autogenerated code. Sun's Java seem to be bundling some libraries with itself like libzip and libjpeg. But the rest of the libraries like X11, ALSA, probably other are taken from the system. I don't think that replacing dynamic linker on the system with out heuristics is the "right way". It is ld.so which should decide which library from the system should be linked with, be it /usr/lib/libXext.so.6 or /usr/lib/libasound.so.2. This means that we should either bundle in all the required libraries, or use dynamic linking with the libraries installed in the system. It doesn't seem to be a problem for anyone who uses Sun Java on a server that it is necessary to install X11 and ALSA libraries. On most Linux distributions it happens automatically using package dependencies. So I am -1 for this approach. Instead I think the wrappers should be changed to link against X11 dynamic libs directly. -- Gregory
