gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] featuretest macros


From: Greg Troxel
Subject: Re: [gpsd-dev] featuretest macros
Date: Fri, 21 Jun 2019 18:37:45 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

> Our problems have been with older distros.  For example, glibc before
> 2.10 is a lot messier.  Fred Wright has been testing those, but he is
> out of the country right now and can not test.

Makes sense that this is more of an issue the farther back one goes.

>> This doesn't surprise me; gpsd's usage is POSIX and common extensions.
>> I know of only one function that's hidden by default in NetBSD, which
>> is the OpenBSD variant of a function (that originated in OpenBSD) and
>> is different in NetBSD: for that one needs to define _OPENBSD_SOURCE.
>
> Which function?  I would like to document that in the SConstruct file.

I don't remember the name, and it came up in some other program, nothing
to do with gpsd.  gpsd compiles on netbsd-8 without defines, so
therefore I am 99.99% sure gpsd does not use it.

>> I think it's reasonably likely that the same results will be obtained
>> on other platforms.  But perhaps glibc or other things needs to be
>> told to include things in POSIX 2008 explicitly.
>
> Before glibc 2.10 and 2.19 things were ugly.  So testing older stuff,
> like the newest RHEL, is important.

You say older/newest, and I am guessing that translates to "current
stable releases of any LTS distribution still under support".

> I'd love to test, after 3.19.  But recent experience does not make
> me feel confident that the defines can all go.  They can likely
> be made better.

Definitely; I don't really think we can get rid of them.  But as an
example, defining _XOPEN_SOURCE to something and then defining
_NETBSD_SOURCE is basically a noop, at least on NetBSD.   So if we can
prune, that would be good.

>> diff --git a/SConstruct b/SConstruct
>> index 91ff42d8..f8e0c05b 100644
>
> Tested on Gentoo stable.  It fails.

Interesting.  I guess the question is (for post 3.19) which function,
what standard defines that function, and if that result is expected.   I
am really unclear on strlcpy; it's normal now in BSD-land, and I expect
most places, but Gentoo might need some _BSD_SOURCE define to see it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]