Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Kaveh R. Ghazi]

 > I checked out a fresh CVS tree and even for a plain ./configure as
 > above still get the same libtool failures.
 > 
 > [...]
 > updating cache ../config.cache
 > loading cache ../config.cache within ltconfig
 > configure: error: libtool configure failed
 > gmake[1]: *** [configure-target-libstdc++-v3] Error 1
 > gmake[1]: Leaving directory `/files/pfeifer/OBJ-0602-11:32'
 > gmake: *** [bootstrap] Error 2
 > 
 > I starting to get worried (about libtool)...
 > Gerald

I get similar problems on solaris2.7 configuring libjava, it started a
couple of days ago:

checking for gethostbyname... no
checking for main in -lnsl... yes
-lsocket -lnsl
checking for main in -ldl... yes
checking for gcj... /teal/caip5/ghazi/gcc-testing/branch/build/gcc/gcj
-B/teal/caip5/ghazi/gcc-testing/branch/build/sparc-sun-solaris2.7/libjava/
-B/teal/caip5/ghazi/gcc-testing/branch/build/gcc/
loading cache ../config.cache within ltconfig
configure: error: libtool tag configuration failed
make.solaris2[1]: *** [configure-target-libjava] Error 1

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun  2, 2001, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

>> I checked out a fresh CVS tree and even for a plain ./configure as
>> above still get the same libtool failures.
>> 
>> [...]
>> updating cache ../config.cache
>> loading cache ../config.cache within ltconfig
>> configure: error: libtool configure failed
>> gmake[1]: *** [configure-target-libstdc++-v3] Error 1
>> gmake[1]: Leaving directory `/files/pfeifer/OBJ-0602-11:32'
>> gmake: *** [bootstrap] Error 2

> I get similar problems on solaris2.7 configuring libjava, it started a
> couple of days ago:

> loading cache ../config.cache within ltconfig
> configure: error: libtool tag configuration failed
> make.solaris2[1]: *** [configure-target-libjava] Error 1

FYI, I've been able to duplicate this problem every now and then.
It's very odd.  It doesn't always occur, even if I repeat exactly the
same sequence of commands.  Seems like severe shell breakage.  As far
as I could tell, the problem always occurs while loading
config.cache, i.e., while the shell is running the command:

. ../config.cache

it seems to silently crash, generally on the line that would load
ac_cv_prog_glibcpp_CXX from the cache.

I'm not sure what to do about this.  On systems whose shells lose so
badly, a number of packages recommend using some working shell.
Solaris does offer such a shell, called /bin/ksh, so I'm inclined to
simply document that Solaris users should set CONFIG_SHELL=/bin/ksh
and be done with it.  What do you think?

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails tobuild today)

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> shell, called /bin/ksh, so I'm inclined to simply
    Alexandre> document that Solaris users should set
    Alexandre> CONFIG_SHELL=/bin/ksh and be done with it.  What do you
    Alexandre> think?

I think this is good.  In fact, I think that if we can do this
automatically in some way, we should try to do so.  If we can not do
that, we should issue an error message if the user is not using
/bin/ksh, if we can do that.

Our goal should be to prevent users from spending hours bootstrapping
the compiler only to have things fail later at all costs.  It is much
better to make users twiddle their environment in some way up front
than it is to allow them the supposed flexibility to use the shell of
their choice if it isn't going to work in the end.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 10, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> shell, called /bin/ksh, so I'm inclined to simply
Alexandre> document that Solaris users should set
Alexandre> CONFIG_SHELL=/bin/ksh and be done with it.  What do you
Alexandre> think?

> I think this is good.  In fact, I think that if we can do this
> automatically in some way, we should try to do so.

I wouldn't go that far.  Out of 4 Solaris boxes in which I test GCC
weekly, only one of them fails, and even then, it doesn't fail
consistently.  After you get a failure, it's easy enough to fix the
problem and proceed from where it stopped.  Both of these workarounds
have consistently worked for me:

        make SHELL=/bin/ksh bootstrap 

