[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Invalid position given by Telit HE910-EUG
From: |
Greg Troxel |
Subject: |
Re: Invalid position given by Telit HE910-EUG |
Date: |
Sun, 05 Apr 2020 11:25:49 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix) |
Titouan Christophe <address@hidden> writes:
> /home/titou/br-test-pkg/br-arm-full/build/gpsd-3.20/.sconf_temp/conftest_27:
> ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically
> linked, interpreter /lib/ld-uClibc.so.0, not stripped
I am guessing your build host is not arm....
> Yes, I am cross-compiling (building for ARM on an x86_64 host) with
> Buildroot, so this is normal, because the current SConstruct file
> attempts to build and run a simple program to determine
> sizeof(time_t). See
> https://gitlab.com/gpsd/gpsd/-/blob/release-3.20/SConstruct#L623-631
Back when gpsd used autoconf, I fixed cross compiling, and it worked
well. I have not tried since the switch to scons. Basically, the
notion of building a program and running it is something you just can't
do.
I'm not even really clear on the need to check time_t; it seems to be
about giving warnings to people if time_t is still a 32-bit value (which
is an OS choice, not determined by the CPU type, but one well-known OS
seems to use the native word size).
That build/run should obviously be conditional on not doing cross
compliation, with the usage either skipped or somehow worked around if
so. I think cross compilation is a requirement (and esr listed it as
so when he posted my requirement list :-), so I'd be inclined to just
remove this if at all possible.
You could try removing this from SConstruct, and either 1) find that the
definition added isn't used or 2) put a definition for your target there
manually.
- Invalid position given by Telit HE910-EUG, Titouan Christophe, 2020/04/03
- Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/03
- Re: Invalid position given by Telit HE910-EUG, Titouan Christophe, 2020/04/04
- Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/04
- Re: Invalid position given by Telit HE910-EUG, Titouan Christophe, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Titouan Christophe, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Greg Troxel, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Titouan Christophe, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG,
Greg Troxel <=
- Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Greg Troxel, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/06
- Re: Invalid position given by Telit HE910-EUG, Greg Troxel, 2020/04/06
- Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Ladislav Michl, 2020/04/05
- Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/05
Re: Invalid position given by Telit HE910-EUG, Gary E. Miller, 2020/04/03