nls patches - need help with make machinery

nls patches - need help with make machinery

[Philipp Thomas]

I'm just now running a bootstrap for testing my patches. Robert, Richard,
would you be willing to test the patches before I check them in?

The only thing I didn't fix is to make chill link to libintl.a if needed. I
just don't understand enough of the gcc make machinery to find a way to
accomplish this. So any help from someone with more knowledge in this area
would be greatly appreciated.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Gerald Pfeifer]

On Sat, 3 Jun 2000, Philipp Thomas wrote:
> I'm just now running a bootstrap for testing my patches. Robert, Richard,
> would you be willing to test the patches before I check them in?

I hope these patches fix the following problem(s) as well? In addition, I
suggest to address those tons of warnings in that code; right now, it's
even hard to find the errors.

Currently both Linux and FreeBSD are broken on ia32. :-(

---- Seen on i486-suse-linux (SuSE 6.4), bootstrapping with GCC 2.95.2
In file included from /cvs/gcc/gcc/intl/localealias.c:73:
/cvs/gcc/gcc/intl/gettextP.h:49: warning: ANSI does not permit the keyword `inline'
/cvs/gcc/gcc/intl/localealias.c: In function `_nl_expand_alias':
/cvs/gcc/gcc/intl/localealias.c:172: warning: implicit declaration of function `bsearch'
/cvs/gcc/gcc/intl/localealias.c: In function `read_alias_file':
/cvs/gcc/gcc/intl/localealias.c:258: warning: pointer targets in passing arg 1 of `fgets' differ in signedness
/cvs/gcc/gcc/intl/localealias.c:264: warning: pointer targets in passing arg 1 of `index' differ in signedness
/cvs/gcc/gcc/intl/localealias.c:317: warning: pointer targets in passing arg 1 of `strlen' differ in signedness
/cvs/gcc/gcc/intl/localealias.c:318: warning: pointer targets in passing arg 1 of `strlen' differ in signedness
/cvs/gcc/gcc/intl/localealias.c:326: warning: implicit declaration of function `realloc'
/cvs/gcc/gcc/intl/localealias.c:337: void value not ignored as it ought to be
/cvs/gcc/gcc/intl/localealias.c:341: void value not ignored as it ought to be
/cvs/gcc/gcc/intl/localealias.c:355: warning: implicit declaration of function `qsort'
/cvs/gcc/gcc/intl/localealias.c: In function `extend_alias_table':
/cvs/gcc/gcc/intl/localealias.c:370: warning: function `realloc' was previously declared within a block
make[4]: *** [localealias.o] Error 1
make[4]: Leaving directory `/tmp/OBJ-0406-00:50/gcc/intl' (cd po && make --jobs=1 all)
make[4]: Entering directory `/tmp/OBJ-0406-00:50/gcc/po'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/tmp/OBJ-0406-00:50/gcc/po'
make[3]: Leaving directory `/tmp/OBJ-0406-00:50/gcc'
rm -f obstack.c
ln -s /cvs/gcc/gcc/../libiberty/obstack.c obstack.c
gcc -c  -DIN_GCC    -g  -W -Wall -Wtraditional -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-DHAVE_CONFIG_H    -I. -I/cvs/gcc/gcc -I/cvs/gcc/gcc/config
-I/cvs/gcc/gcc/../include obstack.c
gcc  -DIN_GCC    -g  -W -Wall -Wtraditional -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-DHAVE_CONFIG_H  -o cpp cppmain.o \
intl.o libcpp.a obstack.o   ./intl/libintl.a     ../libiberty/libiberty.a
gcc: ./intl/libintl.a: No such file or directory
make[2]: *** [cpp] Error 1
make[2]: Leaving directory `/tmp/OBJ-0406-00:50/gcc'

---- Seen on FreeBSD 3.4
In file included from /sw/test/gcc/gcc/gcc/intl/bindtextdom.c:47:
/sw/test/gcc/gcc/gcc/intl/gettextP.h:49: warning: ANSI does not permit the keyword `inline'
/sw/test/gcc/gcc/gcc/intl/bindtextdom.c: In function `bindtextdomain__':
/sw/test/gcc/gcc/gcc/intl/bindtextdom.c:121: warning: implicit declaration of function `malloc'
/sw/test/gcc/gcc/gcc/intl/bindtextdom.c:142: warning: function `malloc' was previously declared within a block
gcc -c -DLOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DGNULOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DLOCALE_ALIAS_PATH=\"/sw/test/gcc/FreeBSD/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I/sw/test/gcc/gcc/gcc/intl -I/sw/test/gcc/gcc/gcc/lib  -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  /sw/test/gcc/gcc/gcc/intl/dcgettext.c
/sw/test/gcc/gcc/gcc/intl/dcgettext.c:52: warning: function declaration isn't a prototype
/sw/test/gcc/gcc/gcc/intl/dcgettext.c:56: warning: function declaration isn't a prototype
In file included from /sw/test/gcc/gcc/gcc/intl/dcgettext.c:79:
/sw/test/gcc/gcc/gcc/intl/gettextP.h:49: warning: ANSI does not permit the keyword `inline'
In file included from /sw/test/gcc/gcc/gcc/intl/dcgettext.c:85:
/sw/test/gcc/gcc/gcc/intl/hash-string.h:38: warning: ANSI does not permit the keyword `inline'
/sw/test/gcc/gcc/gcc/intl/dcgettext.c:99: warning: function declaration isn't a prototype
/sw/test/gcc/gcc/gcc/intl/dcgettext.c: In function `guess_category_value':
/sw/test/gcc/gcc/gcc/intl/dcgettext.c:545: warning: unused parameter `category'
gcc -c -DLOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DGNULOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DLOCALE_ALIAS_PATH=\"/sw/test/gcc/FreeBSD/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I/sw/test/gcc/gcc/gcc/intl -I/sw/test/gcc/gcc/gcc/lib  -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  /sw/test/gcc/gcc/gcc/intl/dgettext.c
gcc -c -DLOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DGNULOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DLOCALE_ALIAS_PATH=\"/sw/test/gcc/FreeBSD/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I/sw/test/gcc/gcc/gcc/intl -I/sw/test/gcc/gcc/gcc/lib  -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  /sw/test/gcc/gcc/gcc/intl/gettext.c
gcc -c -DLOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DGNULOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DLOCALE_ALIAS_PATH=\"/sw/test/gcc/FreeBSD/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I/sw/test/gcc/gcc/gcc/intl -I/sw/test/gcc/gcc/gcc/lib  -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  /sw/test/gcc/gcc/gcc/intl/finddomain.c
/sw/test/gcc/gcc/gcc/intl/finddomain.c:34: warning: function declaration isn't a prototype
In file included from /sw/test/gcc/gcc/gcc/intl/finddomain.c:57:
/sw/test/gcc/gcc/gcc/intl/gettextP.h:49: warning: ANSI does not permit the keyword `inline'
/sw/test/gcc/gcc/gcc/intl/finddomain.c: In function `_nl_find_domain':
/sw/test/gcc/gcc/gcc/intl/finddomain.c:152: warning: implicit declaration of function `malloc'
gcc -c -DLOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DGNULOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DLOCALE_ALIAS_PATH=\"/sw/test/gcc/FreeBSD/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I/sw/test/gcc/gcc/gcc/intl -I/sw/test/gcc/gcc/gcc/lib  -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  /sw/test/gcc/gcc/gcc/intl/loadmsgcat.c
In file included from /sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:39:
/sw/test/gcc/gcc/gcc/intl/gettextP.h:49: warning: ANSI does not permit the keyword `inline'
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c: In function `_nl_load_domain':
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:98: warning: implicit declaration of function `close'
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:124: warning: implicit declaration of function `malloc'
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:132: warning: implicit declaration of function `read'
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:135: warning: function `close' was previously declared within a block
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:144: warning: function `close' was previously declared within a block
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:149: warning: integer constant is unsigned in ANSI C, signed with -traditional
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:149: warning: integer constant is unsigned in ANSI C, signed with -traditional
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:158: warning: implicit declaration of function `free'
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:163: warning: function `malloc' was previously declared within a block
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:174: warning: integer constant is unsigned in ANSI C, signed with -traditional
/sw/test/gcc/gcc/gcc/intl/loadmsgcat.c:197: warning: function `free' was previously declared within a block
gcc -c -DLOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DGNULOCALEDIR=\"/sw/test/gcc/FreeBSD/share/locale\" -DLOCALE_ALIAS_PATH=\"/sw/test/gcc/FreeBSD/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I/sw/test/gcc/gcc/gcc/intl -I/sw/test/gcc/gcc/gcc/lib  -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  /sw/test/gcc/gcc/gcc/intl/localealias.c
/sw/test/gcc/gcc/gcc/intl/localealias.c:47: warning: function declaration isn't a prototype
/sw/test/gcc/gcc/gcc/intl/localealias.c:51: warning: function declaration isn't a prototype
In file included from /sw/test/gcc/gcc/gcc/intl/localealias.c:73:
/sw/test/gcc/gcc/gcc/intl/gettextP.h:49: warning: ANSI does not permit the keyword `inline'
/sw/test/gcc/gcc/gcc/intl/localealias.c: In function `_nl_expand_alias':
/sw/test/gcc/gcc/gcc/intl/localealias.c:172: warning: implicit declaration of function `bsearch'
/sw/test/gcc/gcc/gcc/intl/localealias.c: In function `read_alias_file':
/sw/test/gcc/gcc/gcc/intl/localealias.c:258: warning: pointer targets in passing arg 1 of `fgets' differ in signedness
/sw/test/gcc/gcc/gcc/intl/localealias.c:264: warning: pointer targets in passing arg 1 of `index' differ in signedness
/sw/test/gcc/gcc/gcc/intl/localealias.c:317: warning: pointer targets in passing arg 1 of `strlen' differ in signedness
/sw/test/gcc/gcc/gcc/intl/localealias.c:318: warning: pointer targets in passing arg 1 of `strlen' differ in signedness
/sw/test/gcc/gcc/gcc/intl/localealias.c:326: warning: implicit declaration of function `realloc'
/sw/test/gcc/gcc/gcc/intl/localealias.c:337: void value not ignored as it ought to be
/sw/test/gcc/gcc/gcc/intl/localealias.c:341: void value not ignored as it ought to be
/sw/test/gcc/gcc/gcc/intl/localealias.c:355: warning: implicit declaration of function `qsort'
/sw/test/gcc/gcc/gcc/intl/localealias.c: In function `extend_alias_table':
/sw/test/gcc/gcc/gcc/intl/localealias.c:370: warning: function `realloc' was previously declared within a block
gmake[4]: *** [localealias.o] Error 1
gmake[4]: Leaving directory `/files/pfeifer/OBJ-0306-23:39/gcc/intl'
(cd po && gmake all)
gmake[4]: Entering directory `/files/pfeifer/OBJ-0306-23:39/gcc/po'
gmake[4]: Nothing to be done for `all'.
gmake[4]: Leaving directory `/files/pfeifer/OBJ-0306-23:39/gcc/po'
gmake[3]: Leaving directory `/files/pfeifer/OBJ-0306-23:39/gcc'
rm -f obstack.c
ln -s /sw/test/gcc/gcc/gcc/../libiberty/obstack.c obstack.c
gcc -c  -DIN_GCC    -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I/sw/test/gcc/gcc/gcc -I/sw/test/gcc/gcc/gcc/config -I/sw/test/gcc/gcc/gcc/../include obstack.c
gcc  -DIN_GCC    -g  -W -Wall -Wtraditional -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cpp cppmain.o \
intl.o libcpp.a obstack.o   ./intl/libintl.a     ../libiberty/libiberty.a
gcc: ./intl/libintl.a: No such file or directory
gmake[2]: *** [cpp] Error 1
gmake[2]: Leaving directory `/files/pfeifer/OBJ-0306-23:39/gcc'


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

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Gerald Pfeifer (pfeifer@dbai.tuwien.ac.at) [20000603 23:46]:

> I hope these patches fix the following problem(s) as well? In addition, I
> suggest to address those tons of warnings in that code; right now, it's
> even hard to find the errors.
> 
> Currently both Linux and FreeBSD are broken on ia32. :-(
> 
> ---- Seen on i486-suse-linux (SuSE 6.4), bootstrapping with GCC 2.95.2

That's really strange, as that's the system I'm using! And I would have
noticed if this had happend.

On SuSE 6.4 it shouldn't even try to build libintl.a, as everything that's needed is in
glibc. That is, unless configured with --with-included-gettext. Gerald,
could you please try to find out why configure choose to build libintl on
your SuSE Linux system?

And yes, the warnings should also vanish as my patches deal with them.

For FreeBSD, I'll have to defer test to folks like you, as I don't have a
machine for testing at hand. Patches will be posted tomorrow.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Martin v. Loewis]

> The only thing I didn't fix is to make chill link to libintl.a if needed. I
> just don't understand enough of the gcc make machinery to find a way to
> accomplish this. So any help from someone with more knowledge in this area
> would be greatly appreciated.

Wouldn't adding @INTLLIBS@ into ch/Makefile.in:LIBS do the job? Or
alternatively, follow the guidance of cp/Makefile.in, and define 

INTLLIBS = @INTLLIBS@

and then add this to all places in ch/Makefile.in where INTLLIBS is
added in the cp Makefile (i.e. LIBS and LIBDEPS).

Regards,
Martin

P.S. What is the rationale for indirecting every configure variable
through a Makefile variable?

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Martin v. Loewis (martin@loewis.home.cs.tu-berlin.de) [20000604 00:07]:

> > The only thing I didn't fix is to make chill link to libintl.a if needed. I
> > just don't understand enough of the gcc make machinery to find a way to
> > accomplish this. So any help from someone with more knowledge in this area
> > would be greatly appreciated.
> 
> Wouldn't adding @INTLLIBS@ into ch/Makefile.in:LIBS do the job? Or
> alternatively, follow the guidance of cp/Makefile.in, and define 
> 
> INTLLIBS = @INTLLIBS@
> 
> and then add this to all places in ch/Makefile.in where INTLLIBS is
> added in the cp Makefile (i.e. LIBS and LIBDEPS).

Yes, that's what I finally figured out too :-) Both ch/Makefile.in and
f/Makefile.in now contain this part of cp/makefile.in:

Top build directory, relative to here.
top_builddir = ..

# Internationalization library.
INTLLIBS = @INTLLIBS@
 
and then add INTLLIBS to LIBS and LIBDEPS. Boostrap is currently running but
it seems like that was indeed the right way.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Martin v. Loewis]

> I hope these patches fix the following problem(s) as well? In addition, I
> suggest to address those tons of warnings in that code; right now, it's
> even hard to find the errors.

I'd like to point out that this code is not really ours, nor is
Philipp the author. Instead, it is part of gettext, which is a GNU
package that is currently unmaintained (at least it appears to me that
way).

So while I agree that these problems need to get fixed, I don't think
that this is the exclusive job of a single contributor. Instead,
anybody annoyed by these problems is certainly encouraged to
contribute patches.

Regards,
Martin

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Martin v. Loewis (martin@loewis.home.cs.tu-berlin.de) [20000604 00:17]:

> I'd like to point out that this code is not really ours, nor is
> Philipp the author. Instead, it is part of gettext, which is a GNU
> package that is currently unmaintained (at least it appears to me that
> way).

Well, officially Ulrich Drepper is the maintainer, but I agree that it
havn't seen any upgrades for quite some time.
 
> So while I agree that these problems need to get fixed, I don't think
> that this is the exclusive job of a single contributor. Instead,
> anybody annoyed by these problems is certainly encouraged to
> contribute patches.

I will post patches for this too. Reason is, that we need our own version of
gettext anyway, at least for the time being. This is, because we need a
gettext with Paul Eggerts patches and now also with your patch for scanning
#defines. And while I'm at it, I did those fixes too.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Gerald Pfeifer]

On Sun, 4 Jun 2000, Philipp Thomas wrote:
> On SuSE 6.4 it shouldn't even try to build libintl.a, as everything
> that's needed is in glibc. That is, unless configured with
> --with-included-gettext. Gerald, could you please try to find out why
> configure choose to build libintl on your SuSE Linux system?

I can reproduce it with...

  mkdir OBJ ; cd OBJ
  /cvs/gcc/configure
  nohup gmake bootstrap &

...but I'll send you the output of configure and further data that might
be useful for you.

> And yes, the warnings should also vanish as my patches deal with them.

Great, thanks!

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

Re: nls patches - need help with make machinery

[Ulrich Drepper]

Philipp Thomas <pthomas@suse.de> writes:

> > I'd like to point out that this code is not really ours, nor is
> > Philipp the author. Instead, it is part of gettext, which is a GNU
> > package that is currently unmaintained (at least it appears to me that
> > way).

It's not unmaintained.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Philipp Thomas (pthomas@suse.de) [20000604 00:15]:

> Yes, that's what I finally figured out too :-) Both ch/Makefile.in and
> f/Makefile.in now contain this part of cp/makefile.in:

Spoke too soon :( Chill doesn't use autoconf, so I'll have to come up with a
different fix. My first idea was to make ch/Make-lang.in pass 
"INTLLIBS=../$(INTLLIBS)" in CHILL_FLAGS_TO_PASS, but that would make
INTLLIBS be defined as '../' when libintl isn't necessary.

Martin, do you have an idea how to get Chills Makefile.in be processed by
configure? In that case I could use the same fix as for f/Makefile.in.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Gerald Pfeifer (pfeifer@dbai.tuwien.ac.at) [20000604 00:37]:

> ...but I'll send you the output of configure and further data that might
> be useful for you.

Yes, please do that. And please include gcc/config.log, as that might give
me a clue as to which test failed.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Robert Lipe]

Gerald Pfeifer wrote:

> I hope these patches fix the following problem(s) as well? In addition, I
> suggest to address those tons of warnings in that code; right now, it's
> even hard to find the errors.

I hate to be a grouch, but I'll take this opportunity to point out
that if we had a "don't introduce new warnings into the build" rule,
I believe none of the non-standard GCC extensions that broke builds
on other systems would have made it in.  We would have still had the
bootstrapping problems with missing libraries becuase the "you must
bootstrap while testing your changes" rule wasn't followed.

> In file included from /cvs/gcc/gcc/intl/localealias.c:73:
> /cvs/gcc/gcc/intl/gettextP.h:49: warning: ANSI does not permit the keyword `inline'

This squarely sinks most ISO C compilers.

> /cvs/gcc/gcc/intl/localealias.c:337: void value not ignored as it ought to be
> /cvs/gcc/gcc/intl/localealias.c:341: void value not ignored as it ought to be

These were the tipoff to the "I'm going to treat bcopy as memcpy" problem.

Philipp Thomas wrote:

> Could you supply me with a login to a machine that's not using glibc? I only
> have gcc/glibc machines available to me, so I can't do the verification.

Though I've tried to get a couple of SCO systems outside the firewall to
be available for things like this, I have been unsuccessful in doing it.
I do see that SourceForge has FreeBSD 3.4 in their compilefarm.   I believe
it doesn't use Glibc.

	http://sourceforge.net/compilefarm/

In a different message, Philipp Thomas wrote:
> I'm just now running a bootstrap for testing my patches. Robert, Richard,
> would you be willing to test the patches before I check them in?

Yes.

RJL

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Robert Lipe (robertl@sco.com) [20000604 04:36]:

> > /cvs/gcc/gcc/intl/localealias.c:337: void value not ignored as it ought to be
> > /cvs/gcc/gcc/intl/localealias.c:341: void value not ignored as it ought to be

Yes, I know and have a patch for this.
 
> These were the tipoff to the "I'm going to treat bcopy as memcpy" problem.


> 	http://sourceforge.net/compilefarm/

Of cause! Why didn't I think of sourceforge before? Thanks for reminding me.
 
> Robert, Richard, would you be willing to test the patches before I check
> them in?
 
> Yes.

OK, I'll send you the patches as soon as I've found a solution for Chill.
I'm still figuring out how I can get Chill's Makefile.in be processed by
configure, as that is one of the last problems on my list. The other is,
that the NLS configury doesn't seem to work as it should, as Geralds
problems with SuSE 6.4 showed (gettext tools not installed but support in
glibc. Instead of just disabling the catalog compilation, libintl is being
built).

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Mark Mitchell]

