From: Ian Abbott <abbotti@mev.co.uk>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] nodejs build problems
Date: Wed, 10 Jul 2024 12:38:49 +0100 [thread overview]
Message-ID: <5b0e0443-2aba-4425-bed0-c1fe4c2cb73e@mev.co.uk> (raw)
In-Reply-To: <Zo4q2SoL42ITK8K2@pengutronix.de>
On 10/07/2024 07:31, Michael Olbrich wrote:
> On Tue, Jul 09, 2024 at 03:45:31PM +0100, Ian Abbott wrote:
>> Hello folks,
>>
>> This is my first time trying to build nodejs for arm-v7a-linux-gnueabif and
>> I'm not having much luck. It's failing at the "nodejs.prepare" stage in the
>> `try_check_compiler(CXX, 'c++)` call in "configure.py:
>>
>> ---------------------[8<]------------------------
>>
>> Traceback (most recent call last):
>> File "/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/build-target/node-v20.11.0/./configure",
>> line 29, in <module>
>> Node.js configure: Found Python 3.11.2...
>> import configure
>> File "/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/build-target/node-v20.11.0/configure.py",
>> line 2026, in <module>
>> check_compiler(output)
>> File "/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/build-target/node-v20.11.0/configure.py",
>> line 1038, in check_compiler
>> ok, is_clang, clang_version, gcc_version = try_check_compiler(CXX,
>> 'c++')
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> File "/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/build-target/node-v20.11.0/configure.py",
>> line 944, in try_check_compiler
>> gcc_version = tuple(map(int, values[1:1+3]))
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ValueError: invalid literal for int() with base 10: '__STDC__'
>> make: *** [/usr/local/lib/ptxdist-2024.03.0/rules/nodejs.make:84: /mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/state/nodejs.prepare]
>> Error 1
>> ---------------------[>8]------------------------
>>
>> This is being built in a Debian 12 ("bookworm") schroot. (I also get the
>> same problem when building in my usual Debian "testing" environment.)
>>
>> As you can see, I am using ptxdist-2024.03.0. The selected_toolchain is
>> `/opt/OSELAS.Toolchain-2023.07.1/arm-v7a-linux-gnueabihf/gcc-13.2.1-clang-16.0.6-glibc-2.37-binutils-2.40-kernel-6.3.6-sanitized/bin`.
>>
>> I tried downgrading to the nodejs-v18.13.0 rules and patch series from
>> ptxdist-2024.01.0, but it fails in the same way, so I think there is some
>> incompatibility between that `try_check_compiler` function and the
>> toolchain.
>>
>> I'm wondering if anyone else has seen the same problem and managed to solve
>> it?
>
> Hmmm, I've not seen this in my build tests. And I'm testing that
> combination as well. If you run ptxdist with '-v' then the whole compiler
> commandline is recorded in the logfile (with a 'wrapper:' prefix). Maybe
> call it manually to see what actually happens here.
Thanks Michael. I have since built nodejs successfully for the v7a
platform in DistroKit master branch, which uses the same toolchain, but
a more recent ptxdist (2024.05.0), so that gives me something to compare
against.
For DistroKit (with ptxdist-2024.05.0):
wrapper: arm-v7a-linux-gnueabihf-gcc
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/=
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-host/usr/lib/wrapper/=platform-v7a/
-mfpu=neon -fstack-protector-strong -fstack-clash-protection -fPIE
-pie -D_GLIBCXX_ASSERTIONS -print-sysroot
wrapper: cc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-host/usr/include
-c -o /tmp/cgfoWvk4/dummy.o /tmp/cgfoWvk4/dummy.c
wrapper: cc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-host/usr/include
-E /tmp/cgfoWvk4/dummy.c
wrapper: cc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-host/usr/include
-E /tmp/cgfoWvk4/dummy.c
wrapper: arm-v7a-linux-gnueabihf-gcc
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/=
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-host/usr/lib/wrapper/=platform-v7a/
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -mfpu=neon -Wl,-z,relro
-Wl,-z,now -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--build-id=sha1
-fstack-protector-strong -fstack-clash-protection -fPIE -pie
-D_GLIBCXX_ASSERTIONS -x c -o /dev/null -v - -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-target/usr/include
-B/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-target/usr/lib
-L/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-target/usr/lib
-Wl,-rpath-link
-Wl,/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-target/usr/lib
wrapper: gcc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-host/usr/include
-dumpversion
wrapper: arm-v7a-linux-gnueabihf-ld -v
wrapper: arm-v7a-linux-gnueabihf-gcc
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/=
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-host/usr/lib/wrapper/=platform-v7a/
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -mfpu=neon
-fstack-protector-strong -fstack-clash-protection -fPIE -pie
-D_GLIBCXX_ASSERTIONS -dumpversion -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/DistroKit/platform-v7a/sysroot-target/usr/include
For my platform (using ptxdist 2024.03.0):
wrapper: arm-v7a-linux-gnueabihf-gcc
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/=
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-host/usr/lib/wrapper/=platform-its-ipt4v2/
-mfpu=neon -print-sysroot -ggdb3
wrapper: cc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-host/usr/include
-c -o /tmp/cgTFhVra/dummy.o /tmp/cgTFhVra/dummy.c
wrapper: cc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-host/usr/include
-E /tmp/cgTFhVra/dummy.c
wrapper: cc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-host/usr/include
-E /tmp/cgTFhVra/dummy.c
wrapper: arm-v7a-linux-gnueabihf-gcc
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/=
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-host/usr/lib/wrapper/=platform-its-ipt4v2/
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -mfpu=neon -Wl,--hash-style=gnu
-Wl,--as-needed -Wl,--build-id=sha1 -x c -o /dev/null -v - -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-target/usr/include
-ggdb3
-B/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-target/usr/lib
-L/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-target/usr/lib
-Wl,-rpath-link
-Wl,/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-target/usr/lib
wrapper: gcc -isystem
/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-host/usr/include
-dumpversion
wrapper: arm-v7a-linux-gnueabihf-ld -v
wrapper: arm-v7a-linux-gnueabihf-gcc
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/=
-fdebug-prefix-map=/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-host/usr/lib/wrapper/=platform-its-ipt4v2/
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -mfpu=neon -dumpversion
-isystem
/mnt/lindata/work/abbotti/ptxdist/projects/its-ipt4-demo/platform-its-ipt4v2/sysroot-target/usr/include
-ggdb3
The main difference is that the DistroKit wrapper for
arm-v7a-linux-gnueabihf has these options: -fstack-protector-strong
-fstack-clash-protection -fPIE -pie -D_GLIBCXX_ASSERTIONS
and does not have this option: -ggdb3
but I think that is just differences in the selected hardening and
debugging options.
My next step is to try and capture the commands and pipe contents that
`try_check_compiler` is using.
--
-=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=-
-=( registered in England & Wales. Regd. number: 02862268. )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
next prev parent reply other threads:[~2024-07-10 11:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 14:45 Ian Abbott
2024-07-10 6:31 ` Michael Olbrich
2024-07-10 11:38 ` Ian Abbott [this message]
2024-07-10 16:45 ` Ian Abbott
2024-07-11 6:53 ` Michael Olbrich
2024-07-11 9:47 ` Ian Abbott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b0e0443-2aba-4425-bed0-c1fe4c2cb73e@mev.co.uk \
--to=abbotti@mev.co.uk \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox