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 -- [email protected]
To unsubscribe send an email to [email protected]
--
Kind regards
Lahfa Samy
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