Philip --

  If you have patches for *some* of the problems, please test them and
check them in.  Let's not wait until *all* the problems are fixed.

  Thanks,

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

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Mark Mitchell (mark@codesourcery.com) [20000604 08:47]:

>   If you have patches for *some* of the problems, please test them and
> check them in.

OK, will do! But I'll do that them when I'm up again. Sad as it is on such a
seemingly beautifull summer day, I'll now go to bed as I've been up all
night testing my patches and trying to find a solution for the Chill
problems.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Martin v. Loewis]

> Martin, do you have an idea how to get Chills Makefile.in be processed by
> configure? In that case I could use the same fix as for f/Makefile.in.

Again, without trying: Adding

outputs=ch/Makefile

to ch/config-lang.in might work. If you do this for both ch and objc,
then there would be no 'oldstyle_subdirs' left, which may or may not
be a good thing.

I'm not exactly sure what one has to do to become a 'newstyle' subdir,
configure.in only cares about outputs being set. configure.lang does
all kinds of magic which I don't understand to create ch/Makefile from
Makefile.in. Converting ch to newstyle subdirs does not look to
difficult - it may be that objc is more work.

Alternatively, you could enhance configure.lang to substitute some
other things as well, but I doubt its worth the effort.

Regards,
Martin

Re: nls patches - need help with make machinery

