Re: Problem compiling code with va_list assignment
> Thanks for the pointer. I was able to use a __va_copy(dst,src) instead of
> the more direct approach dst = src.
The 'more direct' approach being what you're used from x86 or other
architectures, but I hope reading the header file made clear why it's dead
wrong.
> However, I would like to comment on this problem. I am not certain that this
> is related to the topics on this list, but this problem living on Linux PPC,
> and my version of Linux installed being only Debian, I decided to post here.
BS. It's a PPC architecture problem so it hits Debian, LinuxPPC, Yellow
Dog, Mandrake and SuSE all alike.
> The compiler error came to a surprise to me, because I used to compile the
> code on Darwin PPC and never got this error reported. I went to look closer
Makes me wonder if Apple borked the compiler, or uses another ABI. Both
equally bad.
Please note that the compiler error message goes away if you compile
without optimization. Of course, you pay for that by nice runtime SEGVs.
> at the gcc includes on Darwin and found that there is an extra section in
> the va-ppc.h that has been added for AIX and APPLE OSs, perhaps to makes
> things a little bit more compatible with other *nix flavors (i.e. va_list
No, it will make binaries compiled with this crap incompatible with ones
compiled with gcc on Linux (or any powerpc Unix architecture adhering to
the SYSV ABI.
> My question is: shouldn't the GCC compiler that comes with Linux (Debian)
> PPC integrate this changes too? Running under APPLE, AIX, or LINUX on PPC,
Why? To break binary compatiblity with older binaries, libraries,
whatever? Please stop to think about this for a moment. What happens if a
binary built with the Apple compiler dynamically loads the Linux libc, and
calls things like printf(fmt, ...)? Does the Apple ABI provide a way to
detect this, and set up the valist accordingly? Don't think that's
even possible.
As far as just adding this inside a big fat #ifdef ______APPLE______ just
for reference, fine. But why not change the first define (#ifndef _WIN32)
to read #if !defined(_WIN32) && !defined(_APPLE_) ?
(Ironic, isn't it?)
> shouldn't we all be using the same headers for one architecture? The ABI is
> pervasive among all OSs running on the PowerPC (as far as using the GNU
> tools anyway.)
We should all be using the same ABI for sure. Apple decided to fork out ot
that, so binary ABI problems is what they get (that may have been the
purpose in the first place).
Michael
Reply to: