Re: [ptxdist] nodejs build problems

[Ian Abbott <abbotti@mev.co.uk>]

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?

-- 
-=( 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 )=-