[Richard Earnshaw]

> > Martin, do you have an idea how to get Chills Makefile.in be processed by
> > configure? In that case I could use the same fix as for f/Makefile.in.
> 
> Again, without trying: Adding
> 
> outputs=ch/Makefile
> 
> to ch/config-lang.in might work. If you do this for both ch and objc,
> then there would be no 'oldstyle_subdirs' left, which may or may not
> be a good thing.

This won't work.  I tried it yesterday.  If you want to bring chill's 
makefile fragment into autoconfigury, you will have to rewrite large 
chunks of it, which are currently set up using some special sed rules 
somewhere.  (I got so lost trying to unravel it all yesterday that this is 
when I just gave up and disabled nls entirely.)

> 
> I'm not exactly sure what one has to do to become a 'newstyle' subdir,
> configure.in only cares about outputs being set. configure.lang does
> all kinds of magic which I don't understand to create ch/Makefile from
> Makefile.in. Converting ch to newstyle subdirs does not look to
> difficult - it may be that objc is more work.
> 
> Alternatively, you could enhance configure.lang to substitute some
> other things as well, but I doubt its worth the effort.
> 
> Regards,
> Martin

I think chill needs bringing properly into the autoconf make system.  That 
would solve a lot of the problems, but it probably isn't a trivial job.

