Issue 65974 - add searchpath for server-only versions of Sun's 64bit JDKs
Summary: add searchpath for server-only versions of Sun's 64bit JDKs
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: current
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: 4.x
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-05-31 19:28 UTC by geki
Modified: 2013-02-07 21:59 UTC (History)
6 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

second searchpath defin (405 bytes, text/plain)
2006-07-29 17:07 UTC, geki
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description geki 2006-05-31 19:28:10 UTC
Summary says it.
Patch is on URL.
Comment 1 kendy 2006-06-01 09:12:26 UTC
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?
Comment 2 geki 2006-06-01 09:46:31 UTC
As long as the way the searchpaths are defined has not changed this is needed
for javaldx.
Comment 3 jkim 2006-06-01 18:38:08 UTC
It's a duplicate of 65511.
Comment 4 pavel 2006-06-01 19:00:54 UTC
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 ***
Comment 5 jkim 2006-06-01 19:53:32 UTC
I looked at your patch:

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. :-)
Comment 6 kay.ramme 2006-06-07 13:45:00 UTC
I am going to close this ...
Comment 7 kay.ramme 2006-06-09 12:38:18 UTC
Comment 8 geki 2006-07-28 11:56:04 UTC
just partly fixed in m179.
Comment 9 pavel 2006-07-29 17:01:22 UTC
geki: can you please attach new patch showing what is missing?
Comment 10 geki 2006-07-29 17:07:22 UTC
Created attachment 38128 [details]
second searchpath defin
Comment 11 kay.ramme 2006-08-04 14:18:57 UTC
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? 
Comment 12 jkim 2006-08-04 16:47:46 UTC
> Could you please comment, why you want to add server jvms?

Just because AMD64 does not have client jvm.
Comment 13 kay.ramme 2006-08-07 10:50:26 UTC
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

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



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[]= {

  #  ifdef WNT 

  #  elif SOLARIS
  #  elif LINUX

  #  else
  #    error "unknown platform"

  #  endif

  #  ifdef WNT
  #  elif UNX
          "/lib/" JFW_PLUGIN_ARCH "/client/",
          "/lib/" JFW_PLUGIN_ARCH "/server/",
          "/lib/" JFW_PLUGIN_ARCH "/classic/"

Comment 14 kay.ramme 2006-08-11 13:39:24 UTC
Jochen, I am going on vacation, so please take this over for a moment ...
Comment 15 joachim.lingner 2006-08-11 14:11:18 UTC
I'm on vacation too :) 
Comment 16 joachim.lingner 2006-08-29 09:41:34 UTC

I second Kay's opinion. The LD_LIBRARY_PATH which is ultimately formed by the
return value of getLibraryPaths may depend on what 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.

Comment 17 joachim.lingner 2006-10-18 09:41:02 UTC
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 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
         "/lib/" JFW_PLUGIN_ARCH "/client",
         "/lib/" JFW_PLUGIN_ARCH "/native_threads", 
         "/lib/" JFW_PLUGIN_ARCH
     *size = sizeof(ar) / sizeof (char*);
    return ar;
    size = 0;
     return NULL;

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 :)
Comment 18 pavel 2006-10-19 10:20:47 UTC
This looks it really needs more thorough investigation, so I'll leave it for you.
Comment 19 joachim.lingner 2006-10-19 15:15:26 UTC
Since the patch is not correct, I will set the type to enhancement. 
Comment 20 Martin Hollmichel 2007-12-07 13:00:17 UTC
set target to 3.x according to
Comment 21 geki 2010-04-03 23:17:01 UTC
Is there any news to this? There is still only this one available. :)