and

        rm *-solaris*/config.cache
        make bootstrap


Another problem I've been investigating is that of building libgcj on
Solaris 8 using the same prefix as that of a previously-installed copy
of libgcj.  Solaris' linker apparently tries to out-smart the user, by
claiming the already-installed library conflicts with the one in the
build tree, even though the program being linked is only going to be
run after the libraries in the build tree are already installed.  I
couldn't find any way to tell the linker that what we're telling it to
do is actually ok, so, should we want to enable libgcj on Solaris 8
(it's currently disabled), I see only two alternatives:

- Recommend the use of --disable-fast-install as a configure switch on
Solaris 8.  This libtool configure switch causes the build not to be
optimized for installation, but for execution in the build tree.  This
will have the effect of the installable programs only being built at
install time, when the libraries have already been installed.  I
haven't had time to investigate whether this will actually fix the
problem, particularly because I haven't been able to create a simple
scenario in which the problem shows up.  But, in theory, it might
help.

- Recommend the use of GNU ld, since it works correctly.


Opinions?

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails tobuild today)

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    >> I think this is good.  In fact, I think that if we can do this
    >> automatically in some way, we should try to do so.

    Alexandre> I wouldn't go that far.  

Why not?  Would doing so actually harm the user in any way?  So far,
it sounds to me like it would avoid problems in some situations, and
not cause them in others, which seems like a net win. 

One of the reasons this interests me is that I would like automated
builds to be as easy as possible, because that's a key means of
keeping our quality up.  I don't want to have to teach each automated
build machine what flags to use -- I'd like `./configure; make
bootstrap' to just work.  I bet users feel the same way.

If you disagree, or if it's hard to do the automated thing, please do
document the thing that one should do.  Patch preapproved.

    Alexandre> even then, it doesn't fail consistently.  After you get
    Alexandre> a failure, it's easy enough to fix the problem and
    Alexandre> proceed from where it stopped. 

You're assuming you know how. :-)  I think most users will say "GCC
3.0 is broken" at this point.  They have no way to know the shell is
at fault.

    Alexandre> we're telling it to do is actually ok, so, should we
    Alexandre> want to enable libgcj on Solaris 8 (it's currently
    Alexandre> disabled), I see only two alternatives:

Boy, I sure don't know how to help with this.  But, as you say, it's
currently disabled, so I guess I needn't worry just yet... :-)

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Gerald Pfeifer]

On Sun, 10 Jun 2001, Mark Mitchell wrote:
> I'd like `./configure; make bootstrap' to just work.  I bet users feel
> the same way.

Definitely.

>> we're telling it to do is actually ok, so, should we want to enable
>> libgcj on Solaris 8 (it's currently disabled), I see only two
>> alternatives:
> Boy, I sure don't know how to help with this.  But, as you say, it's
> currently disabled, so I guess I needn't worry just yet... :-)

We have to, I'm afraid!

HIGHLY IMPORTANT: Today I am experiencing repeated bootstrap failures on
sparc-sun-solaris2.8 with a plain

  configure --prefix=... --enable-languages=c,c++,objc,java

That is, without explicitly specifying libgcj. This means we definitely
have to fix this somehow before the release!

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

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 11, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> HIGHLY IMPORTANT: Today I am experiencing repeated bootstrap failures on
> sparc-sun-solaris2.8 with a plain

>   configure --prefix=... --enable-languages=c,c++,objc,java

> That is, without explicitly specifying libgcj. This means we definitely
> have to fix this somehow before the release!

What is the problem this time?  I couldn't find any message from yours
with further details about the failure.

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Gerald Pfeifer]

On 12 Jun 2001, Alexandre Oliva wrote:
>> HIGHLY IMPORTANT: Today I am experiencing repeated bootstrap failures on
>> sparc-sun-solaris2.8 with a plain
>
>>   configure --prefix=... --enable-languages=c,c++,objc,java
>
>> That is, without explicitly specifying libgcj. This means we definitely
>> have to fix this somehow before the release!
> What is the problem this time?

