|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|
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 gpsd.mk again there is DESTDIR and sysroot; more about it below)Yo Florian! On Wed, 17 Jun 2020 17:38:27 +0200 Florian Kiera <email@example.com> wrote:Somehow gpsd tries to install the python directory "gps" to STAGING_DIR/home/user/buildrootpath/output/host/lib/python2.7/site-packages/ instead of just the /home/user/buildrootpath/output/host/lib/python2.7/site-packages/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.
I told it to install it to STAGING_DIR not to STAGING_DIR/STAGING_DIR.Since it exists an unfortunate test of pkg-generic.mk 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?
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.<
gpsd.mk: the .mk file again if you want to check where/how the
DESTDIR and sysroot vars have been set
Description: Text document
Description: Text Data
|[Prev in Thread]||Current Thread||[Next in Thread]|