I found the folder cp inside : "coreboot/util/crossgcc/build-x86_64-elf-GCC/gcc"
I finally fixed the bug by building the latest make from git, the bug has been reported in March 2020 and fixed later, but still a new release since January 2020 hasn't been made yet thus all make version are affected by the bug.
Now I'm unfortunately hit by another build failure, this time building the coreboot rom img.
I don't know how to fix this, looks like a linker issue somewhere.
GEN build.h CC romstage/lib/version.o CC romstage/mainboard/emulation/qemu-i440fx/bootmode.o CC romstage/mainboard/emulation/qemu-i440fx/fw_cfg.o CC romstage/mainboard/emulation/qemu-i440fx/memmap.o CC romstage/mainboard/emulation/qemu-i440fx/romstage.o CC romstage/security/memory/memory.o CC romstage/southbridge/intel/common/reset.o CC romstage/southbridge/intel/common/rtc.o CC romstage/southbridge/intel/common/smbus.o CC romstage/southbridge/intel/i82371eb/early_pm.o CC romstage/southbridge/intel/i82371eb/early_smbus.o LINK cbfs/fallback/romstage.debug /home/zwei/project/opensource/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/console/vtxprintf.o: in function `number': /home/zwei/project/opensource/coreboot/src/console/vtxprintf.c:63: undefined reference to `__udivmoddi4' /home/zwei/project/opensource/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___udivdi3': /home/zwei/project/opensource/coreboot/src/lib/gcc.c:20: undefined reference to `__udivdi3' make: *** [src/arch/x86/Makefile.inc:172: build/cbfs/fallback/romstage.debug] Error 1 Le 2022-03-18 23:37, Peter Stuge a écrit :
Lahfa Samy wrote:
Hey so here is what I found out about the error and solved it, it was actually making this error because the folder named 'cp' exists, as soon as I renamed the folder 'cp' to something else, the build got working again.
Good find! Where did that 'cp' folder exist?
Very weird issue, if anyone has an idea why it happened, my shell being used is ZSH.
It actually makes sense. Most systems don't treat program binaries specially, they are usually just files, ie. entries in directories.
Commands issued to the system are searched in the PATH directories.
If there's an entry with the sought name in a PATH directory then it's not so wrong to try to execute it, although obviously directories can't ever be executed successfully.
Karl Semich wrote:
I was able to reproduce your error with:
Thanks for the reproducer.
sudo mkdir /usr/local/bin/asdf echo -e 'all:\n\tasdf' > Makefile make
I have gnu make 4.3 .
This could be considered a bug with gnu make, trying to execute directories. Ideally it would be reported to them and a fix contributed. It is likely very easy to fix.
make probably isn't actively choosing to do it.
$ sudo mkdir /usr/local/bin/asdf $ bash -c asdf bash: asdf: command not found $ tcsh -c asdf /usr/local/bin/asdf: Permission denied. $ busybox sh -c asdf sh: asdf: Permission denied $ gcc -o /tmp/a.out -x c - << EOF #include <stdio.h> #include <stdlib.h> #include <unistd.h>
int main(int argc, char *argv[]) { execlp("asdf", "asdf", NULL); perror("execlp"); exit(EXIT_FAILURE); } EOF $ /tmp/a.out execlp: Permission denied $
Based on the error messages and as confirmed with strace -f only bash chooses to reject the subdirectory as a command while the other programs probably just call execlp() or execvp(), so this is libc behavior.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org