It's exactly the problem that lead to this thread. Originally we
had thought that on sparc-sun-solaris2.8 it would only happen if one
explicitly enabled libgcj (so Mark didn't consider it critical), but
now I started to get this for plain builds as above.

I have just fired another build, after getting three failures yesterday...

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

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to buildtoday)

[Mark Mitchell]

--On Wednesday, June 13, 2001 02:23:50 AM +0200 Gerald Pfeifer 
<pfeifer@dbai.tuwien.ac.at> wrote:

> On 12 Jun 2001, Alexandre Oliva wrote:
>>> HIGHLY IMPORTANT: Today I am experiencing repeated bootstrap failures on
>>> sparc-sun-solaris2.8 with a plain
>>
>>>   configure --prefix=... --enable-languages=c,c++,objc,java
>>
>>> That is, without explicitly specifying libgcj. This means we definitely
>>> have to fix this somehow before the release!
>> What is the problem this time?
>
> It's exactly the problem that lead to this thread. Originally we
> had thought that on sparc-sun-solaris2.8 it would only happen if one
> explicitly enabled libgcj (so Mark didn't consider it critical), but
> now I started to get this for plain builds as above.

I don't consider putting `java' in --enable-languages a "plain build". :-)

My intent, and I think what the Java people were kind enough to implement,
was that enabling gcj would imply enabling libgcj -- and that both would
be automatically disabled on platforms where they were known not
to work.  So, by manually enabling Java, you are asking for both the
compiler and the library.

But perhaps I have lost too much context.  If Alexandre remembers
something different, he is probably correct.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 12, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> It's exactly the problem that lead to this thread. Originally we
> had thought that on sparc-sun-solaris2.8 it would only happen if one
> explicitly enabled libgcj

No, that was a different problem.  The one you're experiencing is the
one caused by lossage in Solaris' /bin/sh.  I'm about to post a patch
that documents the problem and recommends using CONFIG_SHELL=ksh on
Solaris.

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 12, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> My intent, and I think what the Java people were kind enough to implement,
> was that enabling gcj would imply enabling libgcj

Not on platforms in which libgcj is marked as non-supported, which is
that case of Solaris 8.  On such platforms, you have to
--enable-libgcj even if java is one of the enabled languages.

> and that both would be automatically disabled on platforms where
> they were known not to work.

IMO, it does make sense to install gcj even if libgcj isn't installed.
This makes it possible to use gcj with other java libraries and JVMs.
Kaffe OpenVM, for example, can load and run binary code compiled by
(some earlier version of) GCJ.

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 10, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
>>> I think this is good.  In fact, I think that if we can do this
>>> automatically in some way, we should try to do so.

Alexandre> I wouldn't go that far.  

> If you disagree, or if it's hard to do the automated thing, please do
> document the thing that one should do.

I don't see how to switch shells in a safe way, so I'd rather not take
that risk.  I hereby volunteer to refer to the documentation below
people who report this problem to gcc-help.

Ok to install?

s
Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>
	* doc/install.texi (ix86-*-solaris*): Removed, outdated.
	(*-*-solaris*): Document problem in /bin/sh that affects
	configuring libraries.
	(sparc-*-solaris*): Recommend GNU binutils 2.11.1 or vendor tools.
	(*-sun-solaris2.8): Document linker problem that explains why
	libjava is disabled by default.

Index: gcc/doc/install.texi
===================================================================
RCS file: /cvs/gcc/egcs/gcc/doc/install.texi,v
retrieving revision 1.1.2.20
diff -u -p -r1.1.2.20 install.texi
--- gcc/doc/install.texi 2001/06/12 19:39:42 1.1.2.20
+++ gcc/doc/install.texi 2001/06/13 02:54:52
@@ -1204,8 +1204,6 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#ix86-*-sco3.2v5*,,i?86-*-sco3.2v5*}
 @item
