Date: Wed, 20 Feb 2013 17:59:23 +0200 From: Damjan Jovanovic <damjan.jov@gmail.com> To: Tijl Coosemans <tijl@coosemans.org>, freebsd-arch@freebsd.org Subject: Re: amd64 cc -m32 support and headers project branch Message-ID: <CAJm2B-m-Y==zHRe--xaDCULjUcL45we=K1cad4pncAdbRpGb3w@mail.gmail.com> In-Reply-To: <20120223171210.GB79013@zim.MIT.EDU> References: <201202061916.45998.tijl@coosemans.org> <20120223171210.GB79013@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 23, 2012 at 7:12 PM, David Schultz <das@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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJm2B-m-Y==zHRe--xaDCULjUcL45we=K1cad4pncAdbRpGb3w>