Date: Tue, 5 Jul 2011 21:04:41 +0200 From: Robert Millan <rmh@debian.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] __FreeBSD_kernel__ Message-ID: <CAOfDtXOQjhm44RcOJPvrR-c%2BKnU1RcPn%2BajOw_EjUoWy%2B77Jdg@mail.gmail.com> In-Reply-To: <20110705140527.17362ed5@kan.dnsalias.net> References: <CAOfDtXPUxQO1zbnxh8sh%2By7g=d8QaH2svYtEQJ06L4d%2BQKG8VA@mail.gmail.com> <20110702193724.5c55a6c9@kan.dnsalias.net> <20110703020827.GA5763@sandvine.com> <CAGH67wQAv4Tf8HjccN2GZzgD2u1ZrORABtGehxXjeg109%2BRNWQ@mail.gmail.com> <20110703103531.4a553271@kan.dnsalias.net> <CAOfDtXOcfbNw6St5CMN4GB_psf8hZEV=hpL4q3mmQXqWeLmqXQ@mail.gmail.com> <20110705140527.17362ed5@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/7/5 Alexander Kabaev <kabaev@gmail.com>: > I agree with all of the above reasons, but none of them change the fact > that __linux__ is used left and right to identify both kernel and > userland environments Yes, __linux__ is used to identify userland. And almost 100% of the times it is the wrong macro. We've spent several years fixing this kind of bug. To give just one example among hundreds, here's the latest incarnation of __linux__ misuse, reported 3 days ago: http://lists.debian.org/debian-bsd/2011/07/msg00013.html > just as __FreeBSD__ is. Not exactly. For example, when you see __FreeBSD__, you know what libc you're dealing with. > You choose to disable > __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life > porting software easier If Debian GNU/kFreeBSD enabled __FreeBSD__, software would expect that it is being built on FreeBSD, and make lots of wrong assumptions. Debian GNU/kFreeBSD is not FreeBSD. It is a derivative that builds on the kernel of FreeBSD and some of its kernel-specific libraries. It's not surprising that asserting we're FreeBSD via the compiler results in breakage (to begin with, even GCC headers wouldn't work properly). (similar statements can be made for e.g. Darwin, which I think you're familiar with) > and are asking FreeBSD project to cope with > the decision. I'm asking FreeBSD project to make life easier for a derivative that is, one way or another, part of its ecosystem, at no cost other than the time spent discussing the proposal. > This breaks compiles of new software with older > compilers than do not define the macro, As far as I'm concerned, new software isn't supposed to rely on this macro unconditionally untill it is deemed reasonable to do so. > takes __FreeBSD__ out of > symmetry with =C2=A0__linux__ I could argue that __FreeBSD_kernel__ would be in symmetry with __linux__. But that's wordplay. I think we agreed to leave it out of the list :-) > and other similarly defined platform macros > and forces a race to update every other compiler out there to follow > the suit. There's no race, and nobody forcing it. --=20 Robert Millan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfDtXOQjhm44RcOJPvrR-c%2BKnU1RcPn%2BajOw_EjUoWy%2B77Jdg>