gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] The attempt to use VTIME has been removed


From: Eric S. Raymond
Subject: Re: [gpsd-dev] The attempt to use VTIME has been removed
Date: Sat, 31 Jan 2015 18:34:05 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Gary E. Miller <address@hidden>:
> > According to strerror(3), glibc provides a POSIX strerror_r() if you
> > set the right feature macros.  I'd say do that.
> 
> I considered that, but, Windows does not have strerror_r(), and are all
> other gpsd hosts POSIX?

Yes.  And we currently don't have a Windows port, nor one in serious process,
so no point in worrying about that.

> We would need to match this:
> 
>    (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
> 
> Which conflicts with current SContruct:
> 
>     # We need to define -D_GNU_SOURCE
>     env.Append(CFLAGS='-D_GNU_SOURCE')

Hm.  I think I'll try buiding with this disabled to see where the 
dependency is.  I'm trying to move us away from glibc dependencies
so we van build with uclibc and other lightweight alternatives on
embedded systems.

I don't see any problem in principle with putting an #undef in ppsthread.c.
 
> Can gpsd assume the _GNU_SOURCE version of strerror_r() is always
> available on all known gpsd hosts?  Sadly POSIX strerror_r() and GNU
> strerror() are incompatible!

Yeah.  I'd rather hew to POSIX/XSI.
 
> In any case, probably nothing we want to try when you want to get a
> release out.  Low risk to leave it alone until after release.  If
> something urgent needed to be done I'd just remove strerror() from
> ppsthread.c and just output the errno.  No sign of urgency.

Agreed on all points.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

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