On 07/09/2017 01:37 PM, Mats Wichmann wrote:
> On 07/09/2017 12:59 AM, Natalia Theologou wrote:
>
>> scons TARGET_OS=linux TARGET_ARCH=arm TARGET_TRANSPORT=IP SECURED=0
>> RELEASE=1 TC_PREFIX=arm-none-linux-gnueabi-
>> TC_PATH=/opt/gcc-arm-none-eabi-6-2017-q2-update/arm-none-eabi/bin
>
>
> Hmmm....
>
> somewhere in the bowels of our build scripts, if we're targeting linux:
>
> if 'gcc' in compiler:
> thread_env.AppendUnique(CFLAGS = ['-Wall'])
> if target_os not in ['android']:
> thread_env.AppendUnique(CFLAGS = ['-pthread'])
> thread_env.AppendUnique(LIBS = ['pthread'])
>
>
> But...
>
>
> scons: Configure: Checking for C++ library boost_thread...
> .sconf_temp/conftest_2.cpp <-
> |
> |
> |
> |int
> |main() {
> |
> |return 0;
> |}
> |
> Compiling .sconf_temp/conftest_2.o
> arm-none-eabi-g++: error: unrecognized command line option '-pthread'
> scons: Configure: no
>
>
> I think we have a bit of a problem here, I'm not sure iotivity works
> without threading.
I know the thread has moved on a bit here, but to circle back: does this
scenario even make sense?
TARGET_OS=linux
TARGET_ARCH=arm
TC_PATH=/opt/gcc-arm-none-eabi-6-2017-q2-update/bin
We "know" enough to be able to set TARGET_os=android and TARGET_OS=yocto
and TARGET_OS=tizen in cross building scenarios. But when it's just bare
"linux", should the build attempt even proceed? The toolchain from ARM
is pretty bare-bones (it's also packaged, at least on my Fedora system),
and unlike SDKs for Android and Tizen, and the Yocto environment, is not
fully populated with a bunch of the cross-built libraries you'd expect
to see in a full sysroot.
I'm just asking whether it's even worth trying to fix the current wrong
assumptions.
