mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
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 )=-



      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