[Olsr-dev] changing 'linux' macro to __linux__ or __gnu_linux__

[Hans-Christoph Steiner]

On 02/02/2012 10:54 AM, Felix Fietkau wrote:
> On 2012-02-02 4:49 PM, Hans-Christoph Steiner wrote:
>>
>>
>> On 02/02/2012 10:22 AM, Felix Fietkau wrote:
>>> On 2012-02-02 4:00 PM, Hans-Christoph Steiner wrote:
>>>>
>>>>
>>>> On 02/02/2012 08:58 AM, Felix Fietkau wrote:
>>>>> On 2012-02-01 8:56 PM, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>> One thing that I've learned in my own porting work is: it is generally
>>>>>> the least overall work to try to use the platform macros that are
>>>>>> automatically defined by the compiler.  Android's NDK only recently
>>>>>> added the __ANDROID__ macro, for example, and Android's gcc also defines
>>>>>> __linux__, but NOT __gnu_linux__.
>>>>>>
>>>>>> Every GNU/Linux I've tried (which is mostly Debian and derivatives) has
>>>>>> a compiler that sets __linux__ and __gnu_linux__.  So I propose changing
>>>>>> olsrd's linux macro to be __linux__ when its kernel-related and
>>>>>> __gnu_linux__ when its OS related.  This will allow the code to
>>>>>> differentiate between GNU/Linux and Android/Linux (not GNU at all,
>>>>>> besides the compiler).
>>>>>>
>>>>>> If people are amenable, I'll post a patch.  This isn't so much to fix a
>>>>>> specific issue now, but rather to prevent issues from arising in the future.
>>>>> I think it's better to explicitly check for android instead of relying
>>>>> on __gnu_linux__. There are enough embedded distros out there (e.g.
>>>>> OpenWrt) that are mostly GNU compatible, but do not use glibc, nor
>>>>> define __gnu_linux__
>>>>
>>>> If we use the __gnu_linux__, __linux__, and __ANDROID__ macros right,
>>>> chances are that the build system won't need to handle them at all.  The
>>>> build system will still need specific checks for Android and other
>>>> embedded systems to setup the build with the right cross-compiler.
>>>
>>> Do you have any examples where you'd check for __gnu_linux__ explicitly?
>>>
>>
>> Not yet specific to the olsrd code, but when there are things that are
>> from standard GNU libraries that are not always in other platforms, the
>> __gnu_linux__ macro makes sense.  I think there are also macros for GNU
>> libc, Android's Bionic libc, and others.  Those I know less well.
>>
>> One example function is ttyname(), which is a standard libc function
>> that is not implemented (yet?) in Bionic libc.
> I don't think you should use __gnu_linux__ to check for things that
> aren't in bionic libc, using __ANDROID__ is more appropriate for that.
> Many things that are not in bionic, are still implemented in uclibc, and
> __gnu_linux__ is not set for that.

I agree, mine wasn't an example for __gnu_linux__ but just
generally the idea in general.  Right now, if a call to ttyname() was
wrapped in olsrd's 'linux' macro, there wouldn't be a way from the build
system to get it working for Android.

An example specifically for __gnu_linux__ would be a GNU extension to
libc that works in a specific way with the linux kernel, I can't think
of a specific example for that off hand.  But there are common GNU
extensions like canonicalize_file_name() which are not POSIX and are not
in most other libcs.

.hc