using PCH branch to make precompiled std include

Benjamin Kosnik bkoz@redhat.com
Mon Dec 16 15:37:00 GMT 2002


>On my P4 it's:
>0.180u 0.010s 0:00.19 100.0%
>vs
>1.030u 0.010s 0:01.04 100.0%
>
>Pretty good!

Definitely worth trying out, I think! This is really good news.

>/tmp/ccSZfk3p.o: In function `main':
>/tmp/ccSZfk3p.o(.text+0x18): undefined reference to 
>`std::allocator<char>::allocator[in-charge]()'

stl-inst.cc

>/tmp/ccSZfk3p.o(.text+0x32): undefined reference to 
>`std::basic_string<char, std::char_traits<char>, std::allocator<char> 
> >::basic_string[in-charge](char const*, std::allocator<char> const&)'

string-inst.cc

>/tmp/ccSZfk3p.o(.text+0x71): undefined reference to 
>`std::basic_ostream<char, std::char_traits<char> >& std::operator<< 
><char, std::char_traits<char>, std::allocator<char> 

ostream-inst.cc

>collect2: ld returned 1 exit status

These are all things that are explicitly instantiated in source files,
and then "extern template" ified in the include files. Does the
libstdc++ binary in the PCH build directory have these bits? If not,
that's a bug. If you build a PCH, and then use it all the time in a
re-jiggered full testsuite run, do things work, or fall down? Looks like
things might not get very far if this simple program doesn't make it.

Sounds like there might be some linkage issues. I'll get back to this
later in the week, I think, after the config/build bits and
__cxa_demangle bits get finished.

Is there a list of known issues and bugs in the current PCH implementation?

-benjamin



More information about the Libstdc++ mailing list