[Top][All Lists]
[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
>