Re: AC_TYPE_UINT32_T and AC_TYPE_UINTMAX_T nits

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

>   * lib/autoconf/types.m4 (_AC_TYPE_INT): Set `$ac_cv_c_int$1_t'
>   to `yes' instead of `int$1_t' if the type is found, for more
>   consistent configure output (where $1 is the number of bits).
>   (_AC_TYPE_UINT): Likewise for `uint$1_t'.
>   Suggested by Bruno Haible.

Thanks, please apply.  I agree that the other problem can be deferred
until after 2.60.

Re: Bug#372179: AC_CANONICAL_SYSTEM overwrites $@

[Tollef Fog Heen]

* Ralf Wildenhues 

| Hello Justin, Tollef,
| 
| * Justin Erenkrantz wrote on Sun, Jun 18, 2006 at 11:40:12PM CEST:
| > On 6/18/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
| > >Currently, if configure is passed --sbindir=, it just overrides
| > >$sbindir without flagging that at all.  If it, in addition to changing
| > >$sbindir, it'd set ac_param_sbindir either to 1 to show that sbindir
| > >is derviced from a command line argument or to the value passed on the
| > >command line.  If we had this, APR_LAYOUT could check if
| > >ac_param_sbindir was set, and if so skip setting sbindir from the
| > >layout.
| > >
| > >Would this be an acceptable solution for both the APR and the autoconf
| > >people?
| > 
| > That could work for our purposes, yes.  It'd be cleaner to boot, too.  
| 
| So what do you do with
|   --bindir=/foo --with-layout=bar --sbindir=/baz
| 
| shouldn't the bar layout override bindir but not sbindir?  (Note I don't
| know the exact semantics --with-layout is supposed to have.)

IMO, command line ordering shouldn't matter, unless you do
--bindir=/foo --bindir=/bar.  --with-layout just changes the defaults,
it doesn't override the state you're currently in.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Spurious datarootdir warnings in Wine configure

[Alexandre Julliard]

The following recent change

  
http://cvs.savannah.gnu.org/viewcvs/autoconf/lib/autoconf/status.m4?root=autoconf&r1=1.110&r2=1.111

is causing warnings in the Wine configure:

configure: creating ./config.status
config.status: creating Make.rules
config.status: creating dlls/Makedll.rules
config.status: WARNING: dlls/Makedll.rules contains a reference to the variable 
`datarootdir'
which seems to be undefined.  Please make sure it is defined.
config.status: creating dlls/Makeimplib.rules
config.status: WARNING: dlls/Makeimplib.rules contains a reference to the 
variable `datarootdir'
which seems to be undefined.  Please make sure it is defined.
config.status: creating dlls/Maketest.rules
config.status: WARNING: dlls/Maketest.rules contains a reference to the 
variable `datarootdir'
which seems to be undefined.  Please make sure it is defined.
config.status: creating libs/Makelib.rules
config.status: WARNING: libs/Makelib.rules contains a reference to the variable 
`datarootdir'
which seems to be undefined.  Please make sure it is defined.
config.status: creating programs/Makeprog.rules
config.status: WARNING: programs/Makeprog.rules contains a reference to the 
variable `datarootdir'
which seems to be undefined.  Please make sure it is defined.
config.status: creating Makefile
config.status: WARNING: Makefile contains a reference to the variable 
`datarootdir'
which seems to be undefined.  Please make sure it is defined.
etc.

That's because in Wine, datarootdir is defined in the global
Make.rules file, which is then included into the individual makefiles
using AC_SUBST_FILE. This means ${datarootdir} is legitimately present
in the output without being part of the current input file.

I'm happy to add a workaround in Wine if you can suggest one,
preferably one that doesn't involve defining datarootdir in every
individual makefile...

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: 2.59d on OpenServer

[Kean Johnston]

Between 2.59 and 2.59e we have changed macros to not expand to long
lines in the resulting scripts, but apparently some shells not only
have limits in the line length, but also in the length of the assignment
string; now, Kean's message above seems to imply that this length
limitation is _before_ variable expansion, not afterwards.  Is that
really the case?  IOW: is (a forward-ported and bug-fixed version of)
the patch above still necessary for 2.59e?

Oops I was finally able to reproduce it with a smaller script. I
put the preamble of the generated configure script into my test
and it now barfs on the really long lines. And the limitation
really does seem to be at about 4000 characters (give or take a bit)
*before* expansion. So I can have:

  longvar="4K_of_text"
  longvar="$longvar 4K_more_of_text"

but not

  longvar="4K_of_text 4K_more_of_text"

but this limitation is *only* imposed when I have the beginning part
of the configure script, it does not apply if I simply write a script
with those contents. When I say "configure preamble" I mean the top
part of a configure script up to the bit where it sets the identity
of the package.

I'm not really sure how to diagnose this further. Also, I will not
personally be able to fix it, because I no longer work for SCO,
I just answer the occasional email such as this one :) But if we
find a recipe for how to reproduce it, I can certainly get in touch
with the right person.

Kean

PS. I'm sending this from my personal account which is the
preferred email address to use for me (I forgot to switch
accounts in my first reply).

--
"Your self-crippling is your own business just as your limitations
 are society’s burden" -- Dan Simmons

Re: Spurious datarootdir warnings in Wine configure

[Ralf Wildenhues]

Hi Alexandre,

* Alexandre Julliard wrote on Mon, Jun 19, 2006 at 01:23:13PM CEST:
> The following recent change

> is causing warnings in the Wine configure:

> config.status: creating dlls/Makedll.rules

> That's because in Wine, datarootdir is defined in the global
> Make.rules file, which is then included into the individual makefiles
> using AC_SUBST_FILE. This means ${datarootdir} is legitimately present
> in the output without being part of the current input file.
> 
> I'm happy to add a workaround in Wine if you can suggest one,
> preferably one that doesn't involve defining datarootdir in every
> individual makefile...

Yes.  If you don't mind, you could add this line
  # This comment contains 'datarootdir' to shut up config.status.

to your files.  I hope that is ok for you.

Cheers,
Ralf

Re: Spurious datarootdir warnings in Wine configure

[Alexandre Julliard]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> * Alexandre Julliard wrote on Mon, Jun 19, 2006 at 01:23:13PM CEST:
>> I'm happy to add a workaround in Wine if you can suggest one,
>> preferably one that doesn't involve defining datarootdir in every
>> individual makefile...
>
> Yes.  If you don't mind, you could add this line
>   # This comment contains 'datarootdir' to shut up config.status.
>
> to your files.  I hope that is ok for you.

Well, that isn't much better than defining it, since we have to do it
in all the files. We currently have about 300 makefiles, so having to
maintain that sort of thing in all of them is annoying.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: 2.59d on OpenServer

[Ralf Wildenhues]

Hi Kean,

Thank you for your work on this.

* Kean Johnston wrote on Sun, Jun 18, 2006 at 06:31:56PM CEST:
> So I can have:
> 
>   longvar="4K_of_text"
>   longvar="$longvar 4K_more_of_text"
> 
> but not
> 
>   longvar="4K_of_text 4K_more_of_text"
> 
> but this limitation is *only* imposed when I have the beginning part
> of the configure script, it does not apply if I simply write a script
> with those contents. When I say "configure preamble" I mean the top
> part of a configure script up to the bit where it sets the identity
> of the package.

Did you try removing the
  BIN_SH=xpg4; export BIN_SH

and the 'set -o posix' part?  Or maybe the part where it searches for a
better shell to not begin searching in /usr/bin/posix?  (I think it was
likely that Autoconf 2.59 did not expose this issue, so something that
was changed in between is the trigger.)

> I'm not really sure how to diagnose this further. Also, I will not
> personally be able to fix it, because I no longer work for SCO,
> I just answer the occasional email such as this one :)

Well, I'm afraid then if we don't find another shell or another person
that uses the shell and helps out with bug reports and/or testing for
the GNU autotools, then it's IMHO not worth pursuing.  Tim agreed we
could ignore this, and really you two guys are the only reason I've
been looking at this at all; if support for some not-really-popular
(to make it an understatement) system is going to rot anyway, we might
as well leave it that way.

IOW, I think we should not put known-worse-scaling algorithms in
Autoconf for issues we don't know the exact cause of and without
seeing test results that are fixed by them, or output of some
package's configure that is unbroken by them.  Please complain if
you disagree.

Cheers,
Ralf

Re: Spurious datarootdir warnings in Wine configure

[Ralf Wildenhues]

* Alexandre Julliard wrote on Mon, Jun 19, 2006 at 05:50:04PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> > * Alexandre Julliard wrote on Mon, Jun 19, 2006 at 01:23:13PM CEST:
> >> I'm happy to add a workaround in Wine if you can suggest one,
> >> preferably one that doesn't involve defining datarootdir in every
> >> individual makefile...
> >
> > Yes.  If you don't mind, you could add this line

> Well, that isn't much better than defining it, since we have to do it
> in all the files. We currently have about 300 makefiles, so having to
> maintain that sort of thing in all of them is annoying.

OK.  We need a way to turn this mechanism off.  Stay tuned.

Cheers,
Ralf

Re: 2.59d on OpenServer

[Kean Johnston]

Did you try removing the
  BIN_SH=xpg4; export BIN_SH

and the 'set -o posix' part?  Or maybe the part where it searches for a
better shell to not begin searching in /usr/bin/posix?  (I think it was

I will try that and report back.


I'm not really sure how to diagnose this further. Also, I will not
personally be able to fix it, because I no longer work for SCO,
I just answer the occasional email such as this one :)


Well, I'm afraid then if we don't find another shell or another person
that uses the shell and helps out with bug reports and/or testing for
the GNU autotools, then it's IMHO not worth pursuing.  Tim agreed we
could ignore this, and really you two guys are the only reason I've
been looking at this at all; if support for some not-really-popular
(to make it an understatement) system is going to rot anyway, we might
as well leave it that way.

Well, even though I dont work for SCO any more, most of my friends
do, and they will be more than happy to make any changes I suggest.
But I think there is an easier way to fix this.  bash is provided
on OpenServer 5 and OpenServer 6. UnixWare has a shell that works
without these limitations. Wouldn't the path of least resistance
be to simply set CONFIG_SHELL to /usr/bin/bash on OSR5 and OSR6 and
to /usr/bin/posix/sh on UnixWare 7 simply solve all of these
problems?

Kean
--
"Your self-crippling is your own business just as your limitations
 are society’s burden" -- Dan Simmons

Re: Bug#372179: AC_CANONICAL_SYSTEM overwrites $@

[Justin Erenkrantz]

On 6/19/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:

* Ralf Wildenhues

| Hello Justin, Tollef,
|
| * Justin Erenkrantz wrote on Sun, Jun 18, 2006 at 11:40:12PM CEST:
| > On 6/18/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
| > >Currently, if configure is passed --sbindir=, it just overrides
| > >$sbindir without flagging that at all.  If it, in addition to changing
| > >$sbindir, it'd set ac_param_sbindir either to 1 to show that sbindir
| > >is derviced from a command line argument or to the value passed on the
| > >command line.  If we had this, APR_LAYOUT could check if
| > >ac_param_sbindir was set, and if so skip setting sbindir from the
| > >layout.
| > >
| > >Would this be an acceptable solution for both the APR and the autoconf
| > >people?
| >
| > That could work for our purposes, yes.  It'd be cleaner to boot, too.
|
| So what do you do with
|   --bindir=/foo --with-layout=bar --sbindir=/baz
|
| shouldn't the bar layout override bindir but not sbindir?  (Note I don't
| know the exact semantics --with-layout is supposed to have.)

IMO, command line ordering shouldn't matter, unless you do
--bindir=/foo --bindir=/bar.  --with-layout just changes the defaults,
it doesn't override the state you're currently in.


Correct.  Anything explicitly provided on the command-line is
literally respected - the layout file just allows the user to change
autoconf's defaults in a straightforward manner.  -- justin

Re: Spurious datarootdir warnings in Wine configure

[Alexandre Julliard]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> * Alexandre Julliard wrote on Mon, Jun 19, 2006 at 05:50:04PM CEST:
>> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> > * Alexandre Julliard wrote on Mon, Jun 19, 2006 at 01:23:13PM CEST:
>> >> I'm happy to add a workaround in Wine if you can suggest one,
>> >> preferably one that doesn't involve defining datarootdir in every
>> >> individual makefile...
>> >
>> > Yes.  If you don't mind, you could add this line
>
>> Well, that isn't much better than defining it, since we have to do it
>> in all the files. We currently have about 300 makefiles, so having to
>> maintain that sort of thing in all of them is annoying.
>
> OK.  We need a way to turn this mechanism off.  Stay tuned.

Maybe you could grep the output file for something like
/^[ \t]*datarootdir[ \t]*=/ to check if it's being defined, even if
it's not present in the input file?  Not sure how reliable that would
be, but it would work for us.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: 2.59d on OpenServer

[Ralf Wildenhues]

* Kean Johnston wrote on Mon, Jun 19, 2006 at 06:04:12PM CEST:
> Wouldn't the path of least resistance be to simply set CONFIG_SHELL to
> /usr/bin/bash on OSR5 and OSR6 and to /usr/bin/posix/sh on UnixWare 7
> simply solve all of these problems?

Sure, if /usr/bin/posix/sh also works fine.  I thought it was
/usr/bin/posix/sh that introduced the problems, though.

Cheers,
Ralf

Re: 2.59d on OpenServer

[Kean Johnston]

Sure, if /usr/bin/posix/sh also works fine.  I thought it was
/usr/bin/posix/sh that introduced the problems, though.


Only on OSR6, not UnixWare. Thats why I suggested to use
bash on OSR5 and OSR6, and /usr/bin/posix/sh on UW7.

Kean

Re: 2.59d on OpenServer

[Tim Rice]

On Mon, 19 Jun 2006, Kean Johnston wrote:

> > Sure, if /usr/bin/posix/sh also works fine.  I thought it was
> > /usr/bin/posix/sh that introduced the problems, though.
> 
> Only on OSR6, not UnixWare. Thats why I suggested to use
> bash on OSR5 and OSR6, and /usr/bin/posix/sh on UW7.

FYI. John Boland has raised a bug report asking for /usr/bin/posix/sh
to link to ksh93 on OSR6 instead of ksh88.

> 
> Kean
> 
> 
> 

-- 
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]

Re: 2.59d on OpenServer

[Tim Rice]

On Sun, 18 Jun 2006, Ralf Wildenhues wrote:

> > It looks like the "at_help_all" variable has 12270 characters in it.
> > The ksh (/usr/bin/posix/sh is a symbolic link to ksh) is blowing up
> > at 4074 characters.
> 
> Does the patch below fix this for you?  It is just a wee bit unfortunate
> because with most shells it causes quadratic initialization time, which
> in practice means something like doubled overhead for Autoconf's
>   ./tests/testsuite --list

While it allows the testsuite to be run...
...
ERROR: 269 tests were run,
138 failed (5 expected failures).
16 tests were skipped.
...

> 
> Cheers,
> Ralf
> 
>   * lib/autotest/general.m4 (AT_CLEANUP): Define `AT_help_all'
>   to append a line to the shell variable `at_help_all'.
>   (AT_INIT): Adjust accordingly, so that variable assignment
>   statement length does overflow OpenServer /usr/bin/posix/sh
> limits.  Reported by Tim Rice in
> 
> .

-- 
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]

Re: man pages for config.guess and friends

[Ben Elliston]

> > I suggest to move the man pages for config.guess and config.sub from
> > autoconf to the config CVS.
> 
> May be a good idea, if Ben agrees.  I think this can safely wait until
> after Autoconf 2.60, though, which we'd like to release ASAP.

I was not even aware that man pages exist; naturally I would be happy
to maintain them in the config CVS repository.

Thanks, Ben

Re: bug in AC_TYPE_UINT32_T on Solaris 2.5.1

[Ralf Wildenhues]

Hello Paul,

Thanks for your research!

* Paul Eggert wrote on Mon, Jun 19, 2006 at 08:46:20AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > * lib/autoconf/types.m4 (_AC_TYPE_UNSIGNED_INT): Solaris 2.5.1
> > needs _UINT8_T and _UINT64_T defines as well, to avoid clashes
> > with system headers.  Report by Bruno Haible.
> 
> That looks good; please install, since it's clearly an improvement.

Hmm, let's see...

> For what it's worth,
>  says that
> Solaris 2.5.1  "defines uint8_t, uint32_t and uint64_t (and
> only those, not the full C99 set)".

...and if we follow this thread until
http://gcc.gnu.org/ml/fortran/2005-11/msg00839.html
it's not so clear any more.  I can't find any usage of those defines
in my copy of the Cygwin headers, though.  Maybe it's not a problem any
more; we'll see.

I have applied the patch.

Cheers,
Ralf

Re: bug in AC_TYPE_UINT32_T on Solaris 2.5.1

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Maybe it's not a problem any more; we'll see.

It's not a problem for Cygwin since their philosophy, I guess, is that
you Should Just Upgrade.

Solaris 2.5.1 is more of an issue.  Its official end of service life
was 2005-09-22, and since Sun no longer has standard support contracts
for it then one could well argue we shouldn't have to worry about
2.5.1 either, and this is the attitude I take for other GNU projects I
maintain.  However, I suppose Autoconf has to be a bit more
conservative, since some of our users are more conservative.

Reference:

http://www.sun.com/service/eosl/solaris/solaris_vintage_eol_5.2005.html

Re: 2.59d on OpenServer

[Stepan Kasal]

On Mon, Jun 19, 2006 at 06:21:54PM +0200, Ralf Wildenhues wrote:
> * Kean Johnston wrote on Mon, Jun 19, 2006 at 06:04:12PM CEST:
> > Wouldn't the path of least resistance be to simply set CONFIG_SHELL to
> > /usr/bin/bash on OSR5 and OSR6 and to /usr/bin/posix/sh on UnixWare 7
> > simply solve all of these problems?
> 
> Sure, if /usr/bin/posix/sh also works fine.  I thought it was
> /usr/bin/posix/sh that introduced the problems, though.

Hello,
  it seems that it would be better to prefer bash over sh.  And we
might search for bash in all dirs, then for /usr/bin/posix/sh (a
special case), then for sh everywher, then for ksh, etc.
  But this stirs the shell selecion very much; it's obvious that it
has to wait after the release.  Bnd I do not think any quick actioon is
neeeded rigt now.

Stepan