[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-25 14:07 --- The build fails: rm -fr .libs/libgcj.lax/libgcjgc_convenience.a mkdir .libs/libgcj.lax/libgcjgc_convenience.a (cd .libs/libgcj.lax/libgcjgc_convenience.a /work/rearnsha/gnu/egcs/binutils/ar x /work/rearnsha/gnu/egcs/arm-elf/thumb/libjava/../boehm-gc/.libs/libgcjgc_convenience.a) copying selected object files to avoid basename conflicts... rm -fr .libs/libgcj.lax mkdir .libs/libgcj.lax cp org/ietf/jgss/MessagesBundle.properties.o .libs/libgcj.lax/lt1-MessagesBundle.properties.o cp .libs/libgcj.lax/libgcj0_convenience.a/EventListener.o .libs/libgcj.lax/lt2-EventListener.o cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/EventListener.o': No such file or directory cp .libs/libgcj.lax/libgcj0_convenience.a/ContentHandler.o .libs/libgcj.lax/lt3-ContentHandler.o cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/ContentHandler.o': No such file or directory cp .libs/libgcj.lax/libgcj0_convenience.a/Attributes.o .libs/libgcj.lax/lt4-Attributes.o cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/Attributes.o': No such file or directory etc. Incidentally, wouldn't it be more efficient to use links (either hard or soft) rather than doing a copy? -- What|Removed |Added AssignedTo|aoliva at gcc dot gnu dot |rearnsha at gcc dot gnu dot |org |org Status|WAITING |ASSIGNED Last reconfirmed|2005-02-24 22:01:51 |2005-02-25 14:07:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-25 16:53 --- Hard-linking is an option, although we can't rely on hard-links being available. Soft-linking would require even more pathname tweaking, it's just not worth it. Anyhow, thanks for testing, I see what the problem is, and I'll have a new patch for you soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-24 13:19 --- Yes, that's the patch that introduces the problem. -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-24 13:19:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
-- What|Removed |Added CC||rth at gcc dot gnu dot org Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-24 14:12 --- *** Bug 20190 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-24 22:01 --- Verified on i686-linux with --disable-shared. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED GCC target triplet|arm-elf | Last reconfirmed|2005-02-24 13:19:31 |2005-02-24 22:01:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-24 22:15 --- Yet another libtool bug. It has clobbered ./java/lang/StringBuffer.o with ./gnu/gcj/runtime/StringBuffer.o when moving data from the convenience library to the main library. I fear we may be screwed, with no resolution that satisfies everyone. Alex? Is there any way out? -- What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-24 22:51 --- Technically, it's not a libtool bug. When you create an archive out of object files that have overlapping basenames, ar will generally only retain the last one. Dropping the dirname portion is mandated by POSIX. The right solution would be to avoid duplicate basenames entirely. This is probably tricky and painful to do in libjava. Libtool has some trickery to at least force object files with the same basename into an archive, passing special options to ar. I suppose the best course of action would be to rename the input files internally, transparently to the caller, such that, when they're extracted, you don't one to overwrite the other. Either way, this is probably not trivial to implement in libtool. Reverting to piecewise linking and modifying the grouping strategy might be easier. I'll think a bit about it. -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-24 22:55 --- A short-term, simpler solution that might be more suitable for the GCC 4 time-frame is to create one convenience archives per subdir, so as to make sure we don't have any overlapping basenames within a single archive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-23 11:10 --- Does backing out this patch help? http://gcc.gnu.org/ml/java-patches/2005-q1/msg00402.html (See also: PR 20155) -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
