From: Baruch Siach <baruch@tkos.co.il>
To: buildroot@busybox.net
Subject: [Buildroot] Configuring the gpsd package
Date: Tue, 28 Jan 2014 21:07:25 +0200 [thread overview]
Message-ID: <20140128190725.GD5596@tarshish> (raw)
In-Reply-To: <20140128183340.410169ce@skate>
HI Thomas,
On Tue, Jan 28, 2014 at 06:33:40PM +0100, Thomas Petazzoni wrote:
> On Mon, 6 Jan 2014 17:56:37 +0200, Baruch Siach wrote:
> > > Anyway, I was able to run the gpsd and use the it in spite of probably
> > > not having the two dependencies. My questions are:
> > > 1. What is the purpose of the two dependencies?
> >
> > As the comment above the MMU dependency says, the gpsd code uses fork(). This
> > system call is not available on non-MMU systems. The same goes for threads
> > support. The package uses the pthreads API, and doesn't build without it.
> >
> > > 2. How come I was able to use the daemon anyway?
> >
> > Apparently you are using an external toolchain. When using an external
> > toolchain you need to explicitly tell Buildroot whether you toolchain includes
> > threading supports.
>
> Correct, but Buildroot checks the selection the user has made in
> menuconfig against the real configuration of the toolchain, and if they
> don't match, the Buildroot build doesn't even start. Therefore, there
> is normally no way to do an incorrect configuration here.
Interesting. Where is the code implementing this check? Does it detect
threading support when the user has not indicated that the toolchain has it
(as is apparently the case here)?
> > As to MMU, for some reason this is option is disabled on your
> > configuration, although clearly your target has MMU enabled.
>
> Where have you seen Gabi's .config ? I've gone through this thread
> again, and I haven't seen his .config.
The message at http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/73739
may be interpreted as saying that MMU and HAS_THREADS are not enabled, though
it is more likely that only HAS_THREADS is missing.
> That being said, Gabi uses a 3+ years old Buildroot, and refuses to
> share his changes, so I must say that the incentive to provide some
> free support in such a situation is fairly low.
Agreed.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
next prev parent reply other threads:[~2014-01-28 19:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-01 15:31 [Buildroot] Configuring the gpsd package Gabi Kelemen
2014-01-01 16:20 ` Baruch Siach
2014-01-02 7:53 ` Gabi Kelemen
2014-01-02 8:01 ` Baruch Siach
2014-01-02 8:21 ` Gabi Kelemen
2014-01-02 8:45 ` Baruch Siach
2014-01-02 9:40 ` Gabi Kelemen
2014-01-02 10:04 ` Baruch Siach
2014-01-02 10:29 ` Gabi Kelemen
2014-01-06 15:42 ` Gabi Kelemen
2014-01-06 15:56 ` Baruch Siach
2014-01-28 17:33 ` Thomas Petazzoni
2014-01-28 19:07 ` Baruch Siach [this message]
2014-01-28 19:42 ` Thomas Petazzoni
2014-01-29 7:31 ` Gabi Kelemen
2014-01-29 7:40 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140128190725.GD5596@tarshish \
--to=baruch@tkos.co.il \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox