Open marxin opened 2 years ago
Thanks for this @marxin ! This kind of weird behavior I associate to mis-compilations (when you do compile against a library, but when you run it picks up another one).
Is it possible you have multiple libC libraries? Or headers of the libC? What is the ldd
output for bear
, libexec.so
, intercept
and wrapper
? Is there any suspicious pick in CMake output?
No, I have a standard openSUSE Tumbleweed without any extra libC libraries.
$ ldd `which bear`
linux-vdso.so.1 (0x00007ffff7fc6000)
libspdlog.so.1 => /lib64/libspdlog.so.1 (0x00007ffff7f04000)
libfmt.so.8 => /lib64/libfmt.so.8 (0x00007ffff7ee4000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ffff7ccb000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff7cb1000)
libc.so.6 => /lib64/libc.so.6 (0x00007ffff7a82000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc8000)
libm.so.6 => /lib64/libm.so.6 (0x00007ffff799d000)
$ ldd /usr/lib64/bear/wrapper
linux-vdso.so.1 (0x00007ffff7fc6000)
libspdlog.so.1 => /lib64/libspdlog.so.1 (0x00007ffff7ede000)
libfmt.so.8 => /lib64/libfmt.so.8 (0x00007ffff7ebe000)
libprotobuf.so.30 => /lib64/libprotobuf.so.30 (0x00007ffff7b82000)
libgrpc++.so.1.41 => /lib64/libgrpc++.so.1.41 (0x00007ffff7aef000)
libabsl_synchronization.so.2111.0.0 => /lib64/libabsl_synchronization.so.2111.0.0 (0x00007ffff7ade000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ffff78c3000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff78a9000)
libc.so.6 => /lib64/libc.so.6 (0x00007ffff767a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc8000)
libz.so.1 => /lib64/libz.so.1 (0x00007ffff7660000)
libgrpc.so.19 => /lib64/libgrpc.so.19 (0x00007ffff7269000)
libgpr.so.19 => /lib64/libgpr.so.19 (0x00007ffff724d000)
libupb.so.19 => /lib64/libupb.so.19 (0x00007ffff722f000)
libabsl_strings.so.2111.0.0 => /lib64/libabsl_strings.so.2111.0.0 (0x00007ffff7214000)
libabsl_stacktrace.so.2111.0.0 => /lib64/libabsl_stacktrace.so.2111.0.0 (0x00007ffff720f000)
libabsl_symbolize.so.2111.0.0 => /lib64/libabsl_symbolize.so.2111.0.0 (0x00007ffff7206000)
libabsl_time.so.2111.0.0 => /lib64/libabsl_time.so.2111.0.0 (0x00007ffff71f3000)
libabsl_malloc_internal.so.2111.0.0 => /lib64/libabsl_malloc_internal.so.2111.0.0 (0x00007ffff71ec000)
libabsl_base.so.2111.0.0 => /lib64/libabsl_base.so.2111.0.0 (0x00007ffff71e4000)
libabsl_spinlock_wait.so.2111.0.0 => /lib64/libabsl_spinlock_wait.so.2111.0.0 (0x00007ffff71df000)
libabsl_raw_logging_internal.so.2111.0.0 => /lib64/libabsl_raw_logging_internal.so.2111.0.0 (0x00007ffff71da000)
libm.so.6 => /lib64/libm.so.6 (0x00007ffff70f7000)
libcares.so.2 => /lib64/libcares.so.2 (0x00007ffff70de000)
libabsl_statusor.so.2111.0.0 => /lib64/libabsl_statusor.so.2111.0.0 (0x00007ffff70d6000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007ffff7033000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007ffff6cfc000)
libaddress_sorting.so.19 => /lib64/libaddress_sorting.so.19 (0x00007ffff6cf7000)
libre2.so.9 => /lib64/libre2.so.9 (0x00007ffff6c99000)
libabsl_status.so.2111.0.0 => /lib64/libabsl_status.so.2111.0.0 (0x00007ffff6c8f000)
libabsl_cord.so.2111.0.0 => /lib64/libabsl_cord.so.2111.0.0 (0x00007ffff6c7a000)
libabsl_str_format_internal.so.2111.0.0 => /lib64/libabsl_str_format_internal.so.2111.0.0 (0x00007ffff6c62000)
libabsl_time_zone.so.2111.0.0 => /lib64/libabsl_time_zone.so.2111.0.0 (0x00007ffff6c49000)
libabsl_cordz_info.so.2111.0.0 => /lib64/libabsl_cordz_info.so.2111.0.0 (0x00007ffff6c42000)
libabsl_strings_internal.so.2111.0.0 => /lib64/libabsl_strings_internal.so.2111.0.0 (0x00007ffff6c3c000)
libabsl_debugging_internal.so.2111.0.0 => /lib64/libabsl_debugging_internal.so.2111.0.0 (0x00007ffff6c33000)
libabsl_demangle_internal.so.2111.0.0 => /lib64/libabsl_demangle_internal.so.2111.0.0 (0x00007ffff6c28000)
libabsl_int128.so.2111.0.0 => /lib64/libabsl_int128.so.2111.0.0 (0x00007ffff6c20000)
libabsl_cord_internal.so.2111.0.0 => /lib64/libabsl_cord_internal.so.2111.0.0 (0x00007ffff6c0d000)
libabsl_cordz_functions.so.2111.0.0 => /lib64/libabsl_cordz_functions.so.2111.0.0 (0x00007ffff6c08000)
libabsl_cordz_handle.so.2111.0.0 => /lib64/libabsl_cordz_handle.so.2111.0.0 (0x00007ffff6c00000)
libabsl_throw_delegate.so.2111.0.0 => /lib64/libabsl_throw_delegate.so.2111.0.0 (0x00007ffff6bf9000)
libabsl_exponential_biased.so.2111.0.0 => /lib64/libabsl_exponential_biased.so.2111.0.0 (0x00007ffff6bf4000)
$ ldd `which intercept`
linux-vdso.so.1 (0x00007ffff7fc6000)
libprotobuf.so.30 => /lib64/libprotobuf.so.30 (0x00007ffff7bff000)
libgrpc++.so.1.41 => /lib64/libgrpc++.so.1.41 (0x00007ffff7b6c000)
libspdlog.so.1 => /lib64/libspdlog.so.1 (0x00007ffff7b0a000)
libfmt.so.8 => /lib64/libfmt.so.8 (0x00007ffff7aea000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ffff78d1000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff78b5000)
libc.so.6 => /lib64/libc.so.6 (0x00007ffff7686000)
libz.so.1 => /lib64/libz.so.1 (0x00007ffff766c000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc8000)
libgrpc.so.19 => /lib64/libgrpc.so.19 (0x00007ffff7275000)
libgpr.so.19 => /lib64/libgpr.so.19 (0x00007ffff7259000)
libupb.so.19 => /lib64/libupb.so.19 (0x00007ffff723d000)
libabsl_synchronization.so.2111.0.0 => /lib64/libabsl_synchronization.so.2111.0.0 (0x00007ffff722a000)
libabsl_strings.so.2111.0.0 => /lib64/libabsl_strings.so.2111.0.0 (0x00007ffff720f000)
libm.so.6 => /lib64/libm.so.6 (0x00007ffff712c000)
libcares.so.2 => /lib64/libcares.so.2 (0x00007ffff7113000)
libabsl_statusor.so.2111.0.0 => /lib64/libabsl_statusor.so.2111.0.0 (0x00007ffff710d000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007ffff7068000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007ffff6d31000)
libaddress_sorting.so.19 => /lib64/libaddress_sorting.so.19 (0x00007ffff6d2c000)
libre2.so.9 => /lib64/libre2.so.9 (0x00007ffff6cce000)
libabsl_status.so.2111.0.0 => /lib64/libabsl_status.so.2111.0.0 (0x00007ffff6cc4000)
libabsl_cord.so.2111.0.0 => /lib64/libabsl_cord.so.2111.0.0 (0x00007ffff6cb1000)
libabsl_str_format_internal.so.2111.0.0 => /lib64/libabsl_str_format_internal.so.2111.0.0 (0x00007ffff6c97000)
libabsl_time.so.2111.0.0 => /lib64/libabsl_time.so.2111.0.0 (0x00007ffff6c84000)
libabsl_time_zone.so.2111.0.0 => /lib64/libabsl_time_zone.so.2111.0.0 (0x00007ffff6c6b000)
libabsl_cordz_info.so.2111.0.0 => /lib64/libabsl_cordz_info.so.2111.0.0 (0x00007ffff6c64000)
libabsl_spinlock_wait.so.2111.0.0 => /lib64/libabsl_spinlock_wait.so.2111.0.0 (0x00007ffff6c5f000)
libabsl_stacktrace.so.2111.0.0 => /lib64/libabsl_stacktrace.so.2111.0.0 (0x00007ffff6c58000)
libabsl_symbolize.so.2111.0.0 => /lib64/libabsl_symbolize.so.2111.0.0 (0x00007ffff6c4f000)
libabsl_malloc_internal.so.2111.0.0 => /lib64/libabsl_malloc_internal.so.2111.0.0 (0x00007ffff6c48000)
libabsl_base.so.2111.0.0 => /lib64/libabsl_base.so.2111.0.0 (0x00007ffff6c42000)
libabsl_raw_logging_internal.so.2111.0.0 => /lib64/libabsl_raw_logging_internal.so.2111.0.0 (0x00007ffff6c3d000)
libabsl_strings_internal.so.2111.0.0 => /lib64/libabsl_strings_internal.so.2111.0.0 (0x00007ffff6c37000)
libabsl_cord_internal.so.2111.0.0 => /lib64/libabsl_cord_internal.so.2111.0.0 (0x00007ffff6c22000)
libabsl_cordz_functions.so.2111.0.0 => /lib64/libabsl_cordz_functions.so.2111.0.0 (0x00007ffff6c1d000)
libabsl_int128.so.2111.0.0 => /lib64/libabsl_int128.so.2111.0.0 (0x00007ffff6c15000)
libabsl_cordz_handle.so.2111.0.0 => /lib64/libabsl_cordz_handle.so.2111.0.0 (0x00007ffff6c0f000)
libabsl_debugging_internal.so.2111.0.0 => /lib64/libabsl_debugging_internal.so.2111.0.0 (0x00007ffff6c06000)
libabsl_demangle_internal.so.2111.0.0 => /lib64/libabsl_demangle_internal.so.2111.0.0 (0x00007ffff6bfb000)
libabsl_throw_delegate.so.2111.0.0 => /lib64/libabsl_throw_delegate.so.2111.0.0 (0x00007ffff6bf4000)
libabsl_exponential_biased.so.2111.0.0 => /lib64/libabsl_exponential_biased.so.2111.0.0 (0x00007ffff6bef000
Thanks @marxin , can you show the output for libexec.so
too?
Sure
ldd /usr/lib64/bear/libexec.so
linux-vdso.so.1 (0x00007ffff7fc6000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ffff7d6f000)
libc.so.6 => /lib64/libc.so.6 (0x00007ffff7b40000)
libm.so.6 => /lib64/libm.so.6 (0x00007ffff7a5d000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffff7a43000)
What I have found interesting, that your PATH
is not in the log. If the PATH
is not accessible, the execvp
will fail. Unless it executes the process with full path. From this log I see it's just calls cc1
and that will require the PATH
to search.
As we have seen earlier from your strace
output, this is not what GCC does.
Can you create me a reproducable test? (I am just guessing otherwise. I could not reproduce it on my machines, nor on the CI build.)
You can reproduce it with the following Dockerfile:
FROM opensuse/tumbleweed
RUN zypper -n install gcc-c++ git mpfr-devel gmp-devel mpc-devel flex bison make Bear
RUN git clone --depth=1 git://gcc.gnu.org/git/gcc.git
WORKDIR gcc
RUN mkdir objdir
WORKDIR objdir
RUN ../configure --disable-bootstrap --disable-multilib
RUN bear --verbose -- make -j16
RUN wc -l compile_commands.json
podman build -t test -f Dockerfile.bear
I see:
[10:18:34.434029, wr, 622, ppid: 124] succeeded with: 0
[10:18:34.434071, el, 622] lib.cc; on_unload
configure: error: in `/gcc/objdir/fixincludes':
configure: error: C compiler cannot create executables
See `config.log' for more details
[10:18:34.436326, el, 630] lib.cc; execve path: /usr/bin/sed
[10:18:34.460248, el, 630] lib.cc; on_load
Thanks @marxin , I could reproduce the bug you've found. But this is not about the c11
anymore. It looks similar to #444 . Where the subprocess IO redirections does not work as expected... Will try to fix it this week.
I am facing the same issue on ubuntu 22.04. Is this fixed . Please let me know what to do
It's a follow-up of #439, now with the patch from #439 (applied on the latest release) I see:
Note it does not happen without the
--verbose
option.