Related articles |
---|
[2 earlier articles] |
Re: Language Books rkneusel@post.its.mcw.edu (1998-07-27) |
opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-07-27) |
Re: opinions wanted on control of extern inlines dwight@pentasoft.com (1998-07-28) |
Re: opinions wanted on control of extern inlines saroj@my-dejanews.com (1998-07-30) |
Re: opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-08-02) |
Re: opinions wanted on control of extern inlines bothner@cygnus.com (1998-08-02) |
Re: opinions wanted on control of extern inlines jason@cygnus.com (Jason Merrill) (1998-08-04) |
Re: opinions wanted on control of extern inlines KittyCrap@severins-child.demon.co.uk (Rachel-Louise Koktava) (1998-08-10) |
From: | Jason Merrill <jason@cygnus.com> |
Newsgroups: | comp.compilers |
Date: | 4 Aug 1998 22:16:34 -0400 |
Organization: | Cygnus Solutions, Sunnyvale, CA |
References: | 98-07-131 98-07-187 98-07-198 98-07-208 98-07-223 98-07-230 98-08-006 |
Keywords: | GCC, C++ |
>>>>> Rachel-Louise Koktava <KittyCrap@severins-child.demon.co.uk> writes:
> The use of other compilers is questionable. Wind River Systems (WRS) do
> not support the loading of ELF object files onto an embedded sparc
> target so any compiler must produce the default a.out-coff format for
> sparc chips.
This is unfortunate, since egcs g++ (and 2.8.x) support for
eliminating duplication is much better under ELF (and Windows
PE/COFF); the GNU linker just throws away extra copies. a.out is not
flexible enough to support this. I think COFF probably could, but
this hasn't been implemented, and a quick check indicates that SPARC
VxWorks uses a.out.
> My original suggest seems to be flawed. The #pragma interface and
> #pragma implementation directives cause a closed set of templates
Only if you use the obsolete -fexternal-templates flag. Without that
flag, they still serve their original purpose of controlling the
placement of vtables and extern inlines.
> However the repo patch cannot be employed as a viewpathing mechanism is
> used to undertake changes to code. The repo patch can (and does) try to
> recompile official build source from down the viewpath, which fails
> since since users don't have write permission to these directories.
The repo patch (which is folded into egcs) only tries to rebuild
object files with associated .rpo files, so you can control where it
tries to insert template instantiations. I'm not sure what your exact
situation is, but you can compile some files with -frepo and others
with -fno-implicit-templates, and then only the ones compiled with
-frepo will be considered. This may or may not be useful to you.
> As always, opinion and advise would be most welcome, and once again
> thanks to all who answered my original mail.
As the g++ maintainer, I'd like to work out something that could be
folded into the standard distribution, so that other people can
benefit from it. Let's talk.
Jason
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.