V3 PATCH to std_complex.h

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

| On Sun, 30 May 2004, Gabriel Dos Reis wrote:
| 
| > In principle, yes.  Which reminds me that I grumbled about the scheme
| > __builtin_xxx expanding to call to xxx -- it is too C-centric.  A way
| > to fix that is to have it call __xxx.  
| > When linking, if we supply -lc before user .o files or libraries,
| > shouldn't that just work?
| 
| I don't think any simple linking trick will provide a magic solution to
| some object files wanting ccos (say) from the C library (through having
| used <complex>) and some wanting a local function of the same name.
| 
| Calling __xxx works as long as the library provides such a function and
| exports it; and glibc doesn't export most such names at present, but uses
| them internally only (exporting them as GLIBC_PRIVATE when another library
| included with glibc needs them from libc).  This may need changing for
| functions used (directly or through built-in functions) from libstdc++
| headers, so that they are exported in namespace-safe versions just as __
| functions used in macros in glibc headers are exported.

So, let me recap:

   (1) on Glibc-systems, we could try to persuade Glibc people to
       export those __xxx functions in a way suitable for use by
       libstdc++.

   (2) on nonglibc-systems, we just replicate the definitions in
       libmath/stubs.c? 

Does that match what you're suggesting?

Hmm, this looks like we've been here before and decided to go with
unconditional definitions in the header -- but then, we no longer
benefits from possible transformations in the compiler...

-- Gaby