R.

Re: nls patches - need help with make machinery

[Zack Weinberg]

On Sat, Jun 03, 2000 at 09:38:48PM -0500, Robert Lipe wrote:
> Gerald Pfeifer wrote:
> 
> > I hope these patches fix the following problem(s) as well? In addition, I
> > suggest to address those tons of warnings in that code; right now, it's
> > even hard to find the errors.
> 
> I hate to be a grouch, but I'll take this opportunity to point out
> that if we had a "don't introduce new warnings into the build" rule,
> I believe none of the non-standard GCC extensions that broke builds
> on other systems would have made it in.  We would have still had the
> bootstrapping problems with missing libraries becuase the "you must
> bootstrap while testing your changes" rule wasn't followed.

Unfortunately, the code in libintl isn't compiled at all on systems that
use GNU libc, because configure finds the routines in libc and skips them
over.  So this would not have helped.

I wonder if it would be a good idea to move libintl to the top level
of the tree, alongside libiberty.  This would avoid the problems with
gcc's um, idiosyncratic configure layout.  It could also avoid the
problems with chill's old-style Makefile (though I think we should work
towards eliminating that).  Has anyone done i18n for gdb or binutils?

zw

Re: nls patches - need help with make machinery

[Robert Lipe]

Zack Weinberg wrote:

> Unfortunately, the code in libintl isn't compiled at all on systems that
> use GNU libc, because configure finds the routines in libc and skips them
> over.  So this would not have helped.

Good point.  It could presumably be forced to be built on such systems
for the maintainers of it, though, right?

> I wonder if it would be a good idea to move libintl to the top level
> of the tree, alongside libiberty.  This would avoid the problems with

Should this copy of libintl generally be updated to use existing
portability machinery in GCC?  There is a lot of stuff that the rest of
GCC knows how to get right that is reimplemented (or worse, missed) in
libintl.    Elsewhere in GCC we've eliminted code like this:

#ifdef __GNUC__
# define alloca __builtin_alloca
# define HAVE_ALLOCA 1
#else
# if defined HAVE_ALLOCA_H || defined _LIBC
#  include <alloca.h>
# else
#  ifdef _AIX
 #pragma alloca
#  else
#   ifndef alloca
char *alloca ();
#   endif
#  endif
# endif
#endif

#include <errno.h>
#ifndef errno
extern int errno;
#endif

Should we do the same for this version of libintl?

I can help with the process if we decide to do so.

RJL

Re: nls patches - need help with make machinery

[Zack Weinberg]

On Sun, Jun 04, 2000 at 01:22:42PM -0500, Robert Lipe wrote:
> Zack Weinberg wrote:
> 
> > Unfortunately, the code in libintl isn't compiled at all on systems that
> > use GNU libc, because configure finds the routines in libc and skips them
> > over.  So this would not have helped.
> 
> Good point.  It could presumably be forced to be built on such systems
> for the maintainers of it, though, right?

