tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
cwrapper g++ -v erroring out (Re: Help with attempt to update devel/gdb (currently in wip/gdb))
Continuing debugging, I hope not to the annoyance of the public. My
current path lead me towards assuming a bug in cwrappers that manifests
only with my separate gcc build on Debian, not with a system-provided
gcc on Ubuntu.
Am Thu, 24 Apr 2025 22:26:18 +0200
schrieb "Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>:
> So it's searching in the CXX tag definition for a compiler of the same name
> as CC? It turns out empty for me.
>
> # ### BEGIN LIBTOOL TAG CONFIG: CXX
> […]
> # A language specific compiler.
> CC=""
>
> The working build with Ubuntu's system gcc has
>
> CC="c++"
I reproduced the libtool generation now in the work dir.
1. bmake build-env, in there
2. make new work directory, call ../gdb-16.2/configure
3. mkdir gdb; ../../gdb-16.2/gdb/configure; cd ..
4. mkdir gdb-no-cwrapper; PATH=$(drop_cwrapper_path $PATH) ../../gdb-16.2/gdb/configure; cd ..
The difference in the two generated gdb/libtool files is apparent:
$ diff -u gdb/libtool gdb-no-cwrapper/libtool
--- gdb/libtool 2025-04-25 14:40:45.901948552 +0200
+++ gdb-no-cwrapper/libtool 2025-04-25 14:42:47.596087930 +0200
@@ -9167,7 +9167,7 @@
# ### BEGIN LIBTOOL TAG CONFIG: CXX
# The linker used to build libraries.
-LD=""
+LD="/sw/compiler/gcc-13.2.0/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64"
# How to create reloadable object files.
reload_flag=" -r"
@@ -9177,25 +9177,25 @@
old_archive_cmds="\$AR \$AR_FLAGS \$oldlib\$oldobjs~\$RANLIB \$oldlib"
# A language specific compiler.
-CC=""
+CC="g++"
# Is the compiler the GNU compiler?
-with_gcc=
+with_gcc=yes
# Compiler flag to turn off builtin functions.
-no_builtin_flag=""
+no_builtin_flag=" -fno-builtin"
# How to pass a linker flag through the compiler.
-wl=""
+wl="-Wl,"
# Additional compiler flags for building library objects.
-pic_flag=""
+pic_flag=" -fPIC -DPIC"
… and it continutes. Basically all variables in the config are empty
with cwrappers in the path. So I need to dig around in the configure
script for the libtool part where it stumbles over the wrappers.
Diffing config.log of the two runs …
--- gdb/config.log 2025-04-25 14:53:48.352964864 +0200
+++ gdb-no-cwrapper/config.log 2025-04-25 14:52:09.579470003 +0200
@@ -27,7 +27,6 @@
/usr/bin/oslevel = unknown
/bin/universe = unknown
-PATH: /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.cwrapper/bin
PATH: /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.buildlink/bin
PATH: /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.gcc/bin
PATH: /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.tools/bin
@@ -66,22 +65,23 @@
configure:3456: $? = 0
configure:3445: gcc -v >&5
Using built-in specs.
-COLLECT_GCC=/nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.gcc/bin/gcc
+COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --enable-languages=c,c++,fortran --disable-gold --disable-werror --disable-multilib --prefix=/sw/compiler/gcc-13.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
-COMPILER_PATH=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc
-linux-gnu/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../.
./../../x86_64-pc-linux-gnu/bin/
-LIBRARY_PATH=/sw/env/gcc-13.2.0_openmpi-4.1.6/pkgsrc/2025Q1-devel/lib/x86_64-pc-linux-gnu/13.2.0/:/usr/lib64/../lib64/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/comp
iler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/sw/env/gcc-13.2.0_openmpi-4.1.6/p
kgsrc/2025Q1-devel/lib/:/usr/lib64/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/lib/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2
.0/../../../:/lib/:/usr/lib/
-... rest of stderr output deleted ...
-configure:3456: $? = 1
+configure:3456: $? = 0
configure:3445: gcc -V >&5
gcc: error: unrecognized command-line option '-V'
+gcc: fatal error: no input files
+compilation terminated.
[…]
So first it uses the cwrapper gcc, the second run uses plain gcc (which
resolves to the same binary in the end after wrapping). The gcc -v
output is different for the wrapper … and … the wrapper returns 1 on
gcc -v, while gcc itself returns 0? Same for g++ -v:
configure:4042: g++ -v >&5
Using built-in specs.
-COLLECT_GCC=/nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.gcc/bin/g++
+COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --enable-languages=c,c++,fortran --disable-gold --disable-werror --disable-multilib --prefix=/sw/compiler/gcc-13.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
-COMPILER_PATH=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc
-linux-gnu/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../.
./../../x86_64-pc-linux-gnu/bin/
-LIBRARY_PATH=/sw/env/gcc-13.2.0_openmpi-4.1.6/pkgsrc/2025Q1-devel/lib/x86_64-pc-linux-gnu/13.2.0/:/usr/lib64/../lib64/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/comp
iler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/sw/env/gcc-13.2.0_openmpi-4.1.6/p
kgsrc/2025Q1-devel/lib/:/usr/lib64/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/lib/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2
.0/../../../:/lib/:/usr/lib/
-... rest of stderr output deleted ...
-configure:4053: $? = 1
+configure:4053: $? = 0
That might be a clue.
$ /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.cwrapper/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.gcc/bin/g++
COLLECT_LTO_WRAPPER=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --enable-languages=c,c++,fortran --disable-gold --disable-werror --disable-multilib --prefix=/sw/compiler/gcc-13.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
COMPILER_PATH=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/sw/env/gcc-13.2.0_openmpi-4.1.6/pkgsrc/2025Q1-devel/lib/x86_64-pc-linux-gnu/13.2.0/:/usr/lib64/../lib64/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/sw/env/gcc-13.2.0_openmpi-4.1.6/pkgsrc/2025Q1-devel/lib/:/usr/lib64/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/lib/:/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-m64' '-fstack-protector-strong' '-v' '-I' '/nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.buildlink/include' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/collect2 -plugin /sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/liblto_plugin.so -plugin-opt=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper -plugin-opt=-fresolution=/beegfs/tmp/hummel2-front2/sw/1744250684.1774977.67358402/cczqHNSz.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/crtbegin.o -L/sw/env/gcc-13.2.0_openmpi-4.1.6/pkgsrc/2025Q1-devel/lib/x86_64-pc-linux-gnu/13.2.0 -L/usr/lib64/../lib64 -L/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0 -L/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/sw/env/gcc-13.2.0_openmpi-4.1.6/pkgsrc/2025Q1-devel/lib -L/usr/lib64 -L/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/lib -L/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../.. -zrelro -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/crtend.o /lib/x86_64-linux-gnu/crtn.o
/sw/compiler/gcc-13.2.0/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /lib/x86_64-linux-gnu/crt1.o: in function `_start':
(.text+0x17): undefined reference to `main'
collect2: error: ld returned 1 exit status
$ echo $?
1
Aha, that errors out. What is below? My actual compiler is hidden in
$ ls -l /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.gcc/bin/g++
lrwxrwxrwx 1 sw sw 31 Apr 24 17:37 /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.gcc/bin/g++ -> /sw/compiler/gcc-13.2.0/bin/g++
$ /sw/compiler/gcc-13.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/sw/compiler/gcc-13.2.0/bin/g++
COLLECT_LTO_WRAPPER=/sw/compiler/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --enable-languages=c,c++,fortran --disable-gold --disable-werror --disable-multilib --prefix=/sw/compiler/gcc-13.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
$ echo $?
0
That's fine. No linking attempted, no error produced. Why what
difference? It seems to trip up the libtool script generation of gdb at
least.
Is the script wrong in assuming that g++ -v should return 0? Trying a little hack:
$ mv /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.cwrapper/bin/g++{,.moved}
$ cat <<EOT > /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.cwrapper/bin/g++
#!/bin/sh
# just catch -v
if test $# = 1 && test "$1" = -v; then
$(dirname $0)/$(basename $0).moved -v
exit 0
fi
exec $(dirname $0)/$(basename $0).moved "$@"
EOT
$ chmod +x /nfs/ssd2.2/u/sw/work/a770de/pkgsrc/2025Q1-devel/bw/devel/gdb/work/.cwrapper/bin/g++
This changes the resulting libtool tag config to start with
# ### BEGIN LIBTOOL TAG CONFIG: CXX
# The linker used to build libraries.
LD="/sw/compiler/gcc-13.2.0/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64"
# How to create reloadable object files.
reload_flag=" -r"
reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"
# Commands used to build an old-style archive.
old_archive_cmds="\$AR \$AR_FLAGS \$oldlib\$oldobjs~\$RANLIB \$oldlib"
# A language specific compiler.
CC="g++"
# Is the compiler the GNU compiler?
with_gcc=yes
Looks a lot better. I presume if I hacked cwrappers to just pass along
the -v without trying a a program link that errors out, I'd fix the gdb
build.
Is that a bug or by design? I guess the cwrappers should be transparent
and offer the same behaviour as the underlying compilers, just with
adjustments for search paths, right? Not?
Revisiting the gdb build that _does_ work on the Ubuntu system with
system-provided gcc 11, I observe that it uses c++ as name and this
also works out for libtool. `c++ -v` returns 0 for /bin/c++, returns 1
for the cwrapper. But this does not confuse the libtool script generation.
It's also a bit weird that the build insists on calling c++, not g++,
as CXX environment variable suggests. But anyhow: With my hack that
makes `g++ -v` non-fatal in the cwrapper, the gdb build succeeds.
Opinions?
Alrighty then,
Thomas
--
Dr. Thomas Orgis
HPC @ Universität Hamburg
Home |
Main Index |
Thread Index |
Old Index