Re: PATCH: Use libgcj_convenience.la ( Re: libjava bootstrap failure on sparc-sun-solaris2.8)

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

I wrote (but failed to CC the java list):

>>> Assuming this actually helps, please add a comment here explaining why
>>> libgcj_convenience.la exists.  Otherwise we won't remember it later
>>> on.  With that change, this is ok.  Thanks.

>> Here is the patch I checked in.

> I predict that this will fail as follows.  Since libgcj contains files
> with the same object name, making a convenience library that is
> unpacked into a new flat directory structure with a POSIX-compatible
> ar, the second step will drop required files (i.e. all but one with
> the same basename).

OK, I have tested my prediction.  The patch only affects one case.
Linking with ``gcj -static'' but the reason is exactly as above.  (I
traced the exact lines emitted by the patched Makefile to initially
confirm it.  I then also confirmed it in actual practice.)

> Since the patch was checked in, I am suprised that this issue was not
> spotted during a regression check...

In HJ's defense, this issue is not spottable with our testsuite unless
the entire gcc tree was originally configured with --disable-shared.
This is because the libjava tests to not honor -static provided in
RUNTESTFLAGS.  This is due to how libtool eats -static in some cases.
(I will not engage in an argument over whether that is good behavior
for libtool since I know Alex could explain why it does; it just does.)

> Also, you are suppose to report
> what platform you ran said regression check upon.  Where is that
> information?

This point still holds.

>>2002-06-04  H.J. Lu  (hjl@gnu.org)
>>
>>	* Makefile.am (libgcj_convenience.la): New target.
>>	(libgcj.la): Depend on libgcj_convenience.la.
>>	* Makefile.in: Regenerated.

The patch should be removed until the creation of libgcj.a is fixed.
The only way to do that and continue to use a convenience library
AKAIK is to rename object files to avoid all conflicts.  Unless we
wish to deviate from de facto standards in the area, we may not rename
at the source level due to Java file naming rules.

Thanks,
Loren