I believe there's a configure option to do that.

> > I wonder if it would be a good idea to move libintl to the top level
> > of the tree, alongside libiberty.  This would avoid the problems with
> 
> Should this copy of libintl generally be updated to use existing
> portability machinery in GCC?  There is a lot of stuff that the rest of
> GCC knows how to get right that is reimplemented (or worse, missed) in
> libintl.

There is some advantage to keeping libintl in sync with the 'official'
version.  But getting the thing to work properly has to take precedence.

I don't have a strong opinion either way.

zw

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Robert Lipe (robertl@sco.com) [20000605 09:40]:

> Good point.  It could presumably be forced to be built on such systems
> for the maintainers of it, though, right?

No problem, you just configure with --with-included-gettext and then libintl
will be built. That's how found all the problems I've never had before.
 
> Should this copy of libintl generally be updated to use existing
> portability machinery in GCC? 

There's a problem there. libintl comes from the gettext utils (ultimately
from glibc) and the further we diverge, the harder it gets to eventually
sync up again.

> Should we do the same for this version of libintl?
> I can help with the process if we decide to do so.

I'm still undecided. For the sake of getting rid of cruft we don't need I'd
say yes.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Zack Weinberg (zack@wolery.cumb.org) [20000605 10:14]:

> Unfortunately, the code in libintl isn't compiled at all on systems that
> use GNU libc, because configure finds the routines in libc and skips them
> over.  So this would not have helped.

Yep, that's also why I didn't notice the failures. I'm now configuring with
--with-included-gettext which will force the use of the included libintl.

BTW, as Gerald's failure report for SuSE Linux showed, there is another
lurking bug in the code for AM_GNU_GETTEXT. When configure determines
that libc has what is needed, but that the gettext tools are missing, it'll
nevertheless activate the use of libintl. As I've been told by a collegue,
that's a very long standing bug in gettext (approx 2 years). I've tried to
track it down, but the gettext/NLs configury isn't exactly easy to
understand.
 
> I wonder if it would be a good idea to move libintl to the top level
> of the tree, alongside libiberty.

It definitely is. Jeff and I agreed approx. a year ago that in the long run
it should move there.

> It could also avoid the problems with chill's old-style Makefile (though I
> think we should work towards eliminating that).

The patches I'll be checking in in an hour or so will eliminate that
problem, as chill's Makefile.in will now be processed by configure.

> Has anyone done i18n for gdb or binutils?

In terms of partially translating catalogs for binutils, yes, but not with
the configury. Funny thing is, that NLS support is enabled by default, at
least in CVS. But binutils is a different animal, because libbfd and
libopcode both have their own catalogs and then a third catalog for the
programs.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Marc Espie]

In article < m3itvqfkyj.fsf@localhost.localdomain > Mr. Drepper writes:
>Philipp Thomas <pthomas@suse.de> writes:

>> > I'd like to point out that this code is not really ours, nor is
>> > Philipp the author. Instead, it is part of gettext, which is a GNU
>> > package that is currently unmaintained (at least it appears to me that
>> > way).

>It's not unmaintained.

Well, I asked Mr. Drepper privately whether he intended to actually 
maintain, like make a new release that would fix that pesky Makefile.in.in 
that doesn't quite work (builds files in src/ not build/ dir, doesn't heed
DESTDIR), especially judging that the last release was two years back.

