On Mon, 28 Apr 2003 09:55:18 -0400 Jesse Marlin wrote:

I hadn't had any trouble compiling gcc-3.1.1 in the past. I think there are some system headers out there causing problems. On a side note I am also getting a lot of these errors just compiling code that used to work with 7.2. A lot of these look like problems with the headers themselves. This is the main reason I was compiling gcc-3.1.1 in the first place.

test_plan_xml_to_rnf.c:14:27: missing terminating " character test_plan_xml_to_rnf.c:17: error: parse error before "Converts" test_plan_xml_to_rnf.c:25:1: missing terminating " character In file included from /usr/include/_G_config.h:44, from /usr/include/libio.h:32, from /usr/include/stdio.h:72, from test_plan_xml_to_rnf.c:48: /usr/include/gconv.h:72: error: parse error before "size_t" /usr/include/gconv.h:88: error: parse error before "size_t" /usr/include/gconv.h:97: error: parse error before "size_t" /usr/include/gconv.h:174: error: parse error before "size_t" /usr/include/gconv.h:174: warning: no semicolon at end of struct or union/usr/include/gconv.h:177: error: parse error before '}' token /usr/include/gconv.h:177: warning: type defaults to `int' in declaration of `__g conv_t' /usr/include/gconv.h:177: warning: data definition has no type or storage class In file included from /usr/include/libio.h:32, from /usr/include/stdio.h:72, from test_plan_xml_to_rnf.c:48: /usr/include/_G_config.h:47: error: field `__cd' has incomplete type /usr/include/_G_config.h:50: error: field `__cd' has incomplete type /usr/include/_G_config.h:53: confused by earlier errors, bailing out

Could possibly be problems with the header files, or possibly problems in your include list. While a well written header file is self referential, not all Linux ones are. I suspect that your problem is in test_plan_xml_to_rnf.c where you might have an unterminated comment or quote, especially if you have some boiler plate at the beginning. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Mon, 28 Apr 2003 12:48:01 -0400 Jesse Marlin wrote:

No the code on the C side looks good. I can compile it fine on other machines, SuSE 7.2, Redhat 7.3, SUN, HP, etc, all with gcc-3.1.1. I found some bug reports about gcc reporting about the wrong files or it may be confused or something.

I just tried to compile the same code above with a gcc-3.1.1 that I copied from my old SuSE 7.2 system and it works. The normal compiler is gcc-3.3 from SuSE 8.2 and it does not work. I think I will just stick with gcc-3.1.1 for now. I would like to recompile gcc-3.1.1 for this system, but if the copy works then I can live with that. I have not installed SuSE 8.2 yet, but I have no problems with gcc-3.2-36.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Philipp Thomas writes:

Jesse Marlin [Mon, 28 Apr 2003 12:48:01 -0400]:

...

...

...

In file included from /usr/include/_G_config.h:44, from /usr/include/libio.h:32, from /usr/include/stdio.h:72, from test_plan_xml_to_rnf.c:48: /usr/include/gconv.h:72: error: parse error before "size_t" /usr/include/gconv.h:88: error: parse error before "size_t" /usr/include/gconv.h:97: error: parse error before "size_t" /usr/include/gconv.h:174: error: parse error before "size_t" I just tried to compile the same code above with a gcc-3.1.1 that I copied from my old SuSE 7.2 system and it works.

The first thing I'd do is put an '#include ' at the top of the includes in test_plan_xml_to_rnf.c. glibc has changed quite a bit since 7.2 and there are a few headers that gcc generates at compile time (/usr/lib/gcc-lib/<target>/<version>/include)

That did seem to help out a lot. It doesn't seem to affect everything that includes stdio.h, but some stuff it does. The manual pages don't reflect any include changes either. Here are some errors from a build I just attempted with gcc-3.1.1. Notice the mixed in gcc-3.3 headers there. From my understanding gcc is supposed to know where to look for its headers. Keep in mind that this compiles fine on every machine we have here except this one with SuSE 8.2 on it. The errors make no sense at all. I've only included a small portion here, this goes on for about a mile :) In file included from CGR.h:31: /usr/include/stdio.h:0: warning: unrecognized text at end of #line /usr/include/stdio.h:27: warning: unrecognized text at end of #line In file included from /usr/include/stdio.h:28, from CGR.h:31: /usr/include/features.h:0: warning: unrecognized text at end of #line /usr/include/features.h:290: warning: unrecognized text at end of #line In file included from /usr/include/features.h:291, from /usr/include/stdio.h:28, from CGR.h:31: /usr/include/sys/cdefs.h:0: warning: unrecognized text at end of #line In file included from /usr/include/stdio.h:28, from CGR.h:31: /usr/include/features.h:291: warning: unrecognized text at end of #line /usr/include/features.h:313: warning: unrecognized text at end of #line In file included from /usr/include/features.h:314, from /usr/include/stdio.h:28, from CGR.h:31: /usr/include/gnu/stubs.h:0: warning: unrecognized text at end of #line In file included from /usr/include/stdio.h:28, from CGR.h:31: /usr/include/features.h:314: warning: unrecognized text at end of #line In file included from CGR.h:31: /usr/include/stdio.h:28: warning: unrecognized text at end of #line In file included from /usr/include/stdio.h:34, from CGR.h:31: /usr/lib/gcc-lib/i486-suse-linux/3.3/include/stddef.h:0: warning: unrecognized text at end of #line /usr/lib/gcc-lib/i486-suse-linux/3.3/include/stddef.h:212: warning: unrecognized text at end of #line In file included from CGR.h:31: /usr/include/stdio.h:34: warning: unrecognized text at end of #line In file included from /usr/include/stdio.h:36, from CGR.h:31: /usr/include/bits/types.h:0: warning: unrecognized text at end of #line /usr/include/bits/types.h:27: warning: unrecognized text at end of #line In file included from /usr/include/bits/types.h:28, from /usr/include/stdio.h:36, from CGR.h:31: /usr/include/bits/wordsize.h:0: warning: unrecognized text at end of #line In file included from /usr/include/stdio.h:36, from CGR.h:31: /usr/include/bits/types.h:28: warning: unrecognized text at end of #line In file included from /usr/include/bits/types.h:31, from /usr/include/stdio.h:36, from CGR.h:31: /usr/lib/gcc-lib/i486-suse-linux/3.3/include/stddef.h:0: warning: unrecognized text at end of #line

Philipp Thomas writes:

Jesse Marlin [Mon, 28 Apr 2003 15:39:12 -0400]:

...

Here are some errors from a build I just attempted with gcc-3.1.1. Notice the mixed in gcc-3.3 headers there.

How did you install the compilers? You can't just copy them over from an older distribution! The way they are configured, they can't be installed in parallel. When compiling gcc, certain paths get hard coded into the compiler driver and language frontends. The only clean way would be to rebuild one of the gcc packages with changed installation paths.

Yeah I just copied it over from an older machine. I suspected that there would be problems with that. I had tried to build the compiler locally from the start, which was the original intent of this thread, but it fails to build with the following: /bin/sh ../libtool --tag CXX --mode=compile /usr/local/src/gcc-3.1.1/gcc/xgcc -shared-libgcc -B/usr/local/src/gcc-3.1.1/gcc/ -nostdinc++ -L/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/src -L/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc-3.1.1/i686-pc-linux-gnu/bin/ -B/usr/local/gcc-3.1.1/i686-pc-linux-gnu/lib/ -isystem /usr/local/gcc-3.1.1/i686-pc-linux-gnu/include -nostdinc++ -I/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/include -I../libsupc++ -I../libmath -g -O2 -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c c++locale.cc /usr/local/src/gcc-3.1.1/gcc/xgcc -shared-libgcc -B/usr/local/src/gcc-3.1.1/gcc/ -nostdinc++ -L/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/src -L/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/gcc-3.1.1/i686-pc-linux-gnu/bin/ -B/usr/local/gcc-3.1.1/i686-pc-linux-gnu/lib/ -isystem /usr/local/gcc-3.1.1/i686-pc-linux-gnu/include -nostdinc++ -I/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++-v3/include -I../libsupc++ -I../libmath -g -O2 -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c c++locale.cc -fPIC -DPIC -o .libs/c++locale.o c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = long int]': c++locale.cc:51: `__strtol_l' undeclared (first use this function) c++locale.cc:51: (Each undeclared identifier is reported only once for each function it appears in.) c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = long unsigned int]': c++locale.cc:69: `__strtoul_l' undeclared (first use this function) c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = long long int]': c++locale.cc:87: `__strtoll_l' undeclared (first use this function) c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = long long unsigned int]': c++locale.cc:106: `__strtoull_l' undeclared (first use this function) c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = float]': c++locale.cc:124: `__strtof_l' undeclared (first use this function) c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = double]': c++locale.cc:141: `__strtod_l' undeclared (first use this function) c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = long double]': c++locale.cc:158: `__strtold_l' undeclared (first use this function) c++locale.cc: In static member function `static void std::locale::facet::_S_create_c_locale(__locale_struct*&, const char*, __locale_struct*)': c++locale.cc:170: `__newlocale' undeclared (first use this function) c++locale.cc: In static member function `static void std::locale::facet::_S_destroy_c_locale(__locale_struct*&)': c++locale.cc:180: `__freelocale' undeclared (first use this function) c++locale.cc: In static member function `static __locale_struct* std::locale::facet::_S_clone_c_locale(__locale_struct*&)': c++locale.cc:184: `__duplocale' undeclared (first use this function)

