This is the mail archive of the
mailing list for the libstdc++ project.
Re: current mainline, port status
> >FAIL: 26_numerics/complex/13450.cc (test for excess errors)
> >FAIL: 26_numerics/complex/complex_value.cc (test for excess errors)
> >FAIL: 26_numerics/complex/pow.cc (test for excess errors)
> >all fail with various forms of (this linker error):
> >...libstdc++-v3/include/complex:593: undefined reference to `carg'
> >[and cargf, cexpf, cexp, cabsl]
> >How are other ports looking these days?
> I think the single most importante open issue is the above, which also
> affects hpux, and Darwin, for instance, but I haven't really studied it
> in detail: I'm afraid, for 4.0 at least, we can only "fix" it by a
> of configury bits and testsuite tweaks.
I seem to remember this dimly: Gaby asked for help with some of the
complex bits, where __builtin_carg wasn't available or couldn't be used,
and so a reference to carg is used instead.
I can't find the reference right now on the list. Gaby?
>From a brief look at std_complex.h, I would think that one thing we
could do is a generic macro like _GLIBCXX_COMPLEX_BUILTINS, where we
flip that on at configure time if all the builtin functions are present,
and then guard the specializations that use the builtins in
std_complex.h with this.
Without the macro, code would just use the primary template (which uses