Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error with --verbose mode: gcc: fatal error: cannot execute 'cc1': execvp: No such file or directory #445

Open
marxin opened this issue Feb 6, 2022 · 8 comments

Comments

@marxin
Copy link

marxin commented Feb 6, 2022

It's a follow-up of #439, now with the patch from #439 (applied on the latest release) I see:

./fixincludes/config.log
...
configure:3652: checking whether the C compiler works
configure:3674: gcc -g -O2      -static-libstdc++ -static-libgcc  conftest.c  >&5
[10:34:11.778532, el, 11333] lib.cc; execve path: /usr/bin/gcc
[10:34:11.783695, el, 11333] lib.cc; on_load
[10:34:11.783789, wr, 11333, ppid: 11332] wrapper: 3.0.18
[10:34:11.783798, wr, 11333, ppid: 11332] arguments: ["/usr/lib64/bear/wrapper", "--destination", "dns:///localhost:33953", "--verbose", "--execute", "/usr/bin/gcc", "--", "gcc", "-g", "-O2", "-static-libstdc++", "-static-libgcc", "conftest.c"]
[10:34:11.783805, wr, 11333, ppid: 11332] environment: ["SHELL=/bin/sh", "GOC=", "OBJDUMP_FOR_TARGET=objdump", "HOST_LIBS=", "M4=m4", "INTERCEPT_REPORT_DESTINATION=dns:///localhost:33953", "YACC=bison -y", "FLEX=flex", "ISLINC=", "CPPFLAGS_FOR_BUILD=", "LANGUAGE=C", "DSYMUTIL=dsymutil", "GDC=gdc", "SED=/usr/bin/sed", "AS_FOR_TARGET=as", "LD_FOR_TARGET=/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld", "DSYMUTIL_FOR_TARGET=dsymutil", "as_nl=
", "PWD=/dev/shm/objdir/fixincludes", "OTOOL_FOR_TARGET=otool", "RANLIB_FOR_TARGET=ranlib", "CXX=g++", "CXXFLAGS=-g -O2    ", "WINDRES=windres", "GMPLIBS=-lmpc -lmpfr -lgmp", "s=/home/marxin/Programming/gcc", "r=/dev/shm/objdir", "LD_PRELOAD=/usr/lib64/bear/libexec.so", "LDFLAGS=-static-libstdc++ -static-libgcc ", "WINDMC=windmc", "TOPLEVEL_CONFIGURE_ARGUMENTS=/home/marxin/Programming/gcc/configure --enable-languages=c,c++,fortran,jit --prefix=/home/marxin/bin/gcc --disable-multilib --enable-host-shared --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap", "CXX_FOR_BUILD=g++", "READELF_FOR_TARGET=readelf", "LD=/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld", "AR_FOR_TARGET=ar", "GCC_FOR_TARGET= /dev/shm/objdir/./gcc/xgcc -B/dev/shm/objdir/./gcc/", "INTERCEPT_REPORT_COMMAND=/usr/lib64/bear/wrapper", "CPP_FOR_BUILD=", "READELF=readelf", "AWK=gawk", "DLLTOOL=dlltool", "ADA_CFLAGS=", "BISON=bison", "CC_FOR_BUILD=gcc", "ISLLIBS=-lisl", "INTERCEPT_VERBOSE=true", "AR=ar", "AS=as", "SHLVL=2", "NM=nm", "LEX=flex", "GMPINC=", "DUALCASE=1", "LD_LIBRARY_PATH=", "MAKEINFO=makeinfo --split-size=5000000", "NM_FOR_TARGET=nm", "OBJCOPY_FOR_TARGET=", "GFORTRAN=", "LIBELFLIBS=@libelflibs@", "OBJCOPY=", "XGCC_FLAGS_FOR_TARGET=-B/home/marxin/bin/gcc/x86_64-pc-linux-gnu/bin/ -B/home/marxin/bin/gcc/x86_64-pc-linux-gnu/lib/ -isystem /home/marxin/bin/gcc/x86_64-pc-linux-gnu/include -isystem /home/marxin/bin/gcc/x86_64-pc-linux-gnu/sys-include  ", "LC_ALL=C", "OTOOL=otool", "OBJDUMP=objdump", "CC=gcc", "CFLAGS=-g -O2    ", "CONFIG_SHELL=/bin/sh", "RANLIB=ranlib", "OLDPWD=/dev/shm/objdir", "LIBELFINC=@libelfinc@", "_=/usr/bin/gcc"]
[10:34:11.783811, wr, 11333, ppid: 11332] arguments parsed: {program: /usr/lib64/bear/wrapper, arguments: [{--: [gcc, -g, -O2, -static-libstdc++, -static-libgcc, conftest.c]}, {--destination: [dns:///localhost:33953]}, {--execute: [/usr/bin/gcc]}, {--verbose: []}]}
[10:34:11.784206, wr, 11333, ppid: 11332] gRPC call requested: supervise::Supervisor::Resolve
[10:34:11.785059, wr, 11333, ppid: 11332] gRPC call [Resolve] finished: true
[10:34:11.785272, wr, 11333, ppid: 11332] Process spawned. [pid: 11337, command: [gcc, -g, -O2, -static-libstdc++, -static-libgcc, conftest.c]]
[10:34:11.785298, wr, 11333, ppid: 11332] gRPC call requested: supervise::Interceptor::Register
[10:34:11.785743, wr, 11333, ppid: 11332] gRPC call [Register] finished: true
[10:34:11.785772, wr, 11333, ppid: 11332] Process wait requested. [pid: 11337]
[10:34:11.786344, el, 11337] lib.cc; on_load
[10:34:11.786858, el, 11338] lib.cc; execvp file: cc1
[10:34:11.786882, el, 11338] lib.cc; execvp failed.
gcc: fatal error: cannot execute 'cc1': execvp: No such file or directory
compilation terminated.

Note it does not happen without the --verbose option.

@rizsotto
Copy link
Owner

rizsotto commented Feb 7, 2022

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?

@marxin
Copy link
Author

marxin commented Feb 9, 2022

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

@rizsotto
Copy link
Owner

rizsotto commented Feb 9, 2022

Thanks @marxin , can you show the output for libexec.so too?

@marxin
Copy link
Author

marxin commented Feb 10, 2022

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)

@rizsotto
Copy link
Owner

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.)

@marxin
Copy link
Author

marxin commented Feb 13, 2022

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

@rizsotto
Copy link
Owner

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.

@nairajay2k
Copy link

I am facing the same issue on ubuntu 22.04. Is this fixed . Please let me know what to do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants