geki: Are you sure that this patch is still needed, please?  I thought that 
Pavel has solved it (though a bit differently).  Or am I wrong?

As long as the way the searchpaths are defined has not changed this is needed
for javaldx.

It's a duplicate of 65511.

It was done on ooo64bit02, but we forgot to brought it back to the main tree :-(


*** This issue has been marked as a duplicate of 65511 ***

I looked at your patch:

http://website.openoffice.org/nonav/source/browse/udk/jvmfwk/plugins/sunmajor/pluginlib/sunjre.cxx?r2=1.3.10.1&r1=1.3&diff_format=u

But geki's patch is more correct because his patch includes fix for
SunInfo::getLibraryPaths().  In fact, I made the same mistake until very
recently. :-)

I am going to close this ...

.

just partly fixed in m179.

geki: can you please attach new patch showing what is missing?

Created attachment 38128 [details]
second searchpath defin

Putting Jochen on CC:

Taking a look, mmmhhhh, this is _not_ as easy as it may look like.
The alternative respectively concatenated paths of "getRuntimePaths" and
"getLibraryPath" are _not_ designed to just be extended. This plugin for the
JVMFWK does only work correctly in its original implementation, only with
client/classic/hotspot JVMs, which has been proved by experiment only! The fix
for 65511 is therefor _wrong_ and needs to be backed out or corrected.

As to our knowledge, server JVM are not appropriate for OOo because of slower
start-up times and other issues.

Could you please comment, why you want to add server jvms? 

> Could you please comment, why you want to add server jvms?

Just because AMD64 does not have client jvm.

Hi JKim, this indeed is a reason. 

So, at we are on it, we probably should get it right generally. Unfortunately, I
was not able to find any jre/jdk layout documentation despite of

  http://java.sun.com/j2se/1.5.0/docs/tooldocs/linux/jdkfiles.html

Which does not seem to cover what we need. Taking a look at Solaris/SPARC, it
seems that the 64bit versions are stored under

  jdk1.5.0/jre/lib/sparc/client/64

respectively 
  
  jdk1.5.0/jre/lib/sparc/server/64

So, I have no other idea as to further split the "#ifdef"s by bitness and even
by platform (Linux, Solaris), where needed. E.g.

  char const* const* SunInfo::getRuntimePaths(int * size)
  {
      static char const* ar[]= {
  #if SAL_TYPES_SIZEOFPOINTER == 8

  #  ifdef WNT 
          "/bin/client/jvm.dll",

  #  elif SOLARIS
        "/bin/server/64/jvm.dll",
  
  #  elif LINUX
          "/bin/server/jvm.dll",

  #  else
  #    error "unknown platform"

  #  endif

  #else
  #  ifdef WNT
          "/bin/client/jvm.dll",
          "/bin/hotspot/jvm.dll",
          "/bin/classic/jvm.dll"
  #  elif UNX
          "/lib/" JFW_PLUGIN_ARCH "/client/libjvm.so",
          "/lib/" JFW_PLUGIN_ARCH "/server/libjvm.so",
          "/lib/" JFW_PLUGIN_ARCH "/classic/libjvm.so"
  #endif
....

Comments?

Jochen, I am going on vacation, so please take this over for a moment ...

I'm on vacation too :) 

Hi,

I second Kay's opinion. The LD_LIBRARY_PATH which is ultimately formed by the
return value of getLibraryPaths may depend on what libjvm.so is used. A wrong
LD_LIBRARY_PATH may lead to crashes and difficult to find errors. So what you
need to find out what directories of the JRE have to be on the path. This can be
done by testing, since this is nowhere specified to my knowledge. The other (and
safer) option is to have a look at the code of the java executable which forks
off a new process and sets the LD_LIBRARY_PATH if necessary.
Then make sure that the getLibraryPaths returns exactly the suitable paths for
the selected runtime lib (getRuntimePaths). This can be achieved by using the
ifdefs as Kay indicated.
BTW, I believe with Java 6 setting the LD_LIBRARY_PATH may not be necessary anymore.

Also assume that if the server vm is used then the client directory is the first
in the LD_LIBRARY_PATH. I bet any library in the client directory is not
intended for use with the server vm. A look into a 1.5.0_07 (linux 32bit) and
1.6.0 (linux 32bit) showed that there is only one other library which however is
a link into the parent directory.

Assuming that the LD_LIBRARY_PATH is right, that is the runtime directory,
native_threads directory, and the lib/ARCH directory are still needed, I still
recommend to make the LD_LIBRARY_PATH depend on the selected VM (similar to what
kr suggested).

That is, use the getRuntimePath as kr suggested.
Change the getLibraryPaths to something like this:

char const* const* SunInfo::getLibraryPaths(int* size)
{
 #ifdef UNX        
     static char const * ar[] = {

#if SAL_TYPES_SIZEOFPOINTER == 8
  # if SOLARIS
//probably the same as Linux, need to verify
          "/lib/" JFW_PLUGIN_ARCH "/server",
         "/lib/" JFW_PLUGIN_ARCH "/native_threads", 
         "/lib/" JFW_PLUGIN_ARCH
  
  # elif LINUX
          "/lib/" JFW_PLUGIN_ARCH "/server",
         "/lib/" JFW_PLUGIN_ARCH "/native_threads", 
         "/lib/" JFW_PLUGIN_ARCH
  #endif
#else 
         "/lib/" JFW_PLUGIN_ARCH "/client",
         "/lib/" JFW_PLUGIN_ARCH "/native_threads", 
         "/lib/" JFW_PLUGIN_ARCH
#endif
 
     };
     *size = sizeof(ar) / sizeof (char*);
    return ar;
 #else
    size = 0;
     return NULL;
 #endif
 }


jl->pjannik: Would you like to take this over? If not set it back to me. Sooner
or later, I have to take care of it anyway, but not now :)

This looks it really needs more thorough investigation, so I'll leave it for you.

Since the patch is not correct, I will set the type to enhancement. 

set target to 3.x according to http://wiki.services.openoffice.org/wiki/Target_3x

Is there any news to this? There is still only this one available. :)

/opt/sun-jdk-1.6.0.19/jre/lib/amd64/server/libjvm.so