[Top][All Lists]

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

Re: Cross compile gpsd-3.20.1~dev for arm with buildroot

From: Florian Kiera
Subject: Re: Cross compile gpsd-3.20.1~dev for arm with buildroot
Date: Thu, 18 Jun 2020 09:52:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

Hey Gary

Am 17.06.20 um 20:18 schrieb Gary E. Miller:
Yo Florian!

On Wed, 17 Jun 2020 17:38:27 +0200
Florian Kiera <> wrote:

Somehow gpsd tries to install the python directory "gps" to 
instead of just the 
Why to you think one is right and the other wrong?  Some packagers want the
build products to go into STAGING_DIR.  Or is there a missing $?  I
can't tell without the full debug output.

which causes gpsd to create the directories of user/buildrootpath/...
etc and that created directory path is supposed to not be existing.
Supposed?  Depends on your build options.
Yes supposed to not be existing, from MY build options, but of cause gpsd must make a mess out of it. The DESTDIR/sysroot variables that are given to scons might be interesting. (Check the again there is DESTDIR and sysroot; more about it below)

Since it exists an unfortunate test of is failing and
causes the compiling to stop.
Not part of gpsd, no idea what it is or what it does.

Still need to find out why gpsd 
uses that staging directory as root and not the usual root.
Because you told it to?  Did you set STAGING_DIR somewhere?
I told it to install it to STAGING_DIR not to STAGING_DIR/STAGING_DIR.

Of cause there is a STAGING_DIR set, but the python modules of gpsd are installed wrong while the other tools are all installed correctly. Check out the "Installing to staging directory" part; this is where the break happens. All files are installed to the STAGING_DIR as supposed to except the gps/* contents. (line 461-474) STAGING_DIR is the path "/home/asterix/buildroot/dimm/buildroot-2020.05.2/output/host/arm-buildroot-linux-uclibcgnueabihf/sysroot" as you can tell from the beginning of every compile stage. May have a look to the .mk file again to understand it: there is sysroot that contains the STAGING_DIR and DESTDIR which also contains the corresponding target directory... for staging this is the STAGING_DIR as well... May gpsd falsely combines DESTDIR and sysroot for the python modules? Thats my assumption at least and would explain the mess. Sadly removing DESTDIR or sysroot will end up to scons not knowing where to install from the start or where to put the files at the install process.

I am not sure if I made it clear enough: DESTDIR and sysroot beeing both set is needed and makes no problem; EXCEPT when gpsd is installing the python object (python=yes), just the python objects are installed wrong. Probably by some miracles of gpsd's scons using DESTDIR/sysroot or sysroot/DESTDIR instead of just DESTDIR or just sysroot (whatever is supposed to be used there)... Or it even uses STAGING_DIR itself?

gpsd_3.20.1~dev_compiles.txt: the file i referred to in this mail, which contains the compilation log.< the .mk file again if you want to check where/how the DESTDIR and sysroot vars have been set

Regards Florian

Attachment: gpsd_3.20.1~dev_compiles.txt
Description: Text document

Description: Text Data

reply via email to

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