imp at bsdimp.com
Sun Jul 10 05:08:08 UTC 2011
I know this is a little late, but...
On Jul 5, 2011, at 2:12 PM, Ed Maste wrote:
> On Tue, Jul 05, 2011 at 02:05:27PM -0400, Alexander Kabaev wrote:
>> 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 just as __FreeBSD__ is. You choose to disable
>> __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life
>> porting software easier and are asking FreeBSD project to cope with
>> the decision. This breaks compiles of new software with older
>> compilers than do not define the macro, takes __FreeBSD__ out of
>> symmetry with __linux__ and other similarly defined platform macros
>> and forces a race to update every other compiler out there to follow
>> the suit. I fail to see the benefits out-weighting the drawbacks in
>> this scenario.
> There are two separate issues here - the macro itself, and where it's
> On the topic of the macro itself, __FreeBSD__ implies something about
> the kernel and the libc, and it used to be the same case for __linux__.
> This became broken for __linux__ once people started combining a Linux
> kernel with other than glibc, and it would break if those combining
> the FreeBSD kernel with another libc defined __FreeBSD__.
> (A note on terminology - some may dislike the "GNU/" name for various
> reasons, but either way their project is properly called "Debian
> GNU/kFreeBSD." I'll refer to it as "kFreeBSD" here for brevity though,
> since the kFreeBSD part is the unique aspect of this project vs other
> Debian ports, and the full name is rather awkward to type.)
> kFreeBSD can't define __FreeBSD__, since it will break any existing
> software that uses that to infer something about the libc in use. So,
> that project had a choice; they could have created a new macro
> __Debian_GNU_kFreeBSD__, say, that indicates the kernel and libc in use.
> However, defining __FreeBSD_kernel__ (and __glibc__ presumably) makes
> more sense, and actually reduces the porting effort for both them and
> the FreeBSD porters. Any effort on porting software to the FreeBSD
> kernel done by either project is then applicable to the other. If
> kFreeBSD project members make a change to get some piece of software
> working on a FreeBSD kernel and then gets that change commited upstream
> we can take advantage of that work without any additional effort on our
I think we should define this.
> On the topic of where such a macro should be defined I originally had
> no strong opinion. However, valid points have been raised about
> compiling software for FreeBSD using compilers that are not the one in
> the base system (from ports or otherwise, and GCC or otherwise). This
> I think is a very valid point and one that would make me lean towards
> defining the macro in sys/param.h. How workable is it to #include
> sys/param.h to pick up the macro where needed?
Why can't the other compilers conform to the new standard instead?
More information about the freebsd-hackers