Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]


[CC newlib mailing list since it affects newlib in the first place]

On Aug 21 14:28, Hans-Bernhard Bröker wrote:
> Am 21.08.2016 um 12:30 schrieb Corinna Vinschen:
> 
> > thanks for the report, but I can't reproduce this.  I can build Cygwin
> > fine natively as well as on Linux, with and without optimization.
> 
> That's strange.  On Re-examination, it builds here, too, even without the
> added include.  I.e. effectively it took only a `touch` of wcwidth.c to fix
> this.
> 
> Could there be a problem with the dependency handling in the newlib auto-foo
> which caused changes to header files to fail triggering a rebuild?

Yes.  If you just pulled and rebuilt, there's a chance that you got
the new headers without triggering a rebuild of dependent sources.

> And while I'm at it: what _is_ the dependency handling here, anyway?  I
> can't seem to find any.  Which could indeed explain the problem.

That's because dependency handling is basically non-existing in newlib.

Nobody added a patch yet to do that.  Newlib being open-source, there's
of course nothing keeping anybody from adding it (*nudge*, *nudge*).

A big problem for many people keeping them from provide patches to the
configury is that newlib's build system still requires the automake
--cygnus option, which isn't supported by automake for quite some time.
The trick is to use an older versions of automake for rebuilding the
configury.  I'm having goods results with this script, which can be
called from newlib or the libc/libm subdirs:

  #!/bin/bash
  aclocal-1.12.2 -I. -I..
  autoconf
  automake-1.12.2 --cygnus --no-force

The autoconf version actually doesn't matter much so I'm using 2.69.

I'm not automake savvy enough to know what to do to get rid of the
--cygnus requirement :(


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Hans-Bernhard Bröker]

[Now subscribed to newlib list to follow this there, too]

Hi Corinna, hi everyone on both lists

Am 21.08.2016 um 20:15 schrieb Corinna Vinschen:
> [CC newlib mailing list since it affects newlib in the first place]

> On Aug 21 14:28, Hans-Bernhard Bröker wrote:
>> Am 21.08.2016 um 12:30 schrieb Corinna Vinschen:

>> And while I'm at it: what _is_ the dependency handling here, anyway?  I
>> can't seem to find any.  Which could indeed explain the problem.

> That's because dependency handling is basically non-existing in newlib.

> Nobody added a patch yet to do that.  Newlib being open-source, there's
> of course nothing keeping anybody from adding it (*nudge*, *nudge*).

That wouldn't be so much a patch as a redesign, I'm afraid, because it's 
strongly tied to the following:

> A big problem for many people keeping them from provide patches to the
> configury is that newlib's build system still requires the automake
> --cygnus option, which isn't supported by automake for quite some time.

And one of the effects of --cygnus is: to enables option 
"no-dependencies", thus turning off dependency tracking.  Hrmpf.

So let's see how far I get trying to un--cygnusify newlib (as part of 
Cygwin):

1) Get rid of for'cygnus' options. In all 134 Makefile.am replace

	AUTOMAKE_OPTIONS = cygwin
by 	AUTOMAKE_OPTIONS = foreign no-installinfo no-dist
and delete cygnus from one or two AM_INIT([]) calls, too

2) autoupdate in newlib, using autoconf-2.69 and automake-1.15
3) autoreconf in newlib, using autoconf-2.69 and automake-1.15
4) run "make" in my build dir
5) touch libc/locale/setlocale.h
6) run "make" again

Et voila!  Step 6 now recompiles 4 files that depend on setlocale.h, 
then re-builds the libraries using them

7) Get a rough glimpse of what I did:

$ git diff --stat newlib | tail -1
  438 files changed, 264967 insertions(+), 101151 deletions(-)

Well, that's what you get for having generated files like Makefile.in, 
configure and aclocal.m4 in version control...


> The trick is to use an older versions of automake for rebuilding the
> configury.  I'm having goods results with this script, which can be
> called from newlib or the libc/libm subdirs:
>
>   #!/bin/bash
>   aclocal-1.12.2 -I. -I..
>   autoconf
>   automake-1.12.2 --cygnus --no-force

Side note: in a cygwin environment (or any that uses Gentoo's 
automake/autoconf wrapper scripts), this should be reducible to:

	WANT_AUTOMAKE=1.12 autoreconf -I. -I..

