amd64 cc -m32 support and headers project branch

[Nathan Whitehorn]

On 02/20/13 09:59, Damjan Jovanovic wrote:
> 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...
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

I'll point out again that the #ifdef route is what we are currently 
doing, and have done for a couple years, for -m32 on PowerPC and MIPS. 
All the header files are actually shared for these architectures between 
32 and 64-bit versions (similar to sys/x86, but more complete) and it 
all works very well with a minimum of ugliness. I'd strongly encourage 
the same route for x86.
-Nathan