Hi Coreboot folks,
Student here trying to build Coreboot in order to launch it with QEMU but the build (crossgcc-x86), I launched the build with this command inside the Coreboot folder (make crossgcc-x86 CPUS=8) seems to fail when building a dependency, anyone would have an idea what is going wrong based on the logs attached to this mail, the error looks like a permission denied, but I'm not too sure as there shouldn't be any permission issues regarding the folder for the build.
I'm aware that the documentation (https://www.coreboot.org/QEMU_Build_Tutorial) I've been using is probably outdated, and this may or may not explain why the build is failing.
If anyone could provide any help or support, thanks ! Hoping I can get to run Coreboot soon under QEMU !
(I've also tried to build crossgcc-i386 but ends up with another error, I can also provide info about this build failing if it's relevant in another mail)
Hi I'm new to coreboot and visiting briefly, I'm replying to this error because it looks like a systems error rather than a coreboot error, at first glance.
"permission denied" during any build of anything is usually from accidentally running part of the build under "sudo", and fixed with (sudo chown -R user:user .) replacing "user" with your username, to copy your parentheses syntax.
Another usual fix is to wipe the source tree and clone the repository again.
What operating system are you building on?
Le 2022-03-14 21:40, Karl Semich a écrit :
Hi I'm new to coreboot and visiting briefly, I'm replying to this error because it looks like a systems error rather than a coreboot error, at first glance.
"permission denied" during any build of anything is usually from accidentally running part of the build under "sudo", and fixed with (sudo chown -R user:user .) replacing "user" with your username, to copy your parentheses syntax.
Another usual fix is to wipe the source tree and clone the repository again.
What operating system are you building on? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Karl,
I'm under ArchLinux (Linux) but I only ran make as an unprivileged user (zwei).
I've run make manually inside the folder for GCC building and I still hit the error. [REDACTED the beginning...] make[2]: Entering directory '/home/zwei/project/opensource/coreboot/util/crossgcc/build-x86_64-elf-GCC/gcc' mkdir -p ada/bldtools/sinfo rm -f ada/bldtools/sinfo/sinfo.ads ada/bldtools/sinfo/sinfo.adb ada/bldtools/sinfo/xsinfo.adb ada/bldtools/sinfo/csinfo.adb cp -p ../../gcc-11.2.0/gcc/ada/sinfo.ads ../../gcc-11.2.0/gcc/ada/sinfo.adb ../../gcc-11.2.0/gcc/ada/xsinfo.adb ../../gcc-11.2.0/gcc/ada/csinfo.adb ada/bldtools/sinfo make[2]: cp: Permission denied make[2]: *** [../../gcc-11.2.0/gcc/ada/Make-generated.in:44: ada/sinfo.h] Error 127 make[2]: Leaving directory '/home/zwei/project/opensource/coreboot/util/crossgcc/build-x86_64-elf-GCC/gcc' make[1]: *** [Makefile:4409: all-gcc] Error 2 make[1]: Leaving directory '/home/zwei/project/opensource/coreboot/util/crossgcc/build-x86_64-elf-GCC' make: *** [Makefile:940: all] Error 2
Here is what ls shows about the permissions, manually running the command in my shell works fine.
.rw------- zwei zwei 20 KB Wed Jul 28 08:55:06 2021 ../../gcc-11.2.0/gcc/ada/csinfo.adb .rw------- zwei zwei 224 KB Wed Jul 28 08:55:06 2021 ../../gcc-11.2.0/gcc/ada/sinfo.adb .rw------- zwei zwei 530 KB Wed Jul 28 08:55:06 2021 ../../gcc-11.2.0/gcc/ada/sinfo.ads .rw------- zwei zwei 7.8 KB Wed Jul 28 08:55:06 2021 ../../gcc-11.2.0/gcc/ada/xsinfo.adb
ada/bldtools/sinfo: drwx------ zwei zwei 2 B Tue Mar 15 23:13:21 2022 . drwx------ zwei zwei 5 B Mon Mar 14 03:43:30 2022 ..
Have you any idea what should I do ? Should I run sudo make ? I've never actually have needed to do so in the past, hence I'm hesitating quite a bit.
Maybe I'll wipe the source tree as you've said and retry to build everything again.
cp -p ../../gcc-11.2.0/gcc/ada/sinfo.ads ../../gcc-11.2.0/gcc/ada/sinfo.adb ../../gcc-11.2.0/gcc/ada/xsinfo.adb ../../gcc-11.2.0/gcc/ada/csinfo.adb ada/bldtools/sinfo make[2]: cp: Permission denied make[2]: *** [../../gcc-11.2.0/gcc/ada/Make-generated.in:44: ada/sinfo.h] Error 127
Here is what ls shows about the permissions, manually running the
command in my shell works fine.
You're saying you have this experience:
$ cp -p ../../gcc-11.2.0/gcc/ada/sinfo.ads ../../gcc-11.2.0/gcc/ada/sinfo.adb ../../gcc-11.2.0/gcc/ada/xsinfo.adb ../../gcc-11.2.0/gcc/ada/csinfo.adb ada/bldtools/sinfo
$ echo $?
0
It sounds like make could be using a cp binary you do not have permission to execute, or running it in a context where it does not have permission to execute. I think "permission denied" can also mean the binary was compiled for a different system.
If I were troubleshooting your issue on my own system, I might mutate the makefile such that it spewed more information, replacing "cp" with such as: ls -l $(type -p cp) strace cp "$(@)"
where "$(@)" is the original args passed to cp.
I might also try replacing the cp binary with a wrapper script that output the diagnostic info.
A painful bandaid for such weirdnesses can be to run the make steps by hand such that make detects the outputs and skips the steps.
I'm actually pretty new to these things and mistakenly thought your issue was simple. Others may know more than me, although it doesn't yet sound like a coreboot-specific issue on your system to me, it possibly could be.
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.
Very weird issue, if anyone has an idea why it happened, my shell being used is ZSH.
Kind regards,
Lahfa Samy
cp -p ../../gcc-11.2.0/gcc/ada/sinfo.ads ../../gcc-11.2.0/gcc/ada/sinfo.adb ../../gcc-11.2.0/gcc/ada/xsinfo.adb ../../gcc-11.2.0/gcc/ada/csinfo.adb ada/bldtools/sinfo make[2]: cp: Permission denied make[2]: *** [../../gcc-11.2.0/gcc/ada/Make-generated.in:44: ada/sinfo.h] Error 127
Here is what ls shows about the permissions, manually running the command in my shell works fine.
You're saying you have this experience:
$ cp -p ../../gcc-11.2.0/gcc/ada/sinfo.ads../../gcc-11.2.0/gcc/ada/sinfo.adb ../../gcc-11.2.0/gcc/ada/xsinfo.adb ../../gcc-11.2.0/gcc/ada/csinfo.adb ada/bldtools/sinfo
$ echo $? 0
It sounds like make could be using a cp binary you do not have permission to execute, or running it in a context where it does not have permission to execute. I think "permission denied" can also mean the binary was compiled for a different system.
If I were troubleshooting your issue on my own system, I might mutate the makefile such that it spewed more information, replacing "cp" with such as: ls -l $(type -p cp) strace cp "$(@)"
where "$(@)" is the original args passed to cp.
I might also try replacing the cp binary with a wrapper script that output the diagnostic info.
A painful bandaid for such weirdnesses can be to run the make steps by hand such that make detects the outputs and skips the steps.
I'm actually pretty new to these things and mistakenly thought your issue was simple. Others may know more than me, although it doesn't yet sound like a coreboot-specific issue on your system to me, it possibly could be. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Fri, Mar 18, 2022, 10:56 AM Lahfa Samy samy@lahfa.xyz 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.
Very weird issue, if anyone has an idea why it happened, my shell being used is ZSH.
I was able to reproduce your error with:
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.
Kind regards,
Lahfa Samy
cp -p ../../gcc-11.2.0/gcc/ada/sinfo.ads ../../gcc-11.2.0/gcc/ada/sinfo.adb ../../gcc-11.2.0/gcc/ada/xsinfo.adb ../../gcc-11.2.0/gcc/ada/csinfo.adb ada/bldtools/sinfo make[2]: cp: Permission denied make[2]: *** [../../gcc-11.2.0/gcc/ada/Make-generated.in:44: ada/sinfo.h] Error 127
Hi again,
I reported it as a bug: https://savannah.gnu.org/bugs/?62200 but someone answered it as not-a-bug status, I'm not too sure what to do he doesn't propose a solution but just further discussions about the issue.
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
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
-
Karl Semich -
Lahfa Samy -
Peter Stuge