This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: V3 PATCH to std_complex.h
"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