[Bug libgcj/21741] New: Need configure option to set java.library.path

[Bug libgcj/21741] New: Need configure option to set java.library.path

[green at redhat dot com]

We need a configure option to set java.library.path.

Right now libgcjawt.so in installed in ${prefix}/lib.

In FC4 we use java-gcj-compat to create a libjawt.so symlink in
/usr/lib/jvm/jre/lib/i386 (via alternatives).    Programs running
System.loadLibrary("jawt") should find this without users having to set
LD_LIBRARY_PATH or -Djava.library.path.  One answer is to let packagers set the
default java.library.path at configure time.

-- 
           Summary: Need configure option to set java.library.path
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: green at redhat dot com
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug libgcj/21741] Need configure option to set java.library.path

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-24 19:52 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-05-24 19:52:41
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug libgcj/21741] Need configure option to set java.library.path

[debian-gcc at lists dot debian dot org]

------- Additional Comments From debian-gcc at lists dot debian dot org  2005-08-16 10:32 -------
This doesn't solve the problem, that the library is not found, when the .so and
.la files are missing, i.e. if the -dev or -devel part of libgcj is not installed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug libgcj/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-08-16 15:39 -------
*** Bug 23403 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fitzsim at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug libgcj/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-08-16 15:41 -------
libjawt.so is in the base package, so it will be found as long as
/usr/lib/jvm/jre/lib/i386 is in java.library.path.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug classpath/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fitzsim at redhat dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug classpath/21741] Need configure option to set java.library.path

[mark at gcc dot gnu dot org]

------- Additional Comments From mark at gcc dot gnu dot org  2005-08-24 16:08 -------
Note that since 0.15 GNU Classpath has the following system property:

* New system property "gnu.classpath.boot.library.path" can be specified
  to define the location of the JNI libraries. It is by all means meant
  ONLY for VM implementors and GNU Classpath hackers. See the hacking
  guide for more information.
http://www.gnu.org/software/classpath/docs/vmintegration.html#SEC43

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug classpath/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug classpath/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-08-24 21:58 -------
OK, $JAVA_HOME/jre/lib/i386 needs to go in gnu.classpath.boot.library.path and
java.library.path.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug libgcj/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-09-02 01:02 -------
This is actually a libgcj bug.  I'm changing the Product.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|classpath                   |libgcj
            Product|classpath                   |gcc
   Target Milestone|---                         |4.1.0
            Version|0.17                        |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug libgcj/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-09-07 01:07 -------
It turns out that Sun handles this in a strange way.  To ensure that libjawt.so
is found automatically, Sun's java executable prepends $JAVA_HOME/jre/lib/i386
to LD_LIBRARY_PATH then re-exec's itself within the new environment.

I've just added a java command to java-gcj-compat that does the same thing only
exec's gij instead of re-exec'ing itself.

java.library.path has nothing to do with LD_LIBRARY_PATH except that its
user-visible value defaults to the contents of LD_LIBRARY_PATH.  The
argument to -Djava.library.path= should be added to the dynamic library
loader's search path.  So we also need to support running JAWT apps like this:

java -Djava.library.path=. gnu.classpath.examples.jawt.DemoJAWT

Currently this doesn't work.  Though the initial problem is fixed now, I won't
close this bug until this usage pattern is also supported.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741

[Bug libgcj/21741] Need configure option to set java.library.path

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-09-07 12:36 -------
Filed two new bugs for the remaining java.library.path issues:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23761

and

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23762

I'm closing this bug.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741