But I'm afraid the time this approach worked reliably may be nearing its 
end.  Automake-1.11/1.12 appears to be no longer fully compatible with 
current versions of Perl.  At least I don't remember having had error 
messages like this back when 1.12 or 1.11 were still on point:

main::scan_file() called too early to check prototype at 
/usr/bin/aclocal-1.11 line 644.

> The autoconf version actually doesn't matter much so I'm using 2.69.

That did not work for me. config/override.m4 insisted rather strictly 
that only 2.64 is allowed to be used.  I shredded lines 30ff. from that 
file to get past that one.

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4492 bytes --]

Hi Hans-Bernhard,

On Aug 22 00:18, Hans-Bernhard Bröker wrote:
> [Now subscribed to newlib list to follow this there, too]

Cool!  I think we can drop the cygwin ML list from CC then.

The winsup dir is not affected by this problem.  To wit, it has it's own
kind of problems, mainly that it does not use automake at all and that
it's using a perl script to wrap the compiler invocation instead of using
more standard means.  But I digress.

> Hi Corinna, hi everyone on both lists
> 
> Am 21.08.2016 um 20:15 schrieb Corinna Vinschen:
> > [CC newlib mailing list since it affects newlib in the first place]
> 
> > On Aug 21 14:28, Hans-Bernhard Bröker wrote:
> > > Am 21.08.2016 um 12:30 schrieb Corinna Vinschen:
> 
> > > And while I'm at it: what _is_ the dependency handling here, anyway?  I
> > > can't seem to find any.  Which could indeed explain the problem.
> 
> > That's because dependency handling is basically non-existing in newlib.
> 
> > Nobody added a patch yet to do that.  Newlib being open-source, there's
> > of course nothing keeping anybody from adding it (*nudge*, *nudge*).
> 
> That wouldn't be so much a patch as a redesign, I'm afraid, because it's
> strongly tied to the following:
> 
> > A big problem for many people keeping them from provide patches to the
> > configury is that newlib's build system still requires the automake
> > --cygnus option, which isn't supported by automake for quite some time.
> 
> And one of the effects of --cygnus is: to enables option "no-dependencies",
> thus turning off dependency tracking.  Hrmpf.

Oh!  I really didn't know that.

> So let's see how far I get trying to un--cygnusify newlib (as part of
> Cygwin):

Yeah, a full solution would also un-cygnusify libgloss, but it's not
used in Cygwin so you won't notice.

> 1) Get rid of for'cygnus' options. In all 134 Makefile.am replace
> 
> 	AUTOMAKE_OPTIONS = cygwin
> by 	AUTOMAKE_OPTIONS = foreign no-installinfo no-dist
> and delete cygnus from one or two AM_INIT([]) calls, too
> 
> 2) autoupdate in newlib, using autoconf-2.69 and automake-1.15
> 3) autoreconf in newlib, using autoconf-2.69 and automake-1.15
> 4) run "make" in my build dir
> 5) touch libc/locale/setlocale.h
> 6) run "make" again
> 
> Et voila!  Step 6 now recompiles 4 files that depend on setlocale.h, then
> re-builds the libraries using them

Yay!

> 7) Get a rough glimpse of what I did:
> 
> $ git diff --stat newlib | tail -1
>  438 files changed, 264967 insertions(+), 101151 deletions(-)
> 
> Well, that's what you get for having generated files like Makefile.in,
> configure and aclocal.m4 in version control...

Ok, that's a a minor problem, just lots of bytes to push.  All ex-Cygnus
trees (gcc, binutils-gdb, newlib-cygwin) have the generated files as
part of their repository.

If you're willing to provide a patch, the patch does not have to contain
the generated files.  I would create them locally and push the result.

> > The trick is to use an older versions of automake for rebuilding the
> > configury.  I'm having goods results with this script, which can be
> > called from newlib or the libc/libm subdirs:
> > 
> >   #!/bin/bash
> >   aclocal-1.12.2 -I. -I..
> >   autoconf
> >   automake-1.12.2 --cygnus --no-force
> 
> Side note: in a cygwin environment (or any that uses Gentoo's
> automake/autoconf wrapper scripts), this should be reducible to:
> 
> 	WANT_AUTOMAKE=1.12 autoreconf -I. -I..

