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

[Florian Kiera]

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 <florian.kiera@logicway.de> 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.
>     
    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)
> > 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?
>     
    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.<

gpsd.mk: the .mk file again if you want to check where/how the DESTDIR and sysroot vars have been set

Regards Florian

gpsd_3.20.1~dev_compiles.txt
Description: Text document

gpsd.mk
Description: Text Data