I have been having trouble compiling an older gcc. I get the following when I try to compile either gcc-3.1.1 or gcc-3.1. I have also tried compiling with a gcc-3.1.1 compiler, not the gcc-3.3. I think the problem is not related to the compiler, but maybe something I have installed or don't have installed. I have the following devel related packages installed: glibc-2.3.2-6 glibc-locale-2.3.2-6 glibc-devel-2.3.2-6 libgcc-3.3-23 gcc-3.3-23 gcc-c++-3.3-23 Here is the output from compiling gcc-3.1.1 with gcc-3.3, the errors are at the bottom and thanks for any help: /bin/sh ../libtool --tag CXX --mode=compile /usr/local/src/gcc-3.1.1/gcc/xgcc -s hared-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-li nux-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/lib stdc++-v3/include -I../libsupc++ -I../libmath -g -O2 -D_GNU_SOURCE -fno-impl icit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-sho w-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/us r/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/ -isys tem /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-strin gs -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: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) make[3]: *** [c++locale.lo] Error 1 make[3]: Leaving directory `/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++ -v3/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++ -v3' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/usr/local/src/gcc-3.1.1/i686-pc-linux-gnu/libstdc++ -v3' make: *** [all-target-libstdc++-v3] Error 2
I have been having trouble compiling an older gcc. I get the following when I try to compile either gcc-3.1.1 or gcc-3.1. I have also tried compiling with a gcc-3.1.1 compiler, not the gcc-3.3. I think the problem is not related to the compiler, but maybe something I have installed or don't have installed. I have the following devel related packages installed: My thought is that you are referencing long longs (and the functions
On Fri, 25 Apr 2003 16:53:12 -0400
Jesse Marlin
Jerry Feldman writes:
On Fri, 25 Apr 2003 16:53:12 -0400 Jesse Marlin
wrote: I have been having trouble compiling an older gcc. I get the following when I try to compile either gcc-3.1.1 or gcc-3.1. I have also tried compiling with a gcc-3.1.1 compiler, not the gcc-3.3. I think the problem is not related to the compiler, but maybe something I have installed or don't have installed. I have the following devel related packages installed: My thought is that you are referencing long longs (and the functions that support them, eg. __strtoll_l. These are most likely not supported in a 32 bit environment.
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
On Mon, 28 Apr 2003 09:55:18 -0400
Jesse Marlin
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
Jerry Feldman writes:
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.
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.
On Mon, 28 Apr 2003 12:48:01 -0400
Jesse Marlin
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
Jesse Marlin
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
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 *really* doubt that it's the compiler! From which package is this test_plan_xml_to_rnf.c? If this is some open source package, I might check for myself? Even easier would be if you'd just add -save-temps to the compiler flags and send me the resulting test_plan_xml_to_rnf.i as private mail. That way I wouldn't need any additional files to check what's going wrong. Until proven otherwise, I bet you it's the source that's at fault ;-) Philipp -- Philipp Thomas work: pthomas@suse.de Development, SuSE Linux AG private: philipp.thomas@t-link.de
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
Jesse Marlin
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. 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 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
--
* Jesse Marlin (jlm@compgen.com) [20030429 00:48]:
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.
I'd strongly advise to use at least the just released 3.2.3.
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.
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.
*Please* try what I suggested and you'll probably see the cause.
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 :).
And you still haven't answered the question whether I may see the code that's
causing troubles. Somehow I feel ignored :(
Philipp
--
Philipp Thomas
* 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
On Mon, 28 Apr 2003 15:39:12 -0400
Jesse Marlin
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 The #line lines are generated by the C Preprocessor. Someone earlier had mentioned not to copy the compiler. This indicates to me that there is some incompatibility between the preprocessor pass and the compiler.
Also note that header files routinely have tests for compiler versions
and other features. If you have mixed components, then that could
account for some of your problems.
--
Jerry Feldman
participants (4)
-
Jerry Feldman
-
Jesse Marlin
-
Philipp Thomas
-
Philipp Thomas