problems with the recent snapshot (971207)

problems with the recent snapshot (971207)

[Tudor Hulubei]

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

Hi,

My program used to compile/link fine with egcs-1.0.  Now I get a bunch
of errors at link-time.  Attached is the log.  Any suggestion?

Thanks,
Tudor


[-- Attachment #2: t.gz --]
[-- Type: application/x-gzip, Size: 1830 bytes --]

Re: problems with the recent snapshot (971207)

[Paul Henning]

I'm refering to egcs-971207 on linux-2.1.71, glibc-2.0.5c with the
following config:

../egcs-971207/configure --host=i686-pc-linux-gnu --prefix=/usr/local/app/egcs --enable-shared --with-gnu-as --with-gnu-ld --norecursion 
# using "../egcs-971207/config/mh-x86pic" and "../egcs-971207/config/mt-x86pic"


I have the same problem the Tudor is having, which appears to be
similar to the problem Jim Peterson was having
(e.g. http://www.cygnus.com/ml/egcs-bugs/1997-Dec/0106.html ).

Essentially, this program won't link:

===
#include <iostream.h>
#include <string>
int main(void) { string s = "Hello, world"; cout << s << endl; return 0; }
===

Just to be sure that I am not running into old C++ libraries, I moved
all the libstc++* and libg++* files (not egcs) to a junk directory and
re-ran ldconfig.  Just to be really-really sure, I renamed
/usr/include/g++ as well.

When I do a "make bootstrap; make -k check", I run into tons of errors
during the g++ tests because ld.so can't find libstd++.so.2.8.0.
Annoying, but fixable.  Re-running "make -k check", I run into the
following failures during libstdc++ check:

Executing on host: /home/phenning/EGCS/Build/build/gcc/xgcc -B/home/phenning/EGCS/Build/build/gcc/ ../../../../egcs-971207/libstdc++/testsuite/libstdc++.tests/../../tests/tstring.cc  -I.. -I../../../../egcs-971207/libstdc++/testsuite/.. -I../../../../egcs-971207/libstdc++/testsuite/../stl -I.   -I/home/phenning/EGCS/Build/egcs-971207/libio -I/home/phenning/EGCS/Build/build/libraries/libio -g -L/home/phenning/EGCS/Build/build/libraries//libstdc++ -lstdc++   -lm  -o /home/phenning/EGCS/Build/build/libraries/libstdc++/testsuite/tstring   
compiler exited with status 1
output is:
/tmp/cca294841.o:/home/phenning/EGCS/Build/build/libraries/libstdc++/testsuite/../../../../egcs-971207/libstdc++/testsuite/../std/bastring.h:148: undefined reference to `ostream & operator<<<char, string_char_traits<char>, __default_alloc_template<false, 0> >(ostream &, basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &)'
[plus a lot of other similar errors]


so, tstring.cc compilation and tstring.cc -O compilation fail unexpectedly.

What else can I provide to help resolve this?

Cheers,
Paul Henning

Re: problems with the recent snapshot (971207)

[H.J. Lu]

> 
> 
> I'm refering to egcs-971207 on linux-2.1.71, glibc-2.0.5c with the
> following config:
> 
> ../egcs-971207/configure --host=i686-pc-linux-gnu --prefix=/usr/local/app/egcs --enable-shared --with-gnu-as --with-gnu-ld --norecursion 
> # using "../egcs-971207/config/mh-x86pic" and "../egcs-971207/config/mt-x86pic"
> 
> 
> I have the same problem the Tudor is having, which appears to be
> similar to the problem Jim Peterson was having
> (e.g. http://www.cygnus.com/ml/egcs-bugs/1997-Dec/0106.html ).
> 
> Essentially, this program won't link:
> 
> ===
> #include <iostream.h>
> #include <string>
> int main(void) { string s = "Hello, world"; cout << s << endl; return 0; }
> ===
> 
> Just to be sure that I am not running into old C++ libraries, I moved
> all the libstc++* and libg++* files (not egcs) to a junk directory and
> re-ran ldconfig.  Just to be really-really sure, I renamed
> /usr/include/g++ as well.
> 
> When I do a "make bootstrap; make -k check", I run into tons of errors
> during the g++ tests because ld.so can't find libstd++.so.2.8.0.
> Annoying, but fixable.  Re-running "make -k check", I run into the
> following failures during libstdc++ check:
> 
> Executing on host: /home/phenning/EGCS/Build/build/gcc/xgcc -B/home/phenning/EGCS/Build/build/gcc/ ../../../../egcs-971207/libstdc++/testsuite/libstdc++.tests/../../tests/tstring.cc  -I.. -I../../../../egcs-971207/libstdc++/testsuite/.. -I../../../../egcs-971207/libstdc++/testsuite/../stl -I.   -I/home/phenning/EGCS/Build/egcs-971207/libio -I/home/phenning/EGCS/Build/build/libraries/libio -g -L/home/phenning/EGCS/Build/build/libraries//libstdc++ -lstdc++   -lm  -o /home/phenning/EGCS/Build/build/libraries/libstdc++/testsuite/tstring   
> compiler exited with status 1
> output is:
> /tmp/cca294841.o:/home/phenning/EGCS/Build/build/libraries/libstdc++/testsuite/../../../../egcs-971207/libstdc++/testsuite/../std/bastring.h:148: undefined reference to `ostream & operator<<<char, string_char_traits<char>, __default_alloc_template<false, 0> >(ostream &, basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &)'
> [plus a lot of other similar errors]
> 
> 
> so, tstring.cc compilation and tstring.cc -O compilation fail unexpectedly.
> 
> What else can I provide to help resolve this?

Same here on i586-linux-gnu. But it was ok on i586-linux-glibc1.
Since egcs 971207 miscompiles things on x86, it is not that strange.

H.J.

Re: problems with the recent snapshot (971207) (Solved)

[Jody Goldberg]

On Mon, Dec 08, 1997 at 05:05:56PM -0800, H.J. Lu wrote:
> > /tmp/cca294841.o:/home/phenning/EGCS/Build/build/libraries/libstdc++/testsuite/../../../../egcs-971207/libstdc++/testsuite/../std/bastring.h:148: undefined reference to `ostream & operator<<<char, string_char_traits<char>, __default_alloc_template<false, 0> >(ostream &, basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &)'
> > [plus a lot of other similar errors]
> > 
> > so, tstring.cc compilation and tstring.cc -O compilation fail unexpectedly.
> > 
> > What else can I provide to help resolve this?
> 
> Same here on i586-linux-gnu. But it was ok on i586-linux-glibc1.
> Since egcs 971207 miscompiles things on x86, it is not that strange.
> 

The patch I submitted for bastring is the source of these problems.  If
you look at the error messages carefully you'll notice

undefined reference to `ostream & operator<<<char, string_char_traits<char>,
		    __default_alloc_template<false, 0>
		                             ^^^^^
>(ostream &, basic_string<char, string_char_traits<char>,
		    __default_alloc_template<false, 0> > const &)'
		                             ^^^^^
In the library you find
    basic_string<char, string_char_traits<char>,
		__default_alloc_template<true, 0> >
		                         ^^^^^

The issue is the -D_PTHREAD during the compilation of sinst.cc.
This causes the thread safe allocator to be used by default under Linux
glibc2.  However, _PTHREAD is NOT defined when tstring.cc is compiled and
it attempts to use the NON-thread safe allocator which was not instantiated
in libstdc++.

I mentioned this issue with the patch but did not have a solution.

What version(s) should go into the library ?  SGI uses _PTHREAD in the stl
and egcs defines it for linux in libstdc++/config/linux.mt.  How should it be
defined for general programs ?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jodyg@idt.net  | By definition all answers are replies. Unfortunately,
               | not all replies are answers.  -- JMS

Re: problems with the recent snapshot (971207) (Solved)

[H.J. Lu]

> 
> On Mon, Dec 08, 1997 at 05:05:56PM -0800, H.J. Lu wrote:
> > > /tmp/cca294841.o:/home/phenning/EGCS/Build/build/libraries/libstdc++/testsuite/../../../../egcs-971207/libstdc++/testsuite/../std/bastring.h:148: undefined reference to `ostream & operator<<<char, string_char_traits<char>, __default_alloc_template<false, 0> >(ostream &, basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &)'
> > > [plus a lot of other similar errors]
> > > 
> > > so, tstring.cc compilation and tstring.cc -O compilation fail unexpectedly.
> > > 
> > > What else can I provide to help resolve this?
> > 
> > Same here on i586-linux-gnu. But it was ok on i586-linux-glibc1.
> > Since egcs 971207 miscompiles things on x86, it is not that strange.
> > 
> 
> The patch I submitted for bastring is the source of these problems.  If
> you look at the error messages carefully you'll notice
> 
> undefined reference to `ostream & operator<<<char, string_char_traits<char>,
> 		    __default_alloc_template<false, 0>
> 		                             ^^^^^
> >(ostream &, basic_string<char, string_char_traits<char>,
> 		    __default_alloc_template<false, 0> > const &)'
> 		                             ^^^^^
> In the library you find
>     basic_string<char, string_char_traits<char>,
> 		__default_alloc_template<true, 0> >
> 		                         ^^^^^
> 
> The issue is the -D_PTHREAD during the compilation of sinst.cc.
> This causes the thread safe allocator to be used by default under Linux
> glibc2.  However, _PTHREAD is NOT defined when tstring.cc is compiled and
> it attempts to use the NON-thread safe allocator which was not instantiated
> in libstdc++.
> 
> I mentioned this issue with the patch but did not have a solution.
> 
> What version(s) should go into the library ?  SGI uses _PTHREAD in the stl
> and egcs defines it for linux in libstdc++/config/linux.mt.  How should it be
> defined for general programs ?
> 

I don't like to link with -lpthread for my single thread program.
Can we have both in libstdc++, like compiling anything which
includes <alloc.h> twice?

# .... -D_PTHREAD -c -o stlinst.omt stlinst.cc
# .... -c -o stlinst.o stlinst.cc

Will it work?


-- 
H.J. Lu (hjl@gnu.org)

Re: problems with the recent snapshot (971207)

[Orn E. Hansen]

Paul Henning writes:
 > 
 > 
 > Essentially, this program won't link:
 > 
 > ===
 > #include <iostream.h>
 > #include <string>
 > int main(void) { string s = "Hello, world"; cout << s << endl; return 0; }
 > ===
 > 

 As the bastring.cc is supplied in the include directory I compiled it
as a template class...

------
#include <string>

template class basic_string<char>;

#include <std/bastring.cc>
------

and then tried to compile a program I have, with this object for
string, but I got the following additional errors... which appears to
indicate that templates are broken.

Menu.o(.data+0x0): multiple definition of `__default_alloc_template<false, 0>::free_list'
main.o(.data+0x34c): first defined here