Issue 1129 - gcc 3.0 and libstdc++
Summary: gcc 3.0 and libstdc++
Status: CLOSED NOT_AN_OOO_ISSUE
Alias: None
Product: porting
Classification: Code
Component: documentation (show other issues)
Version: 632
Hardware: SGI IRIX
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: sander_traveling
QA Contact: issues@porting
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-06-27 22:22 UTC by issues@www
Modified: 2010-03-29 21:08 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Patchset adding <ext/...> - Breaks gcc 3.0 with other STLs (5.26 KB, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - vos: Patch to #if __GNU_STL__ == 3 include <ext/...> (994 bytes, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - store (989 bytes, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - registry (499 bytes, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - idlc (497 bytes, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - codemaker (5.39 KB, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - inet (1.60 KB, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - xmlscript (1.26 KB, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - sot (752 bytes, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - rdbmaker (3.97 KB, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff
patchset - vcl (1.01 KB, patch)
2003-12-06 14:52 UTC, issues@www
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description issues@www 2001-06-27 22:22:03 UTC
gcc 2.95.2 core dumps when used with -g .  Obviously this presents a roadblock 
for the IRIX port as I have a binary and no way to debug it.  I have some faith 
in gcc 3.0, and it seems to be getting around this problem.  It does present a 
new problem in that it has moved extensions to the STL eg hash_map into 
<ext/hash_map> .

% ls /usr/local/gcc-3.0/include/g++-v3/ext/
hash_map         rope             slist            stl_hashtable.h
hash_set         ropeimpl.h       stl_hash_fun.h   stl_rope.h

Initially I solved this by adding
#if ( __GNUC__ == 3 )
#include <ext/hash_map>
#else
#include <hash_map>
#endif

I did this for cppu where gcc 2.95.2 previously failed to compile the code.  
However this will break usage of gcc 3.0 with other STLs such as STLport, and 
so cant be used.  This could be solved by ensuring we have an additional 
#define available for each STL.  This define would have to be made outside of 
the STL, as one can not rely on an STL header having been previously included 
before the define is used.

The simplest solution atm is to modify the include path, and explicitly add the 
ext/ directory.  I would hope there is a gcc 3.0 switch to provide this ... 
and -std=standard looks promising.
Comment 1 issues@www 2001-06-27 22:25:10 UTC
Created attachment 324 [details]
Patchset adding <ext/...> - Breaks gcc 3.0 with other STLs
Comment 2 sander_traveling 2001-06-28 15:11:08 UTC
Well, you are free to introduce a new define that ever only exists in case of
not using a "real" STL but libstdc++
Comment 3 issues@www 2001-06-29 07:57:29 UTC
Created attachment 326 [details]
patchset - vos: Patch to #if __GNU_STL__ == 3 include <ext/...>
Comment 4 jens-heiner.rechtien 2001-06-29 12:48:30 UTC
John,

you don't really want to change a 1000 or so files for this? :-) Why not simply 
include -I $(prefix)/g++-v3/ext via the Irix unx????.mk? Or I'm missing 
something here?

Heiner
Comment 5 issues@www 2001-07-01 23:05:52 UTC
Actually for <hash_(map|set)> its only 117 :)  But ... no I dont want to ... 
however I found that by including -I/path/to/ext I end up with internal STL 
include errors, as stl headers within <ext/*> also include <ext/stl_internal> 
which then cant be found.

However I did get this reply on gnu.g++.help, which I will look into.

"It's an extension and as such not part of the S(tandard)TL, but you'd modify
the specs file of gcc-3.0 or set GPLUSPLUS_INCLUDE_DIR to force g++ to
look for includes in /.../ext, too."
Comment 6 issues@www 2001-07-03 04:02:53 UTC
Created attachment 333 [details]
patchset - store
Comment 7 issues@www 2001-07-03 04:03:22 UTC
Created attachment 334 [details]
patchset - registry
Comment 8 issues@www 2001-07-03 04:05:26 UTC
Created attachment 335 [details]
patchset - idlc
Comment 9 issues@www 2001-07-03 06:42:50 UTC
Created attachment 336 [details]
patchset - codemaker
Comment 10 issues@www 2001-07-05 02:01:29 UTC
Created attachment 347 [details]
patchset - inet
Comment 11 issues@www 2001-07-05 02:02:30 UTC
Created attachment 348 [details]
patchset - xmlscript
Comment 12 issues@www 2001-07-05 03:48:16 UTC
Created attachment 351 [details]
patchset - sot
Comment 13 issues@www 2001-07-05 04:17:45 UTC
Created attachment 352 [details]
patchset - rdbmaker
Comment 14 issues@www 2001-07-05 04:21:41 UTC
Created attachment 353 [details]
patchset - vcl
Comment 15 Unknown 2001-11-08 22:53:04 UTC
changing QA contact from bugs@ to issues@
Comment 16 sander_traveling 2002-05-14 16:37:12 UTC
issuezilla cleanup

plase re-op;en when the gcc3/libsdtc++ port is active again

Comment 17 caolanm 2010-03-29 21:08:49 UTC
per issue 106845 sb removed the partial irix port, so this doesn't make sense in
isolation anymore