amd64 cc -m32 support and headers project branch

[Damjan Jovanovic]

On Thu, Feb 23, 2012 at 7:12 PM, David Schultz <das at freebsd.org> wrote:
> On Mon, Feb 06, 2012, Tijl Coosemans wrote:
>> After a hiatus of almost a year I'd like to continue with merging i386
>> and amd64 headers to get "cc -m32" working on amd64. Previously I tried
>> to fix any problems with the headers first before merging, but this turned
>> out to be a long tedious process. So, because lack of -m32 support is
>> blocking other development I'd like to just merge a minimal set of
>> headers without any macro/type definition changes or other
>> reorganisations. The result will be similar to existing powerpc and mips
>> headers which already support both 32 and 64 bit.
>>
>> When that's done I can create a development branch to work on the
>> problems that have come up. Possible goals for such a branch are:
>>
>> - Fix inconsistencies such as types defined in sys/ and their limits
>>   in machine/. Also, sometimes the limits don't have the correct type.
>> - For types/limits defined under machine/ there is a lot of duplication
>>   between architectures. Try to move some to sys/.
>> - Try to make headers compiler agnostic; limit use of __attribute__,
>>   __builtin_* to a single file.
>> - Maybe remove support for gcc 2.*. The oldest version in ports is 3.4
>>   and I suspect some headers don't compile anymore with gcc 2.*.
>> - Add support for new compiler attributes/built-ins.
>> - Add missing POSIX prototypes, maybe commented out with /* UNIMPL ... */
>>   or similar so they can be grepped.
>> - The gcc ports currently patch some system headers where they think
>>   something is non-standard. These patched headers override the system
>>   headers which means you have to rebuild these ports whenever you do
>>   installworld to make sure they contain the latest changes. Some headers
>>   are trivial to fix, others less so.
>>
>>
>> If there are no objections, I'd like to start with the -m32 work in
>> a week or so.
>
> This sounds like it could degenerate into an error-prone ifdef
> hell.  Wouldn't it be much easier to just have a /usr/include32
> directory?

But we don't have include32 for any other architecture. And how would
it be implemented, compiler magic or #ifdef __LP64__ ..... #else
#include <../include32/myself.h> #endif?

On a possibly unrelated note, please let's try avoid the colossal fail
that Debian's/Ubuntu's "multiarch" ideas has become, where they
succeeded in separating 32 and 64 bit libraries into
/usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu, only to fail at
doing the same for /usr/include, causing you to be able to parallel
install the 32 and 64 bit binary versions of a package, but not the 32
and 64 bit development packages...