From: Ian Abbott <abbotti@mev.co.uk>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] nodejs build problems
Date: Thu, 11 Jul 2024 10:47:00 +0100 [thread overview]
Message-ID: <e566cd4f-774f-4750-8baf-d8712a3db934@mev.co.uk> (raw)
In-Reply-To: <Zo-BVtDBnI0NbFw4@pengutronix.de>
On 11/07/2024 07:53, Michael Olbrich wrote:
> On Wed, Jul 10, 2024 at 05:45:13PM +0100, Ian Abbott wrote:
>> On 10/07/2024 12:38, Ian Abbott wrote:
>>> 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.
>>
>> I have found that the problem only occurs when selecting
>> PTXCONF_TARGET_DEBUG_FULL (architecture ---> extra toolchain options --->
>> debugging (xxx) ---> enabled (full)) in the platformconfig. That sets the
>> `-ggdb3` compiler option. The problem does not occur when selecting
>> PTXCONF_TARGET_DEBUG_ENABLE (sets the `-g` compiler option).
>>
>> The `-ggdb3` option seems to make the GCC preprocessor emit all the
>> `#define` and `#undef` lines even when the `-P` command line option has been
>> used to suppress line control output. (Specifically, it is the request for
>> level 3 debugging information that causes this, so the `-g3` compiler option
>> would do the same thing.) The first line of output is:
>>
>> #define __STDC__ 1
>>
>> However, the `try_check_compiler` function in configure.py is expecting to
>> read a single line of output corresponding to the macro expansion of the
>> following line:
>>
>> __clang__ __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__ __clang_major__
>> __clang_minor__ __clang_patchlevel__
>>
>> For the toolchain in use, that will be macro-expanded to the following line:
>>
>> __clang__ 13 2 1 __clang_major__ __clang_minor__ __clang_patchlevel__
>>
>> With the `-ggdb3` option, that line appears as the last line of output,
>> after over 400 `#define` and `#undef` lines.
>>
>> The next question is how to fix it? Is there a way to disable compiler
>> debugging options during the .prepare stage, or failing that, change or
>> disable the debugging options for a particular package?
>
> Blacklist full debugging:
>
> NODEJS_WRAPPER_BLACKLIST := TARGET_DEBUG_FULL
>
> libpng for example does the same thing and from the commit message it
> sounds like a very similar problem.
>
> But that means, that the extra debug symbols are not enabled at all for
> nodejs.
>
> It would probably be better to detect something like this in the wrapper
> and add any debug options in this case. I think '-E' is probably the best
> indicator but that needs some investigating.
Thanks, I'll use that locally until something less brutal comes along.
I can't see myself attempting to debug nodejs anyway! I'm wondering
whether to raise it as a issue with the maintainers, because they'd
probably just say to use the debug build of node.js.
Locally, I have added this rules/post/nodejs-fixup.make:
------------------------------------------------------------------
# -*-makefile-*-
ifdef PTXCONF_TARGET_DEBUG_FULL
# nodefs.prepare fails if PTXCONF_TARGET_DEBUG_FULL is enabled
NODEJS_WRAPPER_BLACKLIST := TARGET_DEBUG_FULL
# drop the debug information level down from level 3 to level 2
NODEJS_CFLAGS += -ggdb2
endif
# vim: syntax=make
------------------------------------------------------------------
--
-=( 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 )=-
prev parent reply other threads:[~2024-07-11 9:47 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
2024-07-10 16:45 ` Ian Abbott
2024-07-11 6:53 ` Michael Olbrich
2024-07-11 9:47 ` Ian Abbott [this message]
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=e566cd4f-774f-4750-8baf-d8712a3db934@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