3.0.4 builds for solaris 2.7 and 2.8

3.0.4 builds for solaris 2.7 and 2.8

[George.R.Goffe]

# ./config.guess

sparc-sun-solaris2.7

 gcc -v

Reading specs from
/usr/lsd/SunOS.5.7/lib/gcc-lib/sparc-sun-solaris2.7/3.0.4/specs
Configured with: ../configure --prefix=/usr/lsd/SunOS.5.7 --verbose
--x-includes=/usr/openwin/include --x-libraries=/usr/openwin/lib
--with-libiconv-path=/usr/lsd/SunOS.5.7/lib --enable-libgcj --with-gnu-as
--with-gnu-as-path=/usr/lsd/SunOS.5.7/bin/as --with-gnu-ld
--with-gnu-ld-path=/usr/lsd/SunOS.5.7/bin/ld
Thread model: posix
gcc version 3.0.4



# ./config.guess
sparc-sun-solaris2.8

gcc -v

Reading specs from
/usr/lsd/SunOS.5.8/lib/gcc-lib/sparc-sun-solaris2.8/3.0.4/specs
Configured with: ../configure --prefix=/usr/lsd/SunOS.5.8 --verbose
--x-includes=/usr/openwin/include --x-libraries=/usr/openwin/lib
--with-libiconv-path=/usr/lsd/SunOS.5.8/lib --enable-libgcj --with-gnu-as
--with-gnu-as-path=/usr/lsd/SunOS.5.8/bin/as --with-gnu-ld
--with-gnu-ld-path=/usr/lsd/SunOS.5.8/bin/ld
Thread model: posix
gcc version 3.0.4

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Alexandre Oliva]

On Feb 22, 2002, George.R.Goffe@seagate.com wrote:

> --with-gnu-as-path=/usr/lsd/SunOS.5.7/bin/as --with-gnu-ld
> --with-gnu-ld-path=/usr/lsd/SunOS.5.7/bin/ld
  ^^^^^^^^^^^^^^^^^^

These options have no effect at all.  Perhaps you meant --with-as and
--with-ld?

-- 
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: 3.0.4 builds for solaris 2.7 and 2.8

[Janis Johnson]

On Fri, Feb 22, 2002 at 03:30:04PM -0800, George.R.Goffe@seagate.com wrote:
> 
> sparc-sun-solaris2.7

> sparc-sun-solaris2.8

Thanks!  I've added these to the GCC 3.0 build status list at
http://gcc.gnu.org/gcc-3.0/buildstat.html.

Someone pointed out that the options --with-gnu-as-path and
--with-gnu-ld-path are not valid; if you respond with additional
information about that, please do it as a response to your earlier
mail so that it will appear in the same thread as the message that
is linked from the build status page.

Janis

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Alexandre Oliva]

On Feb 25, 2002, Peter Barada <pbarada@mail.wm.sps.mot.com> wrote:

> Have the top-level configuration script build a file that contains
> a list of the configuration option passed in, one per line, and the
> sub-packages configure script removes from the list those options that
> it understands.  At the end of all the sub-package configurations, if
> there is anything left in the list then its either unknown or mispelled.
> Of course the top-level configuration script would any that it
> undrestands.

There are options that apply to more than one sub-package, so this
won't work.  It could be made to work with some refinement, but still,
it would require every single sub-configure to be modified.

One could use the cache file to store pending options: initialized by
whoever creates the cache file, namely the top-level configure, and
such that each sub-package could take options it understood out of it,
but would still use the options it actually gets for the purpose of
telling which options are active.

At the end, the top-level configure looks at the cache file and checks
whether any option remained.  If so, it warns about it.

Yeah, that sounds pretty reasonable.  And it doesn't even require
changes in autoconf.  But it does require a configure script to know
whether it's the top-level one (easy to do, assuming we use
config.cache to tell), and it won't work if config.cache is /dev/null
or some other pre-exiting file.  Still, worth looking into.

-- 
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: 3.0.4 builds for solaris 2.7 and 2.8

[Peter Barada]

>> I've reported before being bitten by misspelling configure options,
>> and configure does not report an error.
>
>So which of the configure scripts do you suggest to look for unknown
>flags and report them?
>
>Remember that it can't be the top-level configure because it's used to
>build a number of different sub-packages, each of which has its own
>set of configure options that keep changing, and it can't be any of
>the sub-packages' configure scripts because those shouldn't have to
>know about each other :-)

If you're asking for ideas, howsa about this one :-)

Have the top-level configuration script build a file that contains
a list of the configuration option passed in, one per line, and the
sub-packages configure script removes from the list those options that
it understands.  At the end of all the sub-package configurations, if
there is anything left in the list then its either unknown or mispelled.
Of course the top-level configuration script would any that it
undrestands.

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Phil Edwards]

On Sun, Feb 24, 2002 at 09:08:24AM -0300, Alexandre Oliva wrote:
> On Feb 24, 2002, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> 
> > For example, one way to achieve this would be for the configure
> > scripts to accept a new option `--list-supported-options',
[...]
> The best option would be to run `sub/configure --help' and extract the
> list of options from that,

For an example, see the "bash autocompletion" project:

    http://freshmeat.net/projects/bashcompletion/

This hooks arbitrary commands to arbitrary shell functions.  When
"<Tab><Tab>" is used to try and auto-complete a command, the appropriate
shell function is executed to generate the list of possible completions.

Somebody has already contributed a function for "configure" commands.  If you

    ..../configure --<tab>

the function runs "configure --help" and then strips out the possible
completions.  It's rather handy.

I've already sent in another function to do the same thing with the GCC
frontends, e.g., typing "g++ -f<tab><tab>" will list all the -f* options.
Yet more motivation for documenting the options...


> but even then, you could miss some, because
> --help doesn't recurse to sub-sub-packages.

Win some, lose some.  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Alexandre Oliva]

On Feb 24, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

> All you need is to have the sub-packages produce a parsable list of
> acceptable options at autoconf-time and have the top-level configure
> read that it to verify them.

Yup.  This was actually debated in a long thread in one of the
autoconf mailing lists probably more than a year ago.  The end result
was that nobody stepped forward to implement it.  No point in our
wasting time duplicating that discussion here :-)

-- 
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: 3.0.4 builds for solaris 2.7 and 2.8

[Mark Mitchell]

> Remember that it can't be the top-level configure because it's used to
> build a number of different sub-packages

Gong!

All you need is to have the sub-packages produce a parsable list of
acceptable options at autoconf-time and have the top-level configure
read that it to verify them.

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

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Fergus Henderson]

On 24-Feb-2002, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Feb 24, 2002, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> 
> > For example, one way to achieve this would be for the configure
> > scripts to accept a new option `--list-supported-options',
> 
> Right.  The problem is that, from then on, --list-supported-options
> becomes a requirement for all sub-configures.

That could be solved by just not enforcing the check if any sub-configure
doesn't support --list-supported-options.  You'd only get the check if all
sub-configures were built with sufficiently recent version of autoconf.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Alexandre Oliva]

On Feb 24, 2002, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:

> For example, one way to achieve this would be for the configure
> scripts to accept a new option `--list-supported-options',

Right.  The problem is that, from then on, --list-supported-options
becomes a requirement for all sub-configures.  Which means you can no
longer use whatever version of autoconf you want (or the sub-package
demands) to generate them, but rather some particular version that
introduces support for this flag.

The best option would be to run `sub/configure --help' and extract the
list of options from that, but even then, you could miss some, because
--help doesn't recurse to sub-sub-packages.

The difficulty lies in the fact that --help is mostly free-hand, and a
number of packages output help with --with-option[=...] and/or
--without-option, ditto for enable/disable, so you'd also have to
filter through that.

Another point to be taken into account is that a package is not
*required* to document all of its options.  In fact, packages are free
to use ${enable_option} and ${with_option} variables without any trace
of documentation to that.  Starting to prohibit the use of such
options in them would probably not be welcome (as many other changes
introduced in autoconf 2.50 that helped expose bugs in existing
configure.in scripts have shown).

Yet another difficulty is that the top-level configure should pass
down an option to prevent sub-packages from performing the same checks
over and over.  This should probably be a regular --disable-* option,
such that packages unaware of yet another option wouldn't error out
when encountering it, so that the top-level configure could pass it
down irregardless of the sub-package supporting it.

Still, I like the idea, and I hope some day we could at least warn
about options not known to be supported.  But that's something for
autoconf to take care of, not GCC.

-- 
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: 3.0.4 builds for solaris 2.7 and 2.8

[Fergus Henderson]

On 23-Feb-2002, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Feb 23, 2002, lucier@math.purdue.edu wrote:
> 
> > I've reported before being bitten by misspelling configure options,
> > and configure does not report an error.
> 
> So which of the configure scripts do you suggest to look for unknown
> flags and report them?
>
> Remember that it can't be the top-level configure because it's used to
> build a number of different sub-packages, each of which has its own
> set of configure options that keep changing, and it can't be any of
> the sub-packages' configure scripts because those shouldn't have to
> know about each other :-)

Obviously the different configure scripts should cooperate.

For example, one way to achieve this would be for the configure
scripts to accept a new option `--list-supported-options',
which would cause the configure script to just echo the
supported --with-* and --enable-* option names.
The top-level configure script could then invoke all the
subdirectory configure scripts with --list-supported-options
to figure out which options were supported by the subdirectory
configure scripts, and could then issue an error or warning
message for options which are not supported.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Alexandre Oliva]