Paraphrasing the answer (as I won't quote without permission), he
told me to mind my own business, that he wouldn't let someone tell him
what to do.

I then asked him how he would feel if I took that to a public forum.
He just told me that I would end up in his kill-file.

So, well, I'm probably in his kill-file now.

And I guess that gettext is `maintained', provided you choose the right
definition of `maintained'.

I must say that I did NOT expect such openly hostile behavior. I have
always seen the FSF crowd as a set of open people, even to BSD people
such as myself.

Mr. Drepper may now force me to revise my impression, which is a shame
really...

(Follow-up to /dev/null, this only posted to the gcc mailing-list because
gettext is used as part of gcc, and this little snippet is in violent 
contradiction to what the gcc `charter' says)

Re: nls patches - need help with make machinery

[David O'Brien]

On Sat, Jun 03, 2000 at 03:39:32PM -0700, Ulrich Drepper wrote:
> > > I'd like to point out that this code is not really ours, nor is
> > > Philipp the author. Instead, it is part of gettext, which is a GNU
> > > package that is currently unmaintained (at least it appears to me that
> > > way).
> 
> It's not unmaintained.


Then can you put these fixes in it, so the GCC doesn't have to use a
custom version of every other GNU tool?

    Reason is, that we need our own version of gettext anyway, at least
    for the time being. This is, because we need a gettext with Paul
    Eggerts patches and now also with your patch for scanning #defines.
    And while I'm at it, I did those fixes too.

-- 
-- David    (obrien@NUXI.com)

Re: nls patches - need help with make machinery

[Marc Espie]

In article <8hfo5c$h1c$1@clipper.ens.fr> you write:
>* Robert Lipe (robertl@sco.com) [20000605 09:40]:

>> Good point.  It could presumably be forced to be built on such systems
>> for the maintainers of it, though, right?

>No problem, you just configure with --with-included-gettext and then libintl
>will be built. That's how found all the problems I've never had before.

As far as OpenBSD goes, we just build --disable-nls.
Having a compiler that works is the most important concern.
Especially if the nls has numerous problems to patch.

Niceties such as internationalized strings can be brought in later.
Especially assuming everything else works by then...

(This is the way our ports tree mostly work now for internationalized
applications. We bring a program in. If it works with nls, fine. If
there is trouble, just --disable-nls it.  If somebody has time, reenable
nls and figure out what the problem was.  But having a working application
is the priority)

Re: nls patches - need help with make machinery

[Marc Espie]

In article < 200006032205.AAA07086@loewis.home.cs.tu-berlin.de > you write:

>INTLLIBS = @INTLLIBS@
>
>and then add this to all places in ch/Makefile.in where INTLLIBS is
>added in the cp Makefile (i.e. LIBS and LIBDEPS).

>P.S. What is the rationale for indirecting every configure variable
>through a Makefile variable?

It's a not-well-known, fairly useful trick.
If you enter

make CFLAGS=-O2

then the value you give on make's command line overrides what's in 
the Makefile (granted, this does not work for recursive builds).
(not to be confused with 'CFLAGS=-O2 make', in /bin/sh, which does set
the env variable CFLAGS, which does NOT override whatever is in the Makefile)

If you simply have 
LIBS=-lfoo -lintl -l${DASDWE}
and you want to override -lintl (say, with specialbuild/libintl.a to test
something), you have to override LIBS.
Whereas
make INTLLIBS=specialbuild/libintl.a
is simpler and faster.

The large advantage of not having to edit the Makefile is that of course,
you won't forget to edit it back later.

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Marc Espie (espie@quatramaran.ens.fr) [20000615 03:14]:

> As far as OpenBSD goes, we just build --disable-nls. Having a compiler
> that works is the most important concern. Especially if the nls has
> numerous problems to patch.

Did you try compiling out of the box, i.e. without --disable-nls after I
checked in my patches? AFAIS, these fixed the bugs and at least Robert Lipe
reported success on SCO so I should also work for *BSD.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Philipp Thomas]

* Kaveh R. Ghazi (ghazi@caip.rutgers.edu) [20000605 10:17]:

> directory to the minimum needed to get it working.

I try to, but at the same time I'm also fixing warnings.

> I'd like to avoid forking our own version of gettext.

Well, for the time being we need our own version of the gettext tools anyway
(more specifically xgettext). Absolutely necessary is Paul Eggerts patches
in ABOUT_GCC_NLS and as Martin's patch (make xgettext look inside #defines, 
making it possible to mark help texts in TARGET_SWITCHES for translation)
seems to be working very nicely I'll include it too.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h

Re: nls patches - need help with make machinery

[Kaveh R. Ghazi]

 > From: Philipp Thomas <pthomas@suse.de>
 > 
 > > Robert, Richard, would you be willing to test the patches before I check
 > > them in?
 >  
 > > Yes.
 > 
 > OK, I'll send you the patches as soon as I've found a solution for Chill.

How about posting what you've already got to the public list?  Do this
prior to installation.  There are a lot of autoconf experts lurking,
they may have useful suggestions.  Less cathedral more bazaar. :-)


 > I'm still figuring out how I can get Chill's Makefile.in be processed by
 > configure, as that is one of the last problems on my list. The other is,
 > that the NLS configury doesn't seem to work as it should, as Geralds
 > problems with SuSE 6.4 showed (gettext tools not installed but support in
 > glibc. Instead of just disabling the catalog compilation, libintl is being
 > built).
 > Philipp

IMHO, --with-included-gettext should be the default.  I'd like to
think it would have preempted some of the problems we're seeing now if
we reproduced them on a glibc system.  I'd do this _after_ we get it
working though. :-)

E.g. we do the same for gnu-regex.c WRT fixincl.  We always use the
included regex lib instead of trying to use a platform's one.  Doing
this always gives us a known state and it ensures gcc's included regex
lib stays working because *everyone* immediately sees any breakage.

Last suggestion, please try to keep any changes necessary in the intl
directory to the minimum needed to get it working.  I'd like to avoid
forking our own version of gettext.  That hampers upgrading it in the
future.

		Thanks,
		--Kaveh

PS: I fully support getting intl working.  Thanks for tackling this!

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions