ltib
[Top][All Lists]
Advanced

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

Re: [Ltib] question about gpsd-2.37-for-uclinux patch


From: Stuart Hughes
Subject: Re: [Ltib] question about gpsd-2.37-for-uclinux patch
Date: Thu, 04 Mar 2010 14:59:59 +0000
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi Andrea,

This looks like a bug to me.  I'm not sure if the developer that added
this patch is on the list or not, maybe they could comment.

Looking at it, HAVE_FORK should be computed in some kind of configure
context, or at least default to 1 (maybe in the spec file).

The most crude way of calculating HAVE_FORK would be to assume that if
the symbol __uClinux__ is defined (by the compiler) then HAVE_FORK is 0
otherwise 1.

A better way is to look at unistd.h (see:
http://article.gmane.org/gmane.comp.video.mplayer.devel/53040).  On a
uClinux toolchain unistd.h takes into account the MMU and only defines
fork() if there is one:

From:
/opt/freescale/usr/local/gcc-4.2.47-uclibc-0.9.47/m68k-uclinux/m68k-uclinux/libc/usr/include/unistd.h

#ifdef __ARCH_USE_MMU__
/* Clone the calling process, creating an exact copy.
   Return -1 for errors, 0 to the new process,
   and the process ID of the new process to the old process.  */
extern __pid_t fork (void) __THROW;
#endif


For now you have 2 options, remove the patch (comment out the line in
the .spec file in the %prep section referring to it).  Or you could add
a patch to correctly compute/define HAVE_FORK.

BTW: I did a quick grep and these packages also look suspiciously
similar to me: alsa-lib, iperf, netperf, openssl

mplayer has a test, but it looks incorrect (based on the host, not
target system).

Regards, Stuart


Andrea Galbusera wrote:
> Hi Ltib folks,
> After upgrading my ltib environment from a previous Freescale BSP up to
> the latest Savannah CVS version, I noticed that one of the packages used
> by my configuration was not behaving as before.
> 
> The package is gpsd: after some investigation I found out that a new
> patch was applied to the default spec file for this package (against the
> same version of upstream sources, gpsd-2.37). The patch is very simple
> and seems to target those architectures that don't implement the fork()
> system call. Here is the patch's content:
> 
> gpsd-2.37-for-uclinux.patch
> --- gpsd-2.37.org/gpsd.c      2008-11-20 09:17:01.000000000 +0800
> +++ gpsd-2.37/gpsd.c  2008-11-20 09:18:15.000000000 +0800
> @@ -126,8 +126,11 @@
>  {
>      int fd;
>      pid_t pid;
> -
> +#if defined(HAVE_FORK)
>      switch (pid = fork()) {
> +#else
> +    switch (pid = vfork()) {
> +#endif
>      case -1:
>       return -1;
>      case 0:  /* child side */
> 
> My question is: who's responsible for providing HAVE_FORK symbol at
> compile time? I can't see any change in configure script. Is it supposed
> to be provided by the ltib configuration environment? If so, how?
> 
> The point is that on my architecture - that HAS fork() - this code get
> compiled in with the #else clause enabled (calling vfork() instead of
> fork()). This results in gpsd not demonizing anymore by default (as
> stated in the manpage for version 2.37) since vfork will block parent
> process.
> 
> Am I missing something or is this a sort of a bug?
> 
> TIA
> Regards
> Andrea
> 
> 
> 
> _______________________________________________
> LTIB home page: http://ltib.org
> 
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib
> 




reply via email to

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