Solaris 2.8 build

Solaris 2.8 build

[Tom Tromey]

I see this in the top-level configure.in:

  sparc-*-solaris*)
    case "${host}" in
    sparc-*-solaris2.8)
      # According to Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>, libjava
      # won't build correctly on Solaris 8 if there's a
      # previously-installed version of GCC in the configured prefix.
      # This problem does not show up on earlier versions of Solaris.
      noconfigdirs="$noconfigdirs ${libgcj}"
      ;;
    esac

Is there something we can do about it?
Disabling libgcj in this case is unfortunate.

Tom

Re: Solaris 2.8 build

[Alexandre Oliva]

On Mar 15, 2002, Tom Tromey <tromey@redhat.com> wrote:

> Is there something we can do about it?

Perhaps we could test for ${libdir}/libgcj.la and error out if it's
present, telling the user to use a different prefix or remove the
earlier version, but only if using Solaris' ld.  This linker just
won't let you do The Right Thing (TM) (i.e., link a library with
dependencies yet-to-be-installed such that the dependencies will be
found in the right place after they are installed).

Incidentally, turning zlib and boehm-gc into convenience libraries
would probably fix the non-problem detected by the linker...

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Solaris 2.8 build

[Rainer Orth]

Tom Tromey writes:

> I see this in the top-level configure.in:
> 
>   sparc-*-solaris*)
>     case "${host}" in
>     sparc-*-solaris2.8)
>       # According to Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>, libjava
>       # won't build correctly on Solaris 8 if there's a
>       # previously-installed version of GCC in the configured prefix.
>       # This problem does not show up on earlier versions of Solaris.
>       noconfigdirs="$noconfigdirs ${libgcj}"
>       ;;
>     esac
> 
> Is there something we can do about it?
> Disabling libgcj in this case is unfortunate.

indeed: I've done a bit research and found what's going on:

Gerald's original report at

	http://gcc.gnu.org/ml/java/2001-04/msg00129.html

shows the problem.  For an explanation, see the Solaris 8 Linker and
Libraries Guide: 

	http://docs.sun.com:80/ab2/coll.45.13/LLM/@Ab2PageView/6558

sub Recorded Name Conflicts:

The command line can be reduced to

	gcj -o jv-convert <jv-convert objs> .libs/libgcj.so

with much stuff around.  gcj implicitly adds -lgcj.  If a libgcj.so with
the same SONAME as the one in .libs is present in $libdir specified when
configuring gcc, gcj will effectively call ld with

	ld -o jv-convert ... .libs/libgcj.so -L$libdir -lgcj

So ld is asked to record dependencies for two different shared objects with
the same SONAME in jv-convert, which is just cannot do since all it records
is the SONAME, so it bails out.

This doubly linking the same library also caused the testsuite failures
described in 

	http://gcc.gnu.org/ml/java/2001-06/msg00247.html

and the thread starting at

	http://gcc.gnu.org/ml/java-patches/2001-q3/msg00076.html

which have now been fixed by avoiding this double linking.  Maybe this can
be done here, too, or we add some -nostdlibgcj switch as proposed there.

	Rainer

Re: Solaris 2.8 build

[Tom Tromey]

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer> The command line can be reduced to
Rainer> 	gcj -o jv-convert <jv-convert objs> .libs/libgcj.so
Rainer> with much stuff around.  gcj implicitly adds -lgcj.  If a
Rainer> libgcj.so with the same SONAME as the one in .libs is present
Rainer> in $libdir specified when configuring gcc, gcj will
Rainer> effectively call ld with
Rainer> 	ld -o jv-convert ... .libs/libgcj.so -L$libdir -lgcj

Alexandre recently checked in a patch that removes the explicit `-l'
options from the command line for gij, jv-convert, etc.  With this
patch in place, we only link once.

First, are we sure we're always linking against the uninstalled
libraries?

Second, if so, then doesn't that imply that the 2.8 problem is fixed?
(If you've got some time, would you mind testing this?  If you can't,
tell me, and I'll see if I can do it.)

Tom

Re: Solaris 2.8 build

[Gerald Pfeifer]

On 15 Mar 2002, Tom Tromey wrote:
> Second, if so, then doesn't that imply that the 2.8 problem is fixed?
> (If you've got some time, would you mind testing this?  If you can't,
> tell me, and I'll see if I can do it.)

I tried bootstrapping mainline with --enable-libgcj and an already
existing installed tree at --prefix, but failed due to an unrelated
failure: <http://gcc.gnu.org/ml/gcc/2002-03/msg00925.html>

I'll try the 3.1-branch ASAP, but to make sure, is this the test you
had in mind?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Solaris 2.8 build

[Rainer Orth]

Tom Tromey writes:

> Alexandre recently checked in a patch that removes the explicit `-l'
> options from the command line for gij, jv-convert, etc.  With this
> patch in place, we only link once.
> 
> First, are we sure we're always linking against the uninstalled
> libraries?

Most likely: I've manually copied a gcc 3.0.5 libgcj.so{,.2} to $prefix/lib
and manually re-run the jv-convert link command: I don't see any accesses
(neither successful nor failed) to $prefix/lib/libgcj.so in truss output,
only to the copy inside the build dir.

> Second, if so, then doesn't that imply that the 2.8 problem is fixed?

Indeed: I'd have expected the ld error Gerald reported if the problem
persisted, but the link succeeded without errors.

> (If you've got some time, would you mind testing this?  If you can't,
> tell me, and I'll see if I can do it.)

Perhaps Gerald could retry a bootstrap (if the current branch bootstraps on
Solaris 2.8) to be extra sure this works?  I'm still working off a 20020313
tree right now.

	Rainer

Re: Solaris 2.8 build

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

Tom> Second, if so, then doesn't that imply that the 2.8 problem is
Tom> fixed?  (If you've got some time, would you mind testing this?
Tom> If you can't, tell me, and I'll see if I can do it.)

Gerald> I tried bootstrapping mainline with --enable-libgcj and an already
Gerald> existing installed tree at --prefix, but failed due to an unrelated
Gerald> failure: <http://gcc.gnu.org/ml/gcc/2002-03/msg00925.html>

Gerald> I'll try the 3.1-branch ASAP, but to make sure, is this the test you
Gerald> had in mind?

Yes.

Tom

Re: Solaris 2.8 build

[Gerald Pfeifer]

On Mon, 18 Mar 2002, Rainer Orth wrote:
> Perhaps Gerald could retry a bootstrap (if the current branch bootstraps on
> Solaris 2.8) to be extra sure this works?  I'm still working off a 20020313
> tree right now.

Unfortunately, both mainline and the 3.1-branch are broken wrt to
libstdc++, and as libgcj requires the C++ frontend (right?), I thus
cannot perform this test. :-(

On 18 Mar 2002, Tom Tromey wrote:
>> I tried bootstrapping mainline with --enable-libgcj and an already
>> existing installed tree at --prefix, but failed due to an unrelated
>> failure: <http://gcc.gnu.org/ml/gcc/2002-03/msg00925.html>
>>
>> I'll try the 3.1-branch ASAP, but to make sure, is this the test you
>> had in mind?
> Yes.

Okay, I'll wait until the release branch builds on sparc-sun-solaris2.8
again (or someone tells me that/how I can avoid building libstdc++ for
libgcj to avoid that failure) and will then perform testing and inform
you.

Thanks for considering this issue again, which I probably would have
forgot...

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Solaris 2.8 build

[Gerald Pfeifer]

On 18 Mar 2002, Tom Tromey wrote:
>> I tried bootstrapping mainline with --enable-libgcj and an already
>> existing installed tree at --prefix [...]
> Yes.

Now that sparc-sun-solaris2.8 is finally bootstrapping again with
--enable-libgcj I ran a couple of tests as prompised and indeed (as
Brad reported) the problem still is here. :-(

Do we already have a PR for this? If not, I can create one, referring
to analyses by Rainer Orth and Alexandre Oliva:

  http://gcc.gnu.org/ml/java/2002-03/msg00348.html
  http://gcc.gnu.org/ml/java/2002-03/msg00343.html

Alexandre's suggestion

  Perhaps we could test for ${libdir}/libgcj.la and error out if it's
  present, telling the user to use a different prefix or remove the
  earlier version, but only if using Solaris' ld.

seems like a useful approach to me, BTW?

Gerald

:
(cd .libs && rm -f libgcj.la && ln -s ../libgcj.la libgcj.la)
/bin/ksh ./libtool --tag=GCJ --mode=link /files/pfeifer/OBJ-0329-2139/gcc/gcj -B/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava/ -B/files/pfeifer/OBJ-0329-2139/gcc/ -L/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava -g -O2  -m64 -m64 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /sw/test/gcc/SunOS/lib/sparcv9 -shared-libgcc   libgcj.la -L/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava/.libs
/files/pfeifer/OBJ-0329-2139/gcc/gcj -B/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava/ -B/files/pfeifer/OBJ-0329-2139/gcc/ -g -O2 -m64 -m64 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc  -L/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava ./.libs/libgcj.so -L/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src -L/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/.libs -lpthread -lrt -ldl -L/files/pfeifer/OBJ-0329-2139/gcc/sparcv9 -L/files/pfeifer/OBJ-0329-2139/gcc -L/sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.1/sparcv9 -L/sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -L/usr/ccs/bin/sparcv9 -L/usr/ccs/bin -L/usr/ccs/lib/sparcv9 -L/usr/ccs/lib -L/sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../../sparcv9 -L/sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../.. -L/lib/sparcv9 -L/usr/lib/sparcv9 -lgcc_s_sparcv9 -lgcc_s_sparcv9 -L/files/pf!
eifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava/.libs -Wl,-R -Wl,/sw/test/gcc/SunOS/lib/sparcv9
ld: fatal: file /sw/test/gcc/SunOS/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../../sparcv9/libgcj.so: recording name `libgcj.so.3' matches that provided by file ./.libs/libgcj.so
ld: fatal: File processing errors. No output written to .libs/jv-convert
collect2: ld returned 1 exit status
gmake[5]: *** [jv-convert] Error 1
gmake[5]: Leaving directory `/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory `/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/sparcv9/libjava'
gmake[3]: *** [multi-do] Error 1
gmake[3]: Leaving directory `/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/libjava'
gmake[2]: *** [all-multi] Error 2
gmake[2]: Leaving directory `/files/pfeifer/OBJ-0329-2139/sparc-sun-solaris2.8/libjava'
gmake[1]: *** [all-target-libjava] Error 2

Re: Solaris 2.8 build

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

Gerald> [ 2.8 libgcj re-install bug ]

Gerald> Do we already have a PR for this? If not, I can create one, referring
Gerald> to analyses by Rainer Orth and Alexandre Oliva:

Gerald>   http://gcc.gnu.org/ml/java/2002-03/msg00348.html
Gerald>   http://gcc.gnu.org/ml/java/2002-03/msg00343.html

As far as I know there is no PR for this.
Please do create one.

Alexandre>   Perhaps we could test for ${libdir}/libgcj.la and error
Alexandre>   out if it's present, telling the user to use a different
Alexandre>   prefix or remove the earlier version, but only if using
Alexandre>   Solaris' ld.

Gerald> seems like a useful approach to me, BTW?

Ideally we would check for this very early, in the top-level
configure.  If we check for it in libgcj then the user will have
already built all the host tools before getting this error.

Does this problem not occur for libstdc++ and other target libraries?
If not, why not?

Tom

Re: Solaris 2.8 build

[Gerald Pfeifer]

On 2 Apr 2002, Tom Tromey wrote:
> As far as I know there is no PR for this.
> Please do create one.

Done.

libgcj/6158: libgcj won't bootstrap on sparc-sun-solaris2.8 if already installed

> Ideally we would check for this very early, in the top-level configure.
> If we check for it in libgcj then the user will have already built all
> the host tools before getting this error.

That's true (though that still would be better than a "regular" bootstrap
failure...)

> Does this problem not occur for libstdc++ and other target libraries?
> If not, why not?

I've never seen this apart from libgcj, and I'm building libstdc++ with
every bootstrap.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/