Date: Wed, 20 Feb 2013 10:25:44 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Damjan Jovanovic <damjan.jov@gmail.com> Cc: Tijl Coosemans <tijl@coosemans.org>, freebsd-arch@freebsd.org Subject: Re: amd64 cc -m32 support and headers project branch Message-ID: <5124F908.3010901@freebsd.org> In-Reply-To: <CAJm2B-m-Y==zHRe--xaDCULjUcL45we=K1cad4pncAdbRpGb3w@mail.gmail.com> References: <201202061916.45998.tijl@coosemans.org> <20120223171210.GB79013@zim.MIT.EDU> <CAJm2B-m-Y==zHRe--xaDCULjUcL45we=K1cad4pncAdbRpGb3w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/20/13 09:59, Damjan Jovanovic wrote: > 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... > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5124F908.3010901>