On Feb 23, 2002, Brad Lucier <lucier@math.purdue.edu> wrote:

>> 
>> On Feb 23, 2002, Brad Lucier <lucier@math.purdue.edu> wrote:
>> 
>> > OK, how about a warning from the top-level configure for options it
>> > can't recognize?
>> 
>> It would be a maintenance burden to whoever modifies any of the
>> sub-packages' set of supported options.

> I meant that the top-level configure would be allowed to give a
> warning about a valid subconfigure option.

So what's the gain?  User thinks he misspelled the option when he
didn't, or gets used to the warning and ignores it when it strikes for
real.

>> However, such patch wouldn't life very long, since we have a volunteer
>> autoconfiscating the top-level configure script.

> OK, does that mean I should stop discussing this, that it just won't be
> done?

Let's say that I wouldn't like to maintain this, but if you would,
feel free to contribute patches to enable this feature, and keep
watching gcc-patches for new configure flags to either remind people
to adjust the top-level configure or adjust it yourself :-)

-- 
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: 3.0.4 builds for solaris 2.7 and 2.8

[Brad Lucier]

> 
> On Feb 23, 2002, Brad Lucier <lucier@math.purdue.edu> wrote:
> 
> > OK, how about a warning from the top-level configure for options it
> > can't recognize?
> 
> It would be a maintenance burden to whoever modifies any of the
> sub-packages' set of supported options.

I meant that the top-level configure would be allowed to give a warning about a
valid subconfigure option.

> However, such patch wouldn't life very long, since we have a volunteer
> autoconfiscating the top-level configure script.

OK, does that mean I should stop discussing this, that it just won't be
done?

Brad

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Alexandre Oliva]

On Feb 23, 2002, Brad Lucier <lucier@math.purdue.edu> wrote:

> OK, how about a warning from the top-level configure for options it
> can't recognize?

It would be a maintenance burden to whoever modifies any of the
sub-packages' set of supported options.

The whole point of --with/--without and --enable/--disable flags in
configure is that it's open-ended, such that you can use the same set
of flags for any packages you build (unless they happen to use the
same flag for totally different purposes), such that you can create a
single wrapper configure script (like the one in gcc) that passes the
same flags to all of the sub-packages without being concerned with
their meaning.  It's up to each package to interpret the flags it
recognizes and ignore those that it doesn't.

That said, I'll give you that the set of configure options accepted by
each sub-package doesn't change very often, so it wouldn't be that
much of a maintenance burden.  So I wouldn't oppose a patch that
implemented the feature you suggest.

However, such patch wouldn't life very long, since we have a volunteer
autoconfiscating the top-level configure script.

-- 
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: 3.0.4 builds for solaris 2.7 and 2.8

[Brad Lucier]

> On Feb 23, 2002, lucier@math.purdue.edu wrote:
> 
> > I've reported before being bitten by misspelling configure options,
> > and configure does not report an error.
> 
> So which of the configure scripts do you suggest to look for unknown
> flags and report them?
> 
> Remember that it can't be the top-level configure because it's used to
> build a number of different sub-packages, each of which has its own
> set of configure options that keep changing, and it can't be any of
> the sub-packages' configure scripts because those shouldn't have to
> know about each other :-)

OK, how about a warning from the top-level configure for options it
can't recognize?

Brad

Re: 3.0.4 builds for solaris 2.7 and 2.8

[Alexandre Oliva]

On Feb 23, 2002, lucier@math.purdue.edu wrote:

> I've reported before being bitten by misspelling configure options,
> and configure does not report an error.

So which of the configure scripts do you suggest to look for unknown
flags and report them?

Remember that it can't be the top-level configure because it's used to
build a number of different sub-packages, each of which has its own
set of configure options that keep changing, and it can't be any of
the sub-packages' configure scripts because those shouldn't have to
know about each other :-)

-- 
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: 3.0.4 builds for solaris 2.7 and 2.8

[lucier]

Re:

Alexandre Oliva writes

> On Feb 22, 2002, George.R.Goffe@seagate.com wrote:
> 
> > --with-gnu-as-path=/usr/lsd/SunOS.5.7/bin/as --with-gnu-ld
> > --with-gnu-ld-path=/usr/lsd/SunOS.5.7/bin/ld
>   ^^^^^^^^^^^^^^^^^^
> 
> These options have no effect at all.  Perhaps you meant --with-as and
> --with-ld?

I've reported before being bitten by misspelling configure options,
and configure does not report an error.

It would be *really*, *really* nice if configure would abort if you gave
it an option that it doesn't understand, rather than just going quietly,
and merrily, on its way.

Brad