Ok, thanks.

> But I'm afraid the time this approach worked reliably may be nearing its
> end.  Automake-1.11/1.12 appears to be no longer fully compatible with
> current versions of Perl.  At least I don't remember having had error
> messages like this back when 1.12 or 1.11 were still on point:
> 
> main::scan_file() called too early to check prototype at
> /usr/bin/aclocal-1.11 line 644.

Yeah, I was already wondering about this.  Patches *extremely* gratefully
accepted.

> > The autoconf version actually doesn't matter much so I'm using 2.69.
> 
> That did not work for me. config/override.m4 insisted rather strictly that
> only 2.64 is allowed to be used.  I shredded lines 30ff. from that file to
> get past that one.

Same here.  Neither Jeff nor I are autotools experts, so we would be
mightly happy if we could get patches to pull the repo to a newer
autotools state.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Aug 22 11:29, Corinna Vinschen wrote:
> Hi Hans-Bernhard,
> [...]
> > > The autoconf version actually doesn't matter much so I'm using 2.69.
> > 
> > That did not work for me. config/override.m4 insisted rather strictly that
> > only 2.64 is allowed to be used.  I shredded lines 30ff. from that file to
> > get past that one.
> 
> Same here.  Neither Jeff nor I are autotools experts, so we would be
> mightly happy if we could get patches to pull the repo to a newer
> autotools state.

Hang on.  Something dreadful just occured to me.  Would a change going
beyond --cygnus require to change toplevel?  The reason I'm asking is
that we share toplevel with the aforementioned ex-Cygnus repos gcc and
binutils-gdb.  If that won't work in future anymore this would make
quitte a dent in our evil plans...


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Peter Rosin]

On 2016-08-22 14:39, Corinna Vinschen wrote:
> On Aug 22 11:29, Corinna Vinschen wrote:
>> Hi Hans-Bernhard,
>> [...]
>>>> The autoconf version actually doesn't matter much so I'm using 2.69.
>>>
>>> That did not work for me. config/override.m4 insisted rather strictly that
>>> only 2.64 is allowed to be used.  I shredded lines 30ff. from that file to
>>> get past that one.
>>
>> Same here.  Neither Jeff nor I are autotools experts, so we would be
>> mightly happy if we could get patches to pull the repo to a newer
>> autotools state.
> 
> Hang on.  Something dreadful just occured to me.  Would a change going
> beyond --cygnus require to change toplevel?  The reason I'm asking is
> that we share toplevel with the aforementioned ex-Cygnus repos gcc and
> binutils-gdb.  If that won't work in future anymore this would make
> quitte a dent in our evil plans...

When Stefano Lattarini deprecated cygnus support in Automake, he talked
about "older" gcc and gdb relying on it. Don't know how much that is worth
though? But it was a few years ago now...

Cheers,
Peter

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

On Aug 22 15:24, Peter Rosin wrote:
> 
> 
> On 2016-08-22 14:39, Corinna Vinschen wrote:
> > On Aug 22 11:29, Corinna Vinschen wrote:
> >> Hi Hans-Bernhard,
> >> [...]
> >>>> The autoconf version actually doesn't matter much so I'm using 2.69.
> >>>
> >>> That did not work for me. config/override.m4 insisted rather strictly that
> >>> only 2.64 is allowed to be used.  I shredded lines 30ff. from that file to
> >>> get past that one.
> >>
> >> Same here.  Neither Jeff nor I are autotools experts, so we would be
> >> mightly happy if we could get patches to pull the repo to a newer
> >> autotools state.
> > 
> > Hang on.  Something dreadful just occured to me.  Would a change going
> > beyond --cygnus require to change toplevel?  The reason I'm asking is
> > that we share toplevel with the aforementioned ex-Cygnus repos gcc and
> > binutils-gdb.  If that won't work in future anymore this would make
> > quitte a dent in our evil plans...
> 
> When Stefano Lattarini deprecated cygnus support in Automake, he talked
> about "older" gcc and gdb relying on it. Don't know how much that is worth
> though? But it was a few years ago now...

I just checked binutils-gdb master:

$ find . -name '*.am' | xargs grep cygnus
./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
./bfd/doc/Makefile.am:# cygnus option.
./binutils/doc/Makefile.am:AUTOMAKE_OPTIONS = cygnus
./binutils/doc/Makefile.am:# cygnus option.
./gas/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus
./gas/doc/Makefile.am:# cygnus option.
./gold/Makefile.am:# the cygnus option.
./zlib/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus

However, in gcc master, only the zlib subdir still uses "cygnus",
so this looks like no change in toplevel is required.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Hans-Bernhard Bröker]

[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]

Hello Corinna,

Am 22.08.2016 um 11:29 schrieb Corinna Vinschen:
> On Aug 22 00:18, Hans-Bernhard Bröker wrote:
>> Am 21.08.2016 um 20:15 schrieb Corinna Vinschen:

>> [Now subscribed to newlib list to follow this there, too]
>
> Cool!  I think we can drop the cygwin ML list from CC then.

Fine with me.

>>> A big problem for many people keeping them from provide patches to the
>>> configury is that newlib's build system still requires the automake
>>> --cygnus option, which isn't supported by automake for quite some time.
>>
>> And one of the effects of --cygnus is: to enables option "no-dependencies",
>> thus turning off dependency tracking.  Hrmpf.
>
> Oh!  I really didn't know that.

I didn't either, until I looked it up and found

	info Automake-1.11 Cygnus

So here's the slightly amended recipe, as discovered so far:

>> 1) Get rid of for'cygnus' options. In all 134 Makefile.am replace
>>
>> 	AUTOMAKE_OPTIONS = cygwin
>> by 	AUTOMAKE_OPTIONS = foreign no-installinfo no-dist
>> and delete cygnus from one or two AM_INIT([]) calls, too
>>
>> 2) autoupdate in newlib, using autoconf-2.69 and automake-1.15

2.1) fix some breakage inserted by autoupdate (LT_INIT wants to be 
updated manually, some spurious __au_m4_changequote()),
2.2) repeat from 2) until no more errors

>> 3) autoreconf in newlib, using autoconf-2.69 and automake-1.15

3.1) add AM_PROG_AS to acinclude.m4, or autoreconf refuses to work
3.2) repeat from 3) until no more errors

> If you're willing to provide a patch, the patch does not have to contain
> the generated files.  I would create them locally and push the result.

Well, OK, so here goes. The core of the modification is best expressed 
as a pseudo shell script (don't run this without double-checking it!)

cd newlib
find . -type f -name 'Makefile.am' | \
   xargs sed -i -e '/AUTOMAKE_OPTIONS.*=/s/cygnus/foreign no-installinfo 
no-dist/'
cd ..

and then apply the attached patch 
"newlib-de-cygnussify-remaining-patch.diff" for the finer details, fix 
auto-tools to latest versions, then autoupdate, autoreconf.


>> main::scan_file() called too early to check prototype at
>> /usr/bin/aclocal-1.11 line 644.
>
> Yeah, I was already wondering about this.  Patches *extremely* gratefully
> accepted.

All I can see off-hand is that scan_file() calls itself recursively in 
that line 644, which would tend to explain that message.  aclocal-1.12 
gets rid of that by adding prototype declarations (lines 156 ff.). 
Back-porting most of those prototypes into 1.11.6 appears to get rid of 
this warning without too much pain.

A real Perl programmer should look over this, though.

>> That did not work for me. config/override.m4 insisted rather strictly that
>> only 2.64 is allowed to be used.  I shredded lines 30ff. from that file to
>> get past that one.
>
> Same here.  Neither Jeff nor I are autotools experts, so we would be
> mightly happy if we could get patches to pull the repo to a newer
> autotools state.
>

Well, FWIW, the attached lift-autconf-version-restriction.diff bluntly 
removes that restriction.  I won't guarante the absence of any adverse 
effect, thoughe ;-)

And just in case: yes, all these patches are free for unrestricted used 
by the public.

[-- Attachment #2: lift-autconf-version-restriction.diff --]
[-- Type: text/plain, Size: 1153 bytes --]

diff --git a/config/override.m4 b/config/override.m4
index 52bd1c3..3af7e21 100644
--- a/config/override.m4
+++ b/config/override.m4
@@ -27,27 +27,6 @@ AC_DEFUN([AC_PREREQ], [frob])
 m4_copy_force([_AC_PREREQ], [AC_PREREQ])
 
 
-dnl Ensure exactly this Autoconf version is used
-m4_ifndef([_GCC_AUTOCONF_VERSION],
-  [m4_define([_GCC_AUTOCONF_VERSION], [2.64])])
-
-dnl Test for the exact version when AC_INIT is expanded.
-dnl This allows to update the tree in steps (for testing)
-dnl by putting
-dnl   m4_define([_GCC_AUTOCONF_VERSION], [X.Y])
-dnl in configure.ac before AC_INIT,
-dnl without rewriting this file.
-dnl Or for updating the whole tree at once with the definition above.
-AC_DEFUN([_GCC_AUTOCONF_VERSION_CHECK],
-[m4_if(m4_defn([_GCC_AUTOCONF_VERSION]),
-  m4_defn([m4_PACKAGE_VERSION]), [],
-  [m4_fatal([Please use exactly Autoconf ]_GCC_AUTOCONF_VERSION[ instead of ]m4_defn([m4_PACKAGE_VERSION])[.])])
-])
-m4_define([AC_INIT], m4_defn([AC_INIT])[
-_GCC_AUTOCONF_VERSION_CHECK
-])
-
-
 dnl Ensure we do not use a buggy M4.
 m4_if(m4_index([..wi.d.], [.d.]), [-1],
   [m4_fatal(m4_do([m4 with buggy strstr detected.  Please install

[-- Attachment #3: newlib-de-cygnussify-remaining-patch.diff --]
[-- Type: text/plain, Size: 1382 bytes --]

diff --git a/newlib/acinclude.m4 b/newlib/acinclude.m4
index 10671f8..ced86dc 100644
--- a/newlib/acinclude.m4
+++ b/newlib/acinclude.m4
@@ -110,7 +110,7 @@ AC_SUBST(newlib_basedir)
 
 AC_CANONICAL_HOST
 
-AM_INIT_AUTOMAKE([cygnus no-define 1.9.5])
+AM_INIT_AUTOMAKE([foreign no-installinfo no-dist no-define])
 
 # FIXME: We temporarily define our own version of AC_PROG_CC.  This is
 # copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS.  We
@@ -187,6 +187,7 @@ ac_given_INSTALL=$INSTALL
 
 AM_MAINTAINER_MODE
 LIB_AM_PROG_AS
+AM_PROG_AS
 
 # We need AC_EXEEXT to keep automake happy in cygnus mode.  However,
 # at least currently, we never actually build a program, so we never
diff --git a/newlib/configure.in b/newlib/configure.in
index 01c6367..e16271a 100644
--- a/newlib/configure.in
+++ b/newlib/configure.in
@@ -1,7 +1,7 @@
 dnl This is the newlib configure.in file.
 dnl Process this file with autoconf to produce a configure script.
 
-AC_PREREQ(2.59)
+AC_PREREQ([2.69])
 AC_INIT([newlib],[NEWLIB_VERSION])
 AC_CONFIG_SRCDIR([libc])
 AC_CONFIG_HEADERS([_newlib_version.h:_newlib_version.hin newlib.h:newlib.hin])
@@ -227,8 +227,7 @@ _LT_DECL_SED
 _LT_PROG_ECHO_BACKSLASH
 AC_PROG_AWK
 if test "${use_libtool}" = "yes"; then
-AC_LIBTOOL_WIN32_DLL
-AM_PROG_LIBTOOL
+LT_INIT([win32-dll])
 fi
 
 dnl The following is being disabled because the mathfp library is

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

Hi Hans-Bernhard,

On Aug 22 23:23, Hans-Bernhard Bröker wrote:
> Am 22.08.2016 um 11:29 schrieb Corinna Vinschen:
> > If you're willing to provide a patch, the patch does not have to contain
> > the generated files.  I would create them locally and push the result.
> 
> Well, OK, so here goes. The core of the modification is best expressed as a
> pseudo shell script (don't run this without double-checking it!)
> 
> cd newlib
> find . -type f -name 'Makefile.am' | \
>   xargs sed -i -e '/AUTOMAKE_OPTIONS.*=/s/cygnus/foreign no-installinfo
> no-dist/'
> cd ..
> 
> and then apply the attached patch
> "newlib-de-cygnussify-remaining-patch.diff" for the finer details, fix
> auto-tools to latest versions, then autoupdate, autoreconf.

Sounds simple enough.  I'll try this in the next couple of days.

> > > main::scan_file() called too early to check prototype at
> > > /usr/bin/aclocal-1.11 line 644.
> > 
> > Yeah, I was already wondering about this.  Patches *extremely* gratefully
> > accepted.
> 
> All I can see off-hand is that scan_file() calls itself recursively in that
> line 644, which would tend to explain that message.  aclocal-1.12 gets rid
> of that by adding prototype declarations (lines 156 ff.). Back-porting most
> of those prototypes into 1.11.6 appears to get rid of this warning without
> too much pain.
> 
> A real Perl programmer should look over this, though.

I don't think we have to do that if we're going to use a newer aclocal
in future anyway, isn't it?

> Well, FWIW, the attached lift-autconf-version-restriction.diff bluntly
> removes that restriction.  I won't guarante the absence of any adverse
> effect, thoughe ;-)

Heh :)   I'll test this on Cygwin.  This should basically cover the
most complex setup, so I don't think other targets will have much of a
problem.

> And just in case: yes, all these patches are free for unrestricted used by
> the public.

Thanks :)


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]

On Aug 23 14:34, Corinna Vinschen wrote:
> Hi Hans-Bernhard,
> 
> On Aug 22 23:23, Hans-Bernhard Bröker wrote:
> > Am 22.08.2016 um 11:29 schrieb Corinna Vinschen:
> > > If you're willing to provide a patch, the patch does not have to contain
> > > the generated files.  I would create them locally and push the result.
> > 
> > Well, OK, so here goes. The core of the modification is best expressed as a
> > pseudo shell script (don't run this without double-checking it!)
> > 
> > cd newlib
> > find . -type f -name 'Makefile.am' | \
> >   xargs sed -i -e '/AUTOMAKE_OPTIONS.*=/s/cygnus/foreign no-installinfo
> > no-dist/'
> > cd ..
> > 
> > and then apply the attached patch
> > "newlib-de-cygnussify-remaining-patch.diff" for the finer details, fix
> > auto-tools to latest versions, then autoupdate, autoreconf.
> 
> Sounds simple enough.  I'll try this in the next couple of days.

No joy.  I tried a lot of stuff.  Basically I'm now down to

 $ find . -type f -name 'Makefile.am' | xargs sed -i -e '/AUTOMAKE_OPTIONS.*=/s/cygnus/foreign no-installinfo no-dist/'
 $ git apply newlib-de-cygnussify-remaining-patch.diff
 $ find newlib -name configure.in -execdir git mv configure.in configure.ac \;
 $ find newlib -name Makefile.am | xargs sed -i -e 's/\<INCLUDES\>/AM_CPPFLAGS/g'
 $ cd newlib
 $ aclocal -I. -I..

No autoupdate in the top-level, it has to stay as is.

No autoupdate in newlib, it breaks stuff.

 $ autoreconf

This fails.  I have a couple of warnings along the lines of:

 configure.ac:14: warning: _AC_COMPILER_EXEEXT was called before AC_NO_EXECUTABLES
 [...]
 Makefile.am:12: warning: source file 'net/domainname.c' is in a subdirectory,
 Makefile.am:12: but option 'subdir-objects' is disabled
 automake: warning: possible forward-incompatibility.
 automake: At least a source file is in a subdirectory, but the 'subdir-objects'
 automake: automake option hasn't been enabled.  For now, the corresponding output
 automake: object file(s) will be placed in the top-level directory.  However,
 automake: this behaviour will change in future Automake versions: they will
 automake: unconditionally cause object files to be placed in the same subdirectory
 automake: of the corresponding sources.
 automake: You are advised to start using 'subdir-objects' option throughout your
 automake: project, to avoid future incompatibilities.
 [...]

and eventually

 Makefile.am:225: warning: suffix '.texinfo' for Texinfo files is discouraged; use '.texi' instead
 Makefile.am:225: installing '../../texinfo.tex'
 [...]
 
Which just did it for me.  I chickened out for now :}


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On 08/22/2016 04:23 PM, Hans-Bernhard Bröker wrote:

>>> That did not work for me. config/override.m4 insisted rather strictly
>>> that
>>> only 2.64 is allowed to be used.  I shredded lines 30ff. from that
>>> file to
>>> get past that one.
>>
>> Same here.  Neither Jeff nor I are autotools experts, so we would be
>> mightly happy if we could get patches to pull the repo to a newer
>> autotools state.
>>
> 
> Well, FWIW, the attached lift-autconf-version-restriction.diff bluntly
> removes that restriction.  I won't guarante the absence of any adverse
> effect, thoughe ;-)
> 

The strongest argument for insisting on an EXACT version is that you
want the generated code checked into git, and for that code to not
undergo a lot of churn if anyone regenerates it under a different
autotool version.  Once you have generated files checked in, then
developers that don't have the right autotools can get by with the
checked in output from the tools.

As long as we rely on --cygnus, we rely on an exact version being
checked in.  But if our goal is to get rid of --cygnus, it makes more
sense to DROP the generated files from git, and to merely require that
developers have new-enough tools installed locally, and bootstrap things
themselves on a git checkout with 'autoreconf -v'.  That is, if we don't
care what version of autotools are used, then we DON'T want the
generated code checked in, as everyone using a different autotools
version will then be stuck with needless local differences.

So I would favor a move towards dropping the generated files altogether
from git (they would still be present in tarballs created by 'make
dist', of course), and just requiring developers to instead have an
up-to-date autotools installation, rather than relying on generated files.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Aug 24 10:21, Eric Blake wrote:
> So I would favor a move towards dropping the generated files altogether
> from git (they would still be present in tarballs created by 'make
> dist', of course), and just requiring developers to instead have an
> up-to-date autotools installation, rather than relying on generated files.

As long as the gcc and binutils-gdb repos provide generated files, we
should do the same.  Changing that would require an RFC on all affected
mailing lists.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Hans-Bernhard Bröker]

Am 24.08.2016 um 17:21 schrieb Eric Blake:
> On 08/22/2016 04:23 PM, Hans-Bernhard Bröker wrote:

>> Well, FWIW, the attached lift-autconf-version-restriction.diff bluntly
>> removes that restriction.  I won't guarante the absence of any adverse
>> effect, thoughe ;-)

> The strongest argument for insisting on an EXACT version is that you
> want the generated code checked into git, and for that code to not
> undergo a lot of churn if anyone regenerates it under a different
> autotool version.  Once you have generated files checked in, then
> developers that don't have the right autotools can get by with the
> checked in output from the tools.

Fair enough.  I took the liberty of counting things in current newlib git:

       2 # Generated by GNU Autoconf 2.66.
       2 configured by $0, generated by GNU Autoconf 2.66,
       3 # Generated by GNU Autoconf 2.69.
       4 # Generated by GNU Autoconf 2.64.
       4 configured by $0, generated by GNU Autoconf 2.64,
       4 generated by GNU Autoconf 2.66.  Invocation command line was
       7 # Generated by GNU Autoconf 2.68.
       8 generated by GNU Autoconf 2.64.  Invocation command line was
      10 configured by $0, generated by GNU Autoconf 2.69,
      20 generated by GNU Autoconf 2.69.  Invocation command line was
     102 # Generated by GNU Autoconf 2.68 for newlib 2.4.0.
     102 [m4_warning([this file was generated for autoconf 2.68.
     102 m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],,
     112 configured by $0, generated by GNU Autoconf 2.68,
     224 generated by GNU Autoconf 2.68.  Invocation command line was

How come that the vast majority of the autoconf-generated files 
currently show a version 2.68, instead of the one the restriction wants 
to enforce:

       1   [m4_define([_GCC_AUTOCONF_VERSION], [2.64])])

;-P

> As long as we rely on --cygnus, we rely on an exact version being
> checked in.  But if our goal is to get rid of --cygnus, it makes more
> sense to DROP the generated files from git, and to merely require that
> developers have new-enough tools installed locally,

Putting generated files into version control only really makes sense if 
the tools needed to generate them cannot really be expected to be 
present in every would-be user's tool box.

And frankly it would be very strange indeed for anyone to have a version 
of autoconf old enough to disqualify.  The version the restriction 
currently wants (but fails) to enforce is 2.64, from 7 years ago, and 
there hasn't been a new release since 2.69, 4 years ago.

> So I would favor a move towards dropping the generated files altogether
> from git (they would still be present in tarballs created by 'make
> dist', of course),

I would agree, but then again, I'm a newbie to this source tree.

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Hans-Bernhard Bröker]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

Hello Corinna,

Am 24.08.2016 um 16:38 schrieb Corinna Vinschen:
> On Aug 23 14:34, Corinna Vinschen wrote:

> No joy.  I tried a lot of stuff.  Basically I'm now down to

I continued trying and yes, there's a lot of details to get
right before this works.  Which is why this took so many days.

> No autoupdate in the top-level, it has to stay as is.
>
> No autoupdate in newlib, it breaks stuff.

I'll put it this way: some of that stuff really needs to be broken, then
put back together in a new, better way.

> $ autoreconf
>
> This fails.  I have a couple of warnings along the lines of:
>
> configure.ac:14: warning: _AC_COMPILER_EXEEXT was called before
> AC_NO_EXECUTABLES [...]
I managed to solve that by updating and reordering some things.

> Makefile.am:12: warning: source file 'net/domainname.c' is in a
> subdirectory, Makefile.am:12: but option 'subdir-objects' is
> disabled

I've been burned by that 'subdir-objects' thingy before, so decided to
fix these by giving that 'net' subdirectory its own Makefile.am and
SUBDIR it.

I eventually managed to beat all the warnings from autoreconf except the
one about automake-1.15 itself that is issued by perl.  For that I
decided to edit my local copy of /usr/bin/automake-1.15 directly :-)

Some minor points remain open:

* newlib/doc/Makefile.am builds a program to run on the build machine, 
so uses $(CC_FOR_BUILD) --- but that failed here because $(CC_FOR_BUILD) 
ended up being the same as $(CC), i.e. it tried to build makedoc.exe 
using the new libraries under construction.  It might have been 
necessary to configure the build as a cross from cygwin to cygwin ...  I 
just built it with CC_FOR_BUILD=gcc instead.

* AM_V_GEN/AM_V_at could be applied more widely to yield a less wordy 
compile log.  I only did some points where it seems useful.

* I'm less than clear about what to do with the libtool support files. 
autoreconf really wants there to be a 'newlib/m4' directory or similar 
for them to be in, but for now, they're in newlib itself.

* I don't recall if the setup was usable for a parallel make before, but 
now there are definitely some problems with it.  In particular, the libm 
manpage extractor rule will need to be fixed.

The only way a 'git format-patch' becomes reasonably small was with the
--irreversible-delete option, so I've attached that. If anyone needs the 
whole whopping 29 MiB of it, I can send it off-list.

Have fun,

Hans-Bernhard Bröker


[-- Attachment #2: 0001-Transport-newlib-auto-foo-to-current-versions-removi.patch.gz --]
[-- Type: application/x-gzip, Size: 34461 bytes --]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On Sun, 4 Sep 2016, Hans-Bernhard Bröker wrote:

> * I'm less than clear about what to do with the libtool support files.
> autoreconf really wants there to be a 'newlib/m4' directory or similar for
> them to be in, but for now, they're in newlib itself.

Certainly for GCC, quite possibly for newlib, updating libtool is said to 
require libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c to be 
reverted from the version of libtool code used (see 
<https://gcc.gnu.org/ml/gcc-patches/2011-01/msg00520.html>).  That 
dependence on a modified libtool version renders it particularly unsuited 
to using any version of libtool someone has installed (which won't have 
that change) rather than checked-in libtool files.

(My view is we should keep the generated files checked in but be stricter 
about enforcing that a particular, current, version of the tools is used 
to generate them, and about making it clear how to do a global 
regeneration.  It's possible that the version in subdirectories owned by 
newlib-cygwin might be newer than the versions used for binutils-gdb and 
GCC, if updating the versions for those projects is harder.)

-- 
Joseph S. Myers
joseph@codesourcery.com