This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Backticks (`) in makefile
- From: LLeweLLyn Reese <llewelly at lifesupport dot shutdown dot com>
- To: John Love-Jensen <eljay at adobe dot com>
- Cc: Tapu <anirudha at cmcltd dot com>, <gcc-help at gcc dot gnu dot org>
- Date: 24 Jun 2003 15:39:42 -0700
- Subject: Re: Backticks (`) in makefile
- References: <BB1C5E58.9316%eljay@adobe.com>
John Love-Jensen <eljay@adobe.com> writes:
> Hi Tapu,
>
> >The idea I have is: the standard lib in C++ will have some OS specific
> libraries and some will be architecture specific. Is it true?
>
> I believe you are correct.
>
> >How to identify them?
>
> By convention, OS specific headers usually reside in the sys/... location.
>
> Architecture specific accommodations are in the header file as
> isolated-embedded #if defined()...#endif blocks, which are usually very
> platform-centric code activated by the preprocessor.
>
> >The next in line is, regarding ABIs .. For the compiler we'll have to define
> one ABI.. And again for standard lib in C++, we'll again have to define some C++
> ABI..At least that's what i understood..
>
> >In which way they differ ?
>
> I don't have an URL that describes the detailed differences between the C
> ABI (which is well established), and the C++ ABI (which has evolved from GCC
> 2.95, RedHat's 2.96, GCC 3.0, GCC 3.1, GCC 3.2 and GCC 3.3).
>
> The C++ ABI is still somewhat of a moving target, in that GCC 3.3 is,
> hopefully, quiescent. However, when/if a C++ ABI cross-vendor standard
> becomes available, I suspect that the GCC C++ ABI will change again, to
> accommodate the anticipated standard.
Here is a cross-vendor ABI:
http://www.codesourcery.com/cxx-abi/
gcc 3.x tries to meet that standard. 3.1.0, 3.2.0, 3.3.0 are all
releases in which abi-breaking bugfixes had to be introduced; in
each case gcc did not correctly implement the abi (or the abi
changed).
However that ABI is for the core language, and does not include the
standard library.
>
> The C++ ABI covers things like: exception handling, name mangling, scoped
> enumerations, inner classes/structs, calling convention, RTTI, dynamic
> casting, and probably a bazillion details with which I am unaware.
Since most programs use library facilities like std::cout, it may also
include things such as the sizes and layouts of objects
passed to and from functions in libstdc++.so , and of global
objects like std::cout. To say nothing of function names ...
>
> (My hat is off to the unsung heroes who have tackled the C++ ABI.)
Agreed.