-@uref{#ix86-*-solaris*,,i?86-*-solaris*}
-@item
 @uref{#ix86-*-udk,,i?86-*-udk}
 @item
 @uref{#ix86-*-isc,,i?86-*-isc}
@@ -1951,19 +1949,6 @@ engineering and will hopefully be addres
 </p>
 <hr>
 @end html
-@heading @anchor{ix86-*-solaris*}i?86-*-solaris*
-
-GCC 2.95.2, when configured to use the GNU assembler, would invoke
-it with the @code{-s} switch, that GNU as up to 2.9.5.0.12 does
-not support.  If you'd rather not use a newer GNU as nor the native
-assembler, you'll need the patch 
-@uref{x86-sol2-gas.patch,,@file{x86-sol2-gas.patch}}.
-
-
-@html
-</p>
-<hr>
-@end html
 @heading @anchor{ix86-*-udk}i?86-*-udk
 
 This target emulates the SCO Universal Development Kit and requires that
@@ -2911,6 +2896,12 @@ error: can't compute value of an express
 This is Sun bug 4237974.  This is fixed with patch 108908-02 and has
 been fixed in later (5.x) versions of the assembler.
 
+Solaris' /bin/sh will often fail to configure libstdc++-v3, boehm-gc or
+libjava.  If you encounter this problem, set @var{CONFIG_SHELL} to
+@code{/bin/ksh} in your environment and run @samp{make bootstrap} again.
+Another possibility that sometimes helps is to remove
+@code{*-*-solaris*/config.cache}.
+
 @html
 <p>
 <hr>
@@ -2957,8 +2948,9 @@ On Solaris 2, trying to use the linker a
 For example, the linker may hang indefinitely.  The fix is to remove
 @file{/usr/ucb} from your @code{PATH}.
 
-binutils 2.9.1 has known bugs on this platform. We recommend to use
-binutils 2.10 or the vendor tools (Sun as, Sun ld).
+All releases of binutils prior to 2.11.1 have known bugs on this
+platform. We recommend to use binutils 2.11.1 or the vendor tools (Sun
+as, Sun ld).
 
 Unfortunately, C++ shared libraries, including libstdc++, won't work
 properly if assembled with Sun as: the linker will complain about
@@ -2966,7 +2958,6 @@ relocations in read-only sections, in th
 tables. Also, Sun as fails to process long symbols resulting from
 mangling template-heavy C++ function names.
 
-
 @html
 </p>
 <hr>
@@ -3026,6 +3017,12 @@ will assume that any missing type is 'in
 For Solaris 8, this is fixed by revision 24 or later of patch 108652
 (for SPARCs) or 108653 (for Intels).
 
+Solaris 8's linker fails to link some libjava programs if
+previously-installed GCC java libraries already exist in the configured
+prefix.  For this reason, libgcj is disabled by default on Solaris 8.
+If you use GNU ld, or if you don't have a previously-installed libgcj in
+the same prefix, use @code{--enable-libgcj} to build and install the
+Java libraries.
 
 @html
 <p>

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to buildtoday)

[Mark Mitchell]

--On Tuesday, June 12, 2001 11:59:55 PM -0300 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> On Jun 12, 2001, Mark Mitchell <mark@codesourcery.com> wrote:
>
>> My intent, and I think what the Java people were kind enough to
>> implement, was that enabling gcj would imply enabling libgcj
>
> Not on platforms in which libgcj is marked as non-supported, which is
> that case of Solaris 8.  On such platforms, you have to
> --enable-libgcj even if java is one of the enabled languages.

OK.  Then I'm not sure why Nathan's seeing problems with libgcj;
that sounds like the scheme you describe wasn't fully implemented.
I'm probably lost, though, and the lack of sleep is starting to
catch up with me.

Yours,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to buildtoday)

[Mark Mitchell]

> Ok to install?
>

Yes -- but:

+platform. We recommend to use binutils 2.11.1 or the vendor tools (Sun
+as, Sun ld).

"We recommend the use of binutils..." is better grammatically.

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 13, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> --On Tuesday, June 12, 2001 11:59:55 PM -0300 Alexandre Oliva
> <aoliva@redhat.com> wrote:


>> On Jun 12, 2001, Mark Mitchell <mark@codesourcery.com> wrote:
>> 
>>> My intent, and I think what the Java people were kind enough to
>>> implement, was that enabling gcj would imply enabling libgcj
>> 
>> Not on platforms in which libgcj is marked as non-supported, which is
>> that case of Solaris 8.  On such platforms, you have to
>> --enable-libgcj even if java is one of the enabled languages.

> OK.  Then I'm not sure why Nathan's seeing problems with libgcj;

Is he?  Gerry is seeing problems in libstdc++, I suppose.

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 13, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> +platform. We recommend to use binutils 2.11.1 or the vendor tools (Sun
> +as, Sun ld).

> "We recommend the use of binutils..." is better grammatically.

Thanks, fixed, checking in.

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Gerald Pfeifer]

On 13 Jun 2001, Alexandre Oliva wrote:
> Ok to install?

Yes, thanks, with minor changes:

+Solaris' /bin/sh will often fail to configure libstdc++-v3, boehm-gc or
+libjava.  If you encounter this problem, set @var{CONFIG_SHELL} to
+@code{/bin/ksh}

@command{/bin/sh} and @command{/bin/ksh}.

+Another possibility that sometimes helps is to remove
+@code{*-*-solaris*/config.cache}.

@file{*-*-solaris*/config.cache}

+If you use GNU ld, or if you don't have a previously-installed libgcj in
+the same prefix, use @code{--enable-libgcj} to build and install the
+Java libraries.

@option{--enable-libgcj}.

Thanks,
Gerald

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Joseph S. Myers]

On Wed, 13 Jun 2001, Gerald Pfeifer wrote:

> On 13 Jun 2001, Alexandre Oliva wrote:
> > Ok to install?
> 
> Yes, thanks, with minor changes:
> 
> +Solaris' /bin/sh will often fail to configure libstdc++-v3, boehm-gc or
> +libjava.  If you encounter this problem, set @var{CONFIG_SHELL} to
> +@code{/bin/ksh}
> 
> @command{/bin/sh} and @command{/bin/ksh}.

Also, @env{CONFIG_SHELL} rather than @var{CONFIG_SHELL}.

(See the "Marking Text" section in the Texinfo 4.0 manual, which is quite
short and gives enough information to get most of this sort of markup
right.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 13, 2001, "Joseph S. Myers" <jsm28@cam.ac.uk> wrote:

> On Wed, 13 Jun 2001, Gerald Pfeifer wrote:
>> On 13 Jun 2001, Alexandre Oliva wrote:
>> > Ok to install?
>> 
>> Yes, thanks, with minor changes:
>> 
>> +Solaris' /bin/sh will often fail to configure libstdc++-v3, boehm-gc or
>> +libjava.  If you encounter this problem, set @var{CONFIG_SHELL} to
>> +@code{/bin/ksh}
>> 
>> @command{/bin/sh} and @command{/bin/ksh}.

> Also, @env{CONFIG_SHELL} rather than @var{CONFIG_SHELL}.

I see you've taken care of these issues in the patch you posted
earlier today (oops, it has just become yesterday).  Thanks!

> (See the "Marking Text" section in the Texinfo 4.0 manual, which is quite
> short and gives enough information to get most of this sort of markup
> right.)

Thanks for the pointer.  It's hard to remember all these
possibilities, especially when you look around in the file to follow
examples and they turn out to be wrong.  Your clean up will really
help prevent it from happening again.  Thanks a lot.

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Alexandre Oliva]

On Jun 11, 2001, mike stump <mrs@windriver.com> wrote:

>> It's very odd.

> Not that odd, one just has to be willing to track it down and discover
> what the problem is and fix it.

The problem is that it is random.  Given *exactly* the same sources,
it won't always occur.  It's a heisenbug in Solaris' shell.  How do
you track down and fix this kind of problem?  config.cache looks very
reasonable, except, perhaps, for some relatively long strings.

>> It doesn't always occur, even if I repeat exactly the same sequence
>> of commands.  Seems like severe shell breakage.

> Or, a small bit of shell non-portability.

This doesn't seem to be the case.  Well, unless you consider `working
around random bugs in shells' as part of `shell portability'.  I agree
with this definition, up to a point.  This particular bug appears to
be beyond the point I'd generally concede.

>> it seems to silently crash, generally on the line that would load
>> ac_cv_prog_glibcpp_CXX from the cache.

> Reminds me of http://gcc.gnu.org/ml/gcc/2001-04/msg00457.html ...

> where it crashed upon seeing:

> lt_cv_file_magic_cmd=${lt_cv_file_magic_cmd='$MAGIC_CMD'}

Nope, that's a different problem.  That was not a crash, it just
parsed the thing differently.

> I think it needs to be tracked down and fixed (if possible), not
> papered over.

Please be my guest.  I've already spent lots of hours trying to track
it down, bootstraping the very same set of sources from scratch a
number of times and seeing it fail some times and not fail other
times.  Very frustrating.  I really don't feel like wasting more time
on this issue.

> I think changing the documentation is wrong.  The software, when used,
> should just work.

Shouldn't this be applied to Solaris' /bin/sh too?

-- 
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    *Please* write to mailing lists, not to me

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[mike stump]

> Date: Mon, 11 Jun 2001 16:55:40 -0700
> From: Mark Mitchell <mark@codesourcery.com>

> I think we should work with at least one easy-to-obtain shell on
> each platform, preferably one shipped with the system by the vendor
> -- but not necessarily all.

Next time we are at a bar, buy me a beer and I will tell you of the
story of having to configure with one shell, and building with
another, because neither shell could do the other job.  Really gross
and responsible for burning far more engineering time then it seems
like it should have.   :-(

But, if the software uses ksh or bash whenever a broken /bin/sh would
have been used, I think that is enough to not screw users.

Re: libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[mike stump]

> To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 10 Jun 2001 22:14:05 -0300

> > I get similar problems on solaris2.7 configuring libjava, it started a
> > couple of days ago:

:-)  around about 7 months ago actually:

http://gcc.gnu.org/ml/gcc-bugs/2000-11/msg00438.html

> FYI, I've been able to duplicate this problem every now and then.

Ditto.

> It's very odd.

Not that odd, one just has to be willing to track it down and discover
what the problem is and fix it.  No one has done that.  I think that 3.0
should not be released until it is tracked down and fixed.

> It doesn't always occur, even if I repeat exactly the same sequence
> of commands.  Seems like severe shell breakage.

Or, a small bit of shell non-portability.

> As far as I could tell, the problem always occurs while loading
> config.cache, i.e., while the shell is running the command:

> . ../config.cache

Yes.

> it seems to silently crash, generally on the line that would load
> ac_cv_prog_glibcpp_CXX from the cache.

Reminds me of http://gcc.gnu.org/ml/gcc/2001-04/msg00457.html ...

where it crashed upon seeing:

lt_cv_file_magic_cmd=${lt_cv_file_magic_cmd='$MAGIC_CMD'}

> I'm not sure what to do about this.

I think that the configury bits in the compiler need to be
exceptionally stable and portable and they need to work with all
shells, even broken ones.  Take a look at all the bugs reports to date
relating to this, what a pain.  I know I killed large amounts of time
because of this.  I think it needs to be tracked down and fixed (if
possible), not papered over.

> On systems whose shells lose so badly, a number of packages
> recommend using some working shell.  Solaris does offer such a
> shell, called /bin/ksh, so I'm inclined to simply document that
> Solaris users should set CONFIG_SHELL=/bin/ksh and be done with it.
> What do you think?

I think changing the documentation is wrong.  The software, when used,
should just work.  If it works, the no documentation is necessary.  If
the software doesn't work, then the documentation that explains the
magic incantation to make it work is a liability.

A quick no work solution to this is on solaris to reject the use of sh
out of hand, and always use ksh or bash.

I tracked it down once and saw the problem as I recall back in April.
I'm now sorry I didn't email the results of my investigation back in.
:-(

libtool (was: GCC 3.0: sparc-sun-solaris2.8 fails to build today)

[Gerald Pfeifer]

On Sat, 2 Jun 2001, Gerald Pfeifer wrote:
> I usually configure with --enable-languages=c,c++,objc,java --prefix=....

I checked out a fresh CVS tree and even for a plain ./configure as above
still get the same libtool failures.

gmake[3]: Leaving directory `/files/pfeifer/OBJ-0602-11:32/gcc'
gmake[2]: Leaving directory `/files/pfeifer/OBJ-0602-11:32/gcc'
Configuring in sparc-sun-solaris2.8/libstdc++-v3
creating cache ../config.cache
checking host system type... sparc-sun-solaris2.8
checking target system type... sparc-sun-solaris2.8
checking build system type... sparc-sun-solaris2.8
checking for a BSD compatible install... /bin/sh /sw/test/gcc/cvs-3.0/install-sh -c
checking whether build environment is sane... yes
checking whether gmake sets ${MAKE}... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking for gcc... /files/pfeifer/OBJ-0602-11:32/gcc/xgcc -B/files/pfeifer/OBJ-0602-11:32/gcc/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include
checking whether we are using GNU C... yes
checking whether /files/pfeifer/OBJ-0602-11:32/gcc/xgcc -B/files/pfeifer/OBJ-0602-11:32/gcc/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include accepts -g... yes
checking for c++... /files/pfeifer/OBJ-0602-11:32/gcc/xgcc -B/files/pfeifer/OBJ-0602-11:32/gcc/ -nostdinc++  -L/files/pfeifer/OBJ-0602-11:32/sparc-sun-solaris2.8/libstdc++-v3/src -L/files/pfeifer/OBJ-0602-11:32/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include
checking whether we are using GNU C++... yes
checking whether /files/pfeifer/OBJ-0602-11:32/gcc/xgcc -B/files/pfeifer/OBJ-0602-11:32/gcc/ -nostdinc++  -L/files/pfeifer/OBJ-0602-11:32/sparc-sun-solaris2.8/libstdc++-v3/src -L/files/pfeifer/OBJ-0602-11:32/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include accepts -g... yes
checking for as... as
checking for ar... ar
checking for ranlib... true
checking for a BSD compatible install... /bin/sh /sw/test/gcc/cvs-3.0/install-sh -c
checking whether to enable maintainer-specific portions of Makefiles... no
CPU config directory is config/cpu/sparc/sparc32
OS config directory is config/os/solaris/solaris2.7
checking for ld used by GCC... ld
checking if the linker (ld) is GNU ld... no
checking for ld option to reload object files... -r
checking for BSD-compatible nm... nm
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking for object suffix... o
checking for ranlib... (cached) true
checking for strip... strip
checking how to run the C++ preprocessor... /files/pfeifer/OBJ-0602-11:32/gcc/xgcc -B/files/pfeifer/OBJ-0602-11:32/gcc/ -nostdinc++  -L/files/pfeifer/OBJ-0602-11:32/sparc-sun-solaris2.8/libstdc++-v3/src -L/files/pfeifer/OBJ-0602-11:32/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include -E
updating cache ../config.cache
loading cache ../config.cache within ltconfig
configure: error: libtool configure failed
gmake[1]: *** [configure-target-libstdc++-v3] Error 1
gmake[1]: Leaving directory `/files/pfeifer/OBJ-0602-11:32'
gmake: *** [bootstrap] Error 2

I starting to get worried (about libtool)...

Gerald