bfd_abort vs. noreturn vs. _exit
Mon May 10 07:47:00 GMT 2010
I would kind of like to avoid fixincludes if I can.
For example... you can't cross build fixincludes, because it uses fork, and VMS doesn't presently have fork.
I've been using -disable-fixincludes or deleting the directory.
(actually I'm off on Solaris x86/amd64 stuff, will come back to VMS soon).
Fixincludes seem to be problematic for cross builds in general.
I opened multiple bugs, years, ago, they languish.
For example, gcc build gets confused when build!=host and host=target.
It thinks host=target is a "native" build.
But this only affects/affected fixincludes as I recall.
Some advise says to later run fixincludes on the target, and yet other advise
says that isn't supported (just look through the old bugs I opened; granted,
I haven't revisisted them myself in years).
Really, larger point, I haven't quite accepted the idea of fixincludes.
I'd like to imagine the headers are acceptable asis.
Granted, I don't remember finding a good solution here.
I think configure -disable-werror is my current favorite.
Granted also, they are full of #pragma this and that.
In need of e.g. #define __int64 long long somewhere, and I have in fact hacked up the includes myself a little..
(but maybe gcc could understand __int64; I opened a bug).
> Subject: Re: bfd_abort vs. noreturn vs. _exit
> From: firstname.lastname@example.org
> Date: Mon, 10 May 2010 09:38:40 +0200
> CC: email@example.com
> To: firstname.lastname@example.org
>> /usr/local/alpha-dec-vms/include/unistd.h doesn't declare _exit with such an annotation.
>> Possibly the native compiler has no such mechanism.
> AFAIK, the native compiler (dec-c) has no such mechanism. The correct way to fix that is through
>> It seems to me there is a slight tension between portability and quality.
>> Quality says to put in the attribute for slightly better compiler analysis/diagnostics.
>> Portability says to remove it.
>> - Jay
More information about the Binutils