[Bug libgcj/17311] New: Wrong libgcc_s.so.1 is used by lt-gij

[Bug libgcj/17311] New: Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

libtool doesn't put the right path in lt-gij when building it to be used during
build:

# readelf -d ia64-unknown-linux-gnu/libjava/.libs/lt-gij

                                                                                
Dynamic section at offset 0x2460 contains 33 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libgcj.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6.1]
 0x0000000000000001 (NEEDED)             Shared library: [libunwind.so.7]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6.1]
 0x000000000000000f (RPATH)              Library rpath:
[/export/build/gnu/gcc-3.4-redhat/build-ia64-linux/ia64-unknown-linux-gnu/libjava/.libs:/usr/gcc-3.4-redhat/lib]
 0x000000000000000c (INIT)               0x4000000000000980
 0x000000000000000d (FINI)               0x4000000000001ac0
 0x0000000000000019 (INIT_ARRAY)         0x6000000000002418
 0x000000000000001b (INIT_ARRAYSZ)       24 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x6000000000002430
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000004 (HASH)               0x4000000000000238
 0x0000000000000005 (STRTAB)             0x4000000000000560
 0x0000000000000006 (SYMTAB)             0x40000000000002f0
 0x000000000000000a (STRSZ)              584 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000070000000 (IA_64_PLT_RESERVE)  0x60000000000026c8 -- 0x60000000000026e0
 0x0000000000000003 (PLTGOT)             0x60000000000026c8
 0x0000000000000002 (PLTRELSZ)           264 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x4000000000000878
 0x0000000000000007 (RELA)               0x4000000000000800
 0x0000000000000008 (RELASZ)             120 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x40000000000007e0
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x40000000000007a8
 0x0000000000000000 (NULL)               0x0

The gcc build directory needs to be in DT_RPATH. Otherwise, the wrong
libgcc_s.so will be used.

-- 
           Summary: Wrong libgcc_s.so.1 is used by lt-gij
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-09-03 20:46 -------
Most likely, this is also due to automake passing the wrong -B directories to
libtool/gcj while building libjava. 

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-09-03 20:52 -------
I don't think so. The problem is similar to bug 16633.

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-09 03:42 -------
Is this fixed?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-09-09 16:25 -------
No. Although the nature of this bug is the same as bug 16633,
they requires different fixes. I posted 2 patches to fix this
bug. The first one is

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00663.html

and the second one is

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00836.html

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-09-14 18:42 -------
The updated second patch is at

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01449.html

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-09-16 00:11 -------
An updated second patch is at

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|0000-00-00 00:00:00         |2004-09-16 00:11:49
               date|                            |


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2004-10-11 20:13 -------
I read through these patches a little.

I don't understand why ltmain.sh is the way it is,
but Gary's comment seemed appropriate.
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02333.html

Doesn't the second patch eliminate the need for
the first one?  I still don't understand why the
second patch is needed, though.  To me it looks like
libjava.exp:libjava_init initializes the various
forms of LD_LIBRARY_PATH appropriately, finding libgcc_s.so.
Can you tell me why this doesn't work?


-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-10-11 20:32 -------
See

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02467.html

I don't know how to do --disable-fast-install for gcc.
--enable-fast-install is totally wrong for ELF. It should
never be used for any ELF targets.

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2004-10-11 20:49 -------
I read that.  What I observe is that .libs/gij is created
by the build.  Then if I run gij (not .libs/gij), it creates
.libs/lt-gij.

My understanding is that --enable-fast-install is what makes
all this work as it does.  .libs/gij has the install tree
in its DT_RPATH -- but that is ok since this executable is never
run from the build tree.  It exists only so that installation
can be as simple as "cp".

.libs/lt-gij is relinked lazily, when gij is run.  Its DT_RPATH
is:

opsy. readelf -d .libs/lt-gij |grep RPATH
 0x0000000f (RPATH)                      Library rpath:
[/home/tromey/gnu/Trunk/build/i686-pc-linux-gnu/libjava/.libs:/home/tromey/gnu/Trunk/install/lib]

So to me it looks like we're missing an entry here for the libgcc_s.so
directory.  So, probably, your first patch is the way to go... I'd like
a bona fide libtool expert to look at this though.

I still don't understand why the second patch is needed.

As for --disable-fast-install, did you try just passing that to the
top-level configure?  (I didn't)


-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-10-11 21:01 -------
.libs/lt-gij is used by "make check". Try

# grep -i gij */*.exp

in libjava/testsuite.

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2004-10-11 21:27 -------
I'm afraid I couldn't really parse that.

To me it looks like libjava_find_gij looks for
"gij" in the build directory.  This in turn is
a shell script which, if needed, creates lt-gij.

The fact that the install tree is put in DT_RPATH
is, like I mentioned in comment #9, a problem.
For this we probably need your patch.

I suppose what I would really like to know is why
you needed the second patch.  What is wrong with
the current code for setting LD_LIBRARY_PATH in
libjava.exp?


-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-10-12 19:52 -------
You are right. The second patch isn't needed.

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-17 03:12 -------
What is the status of this bug (why is this still in waiting)?

-- 


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

[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2005-08-17 18:06 -------
FWIW, the bug is still there.

-- 


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