The best way is to install the 'secondary' compiler to somewhere in /opt. The easiest way for you would be to send me the respective gcc.spec and I'll change it for you.

...

From my understanding gcc is supposed to know where to look for its headers.

Not if you mix them up like it seems you did.

...

Keep in mind that this compiles fine on every machine we have here except this one with SuSE 8.2 on it.

One of the things that changed in glibc 3.1.2 is that headers pull in exactly what they need and nothing more, whereas in the past some headers got pulled in implicitly. So the programmer is *required* to explicitly include all necessary headers. If the man page for a certain library function says that sys/types.h and sys/stat.h are needed, you really have to include both.

...

The errors make no sense at all.

Compile the file with -save-temps and remove all lines starting with #line from the resulting .i file. Now feed that edited .i file to the compiler. If you now look at the places the error messages point to, I'm rather sure you'll see what's wrong.

See where that what's missing is defined and include that header.

...

I've only included a small portion here, this goes on for about a mile :)

I'd really advise to delete all traces of *both* compilers, reinstall the gcc-3.3 from 8.2 and use that as the basis for finding the necessary headers.

Believe me, this is *no* error in the compiler but rather a more standards conforming glibc that leads to failures in code that doesn'T adhere to the rules.

Once again, if this is code you can freely pass on, point me to a tarball and I'll see what I can do (but not today :).

Philipp

-- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de

--

* Philipp Thomas (pthomas@suse.de) [20030429 11:12]:

...

c++locale.cc: In function `void std::__convert_to_v(const char*, _Tv&, std::_Ios_Iostate&, __locale_struct* const&, int) [with _Tv = long int]': c++locale.cc:51: `__strtol_l' undeclared (first use this function) c++locale.cc:51: (Each undeclared identifier is reported only once for each function it appears in.)

I'm compiling a stock 3.1.1 in the background, let's see what happens.

OK, found the reason for this. these __str* functions are internal glibc functions for which the prototypes have been removed in newer versions. gcc 3.2.x contains a workaround for this but then it'll fail later on. Face it, gcc 3.1.1 just can't cope with glibc 2.3.X and nobody is going to invest any effort in fixing it. For glibc 2.3.X you need gcc >= 3.2. This again means that you will have to face the task of fixing the code that gcc 3.2.X complains about. Philipp -- Philipp Thomas SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nuremberg, Germany