| Summary: | musl buildroot-toolchain does not put libgcc_s.so.1 into place | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Alexander Clouter <alex+buildroot> |
| Component: | Other | Assignee: | Thomas Petazzoni <thomas.petazzoni> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | buildroot |
| Priority: | P5 | ||
| Version: | 2014.08 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
|
Description
Alexander Clouter
2014-10-26 18:25:33 UTC
This looks strange because the installation of libgcc_s.so.1 is done by the gcc-final package, and therefore should not depend on the C library being used. Here is the relevant snippet of code from gcc-final.mk:
define HOST_GCC_FINAL_INSTALL_LIBGCC
-cp -dpf $(HOST_DIR)/usr/$(GNU_TARGET_NAME)/lib*/libgcc_s* \
$(STAGING_DIR)/lib/
-cp -dpf $(HOST_DIR)/usr/$(GNU_TARGET_NAME)/lib*/libgcc_s* \
$(TARGET_DIR)/lib/
endef
HOST_GCC_FINAL_POST_INSTALL_HOOKS += HOST_GCC_FINAL_INSTALL_LIBGCC
Obviously, there is a "-" before those commands, so if the command fails for some reason, it will be ignored. Maybe that's the issue here. I'll have to reproduce and see what happens.
Thanks for the report!
Humm, I'm not able to reproduce your problem. I've built the following defconfig: test@build:~/outputs/bug7568$ cat defconfig BR2_mipsel=y BR2_TOOLCHAIN_BUILDROOT_MUSL=y And there is definitely libgcc_s.so.1 installed in the target: test@build:~/outputs/bug7568$ ls -l target/lib total 976 lrwxrwxrwx 1 test test 12 Nov 9 10:54 ld-musl-mipsel-sf.so.1 -> /lib/libc.so -rwxr-xr-x 1 test test 778344 Nov 9 10:57 libc.so lrwxrwxrwx 1 test test 13 Nov 9 10:57 libgcc_s.so -> libgcc_s.so.1 -rw-r--r-- 1 test test 216248 Nov 9 10:57 libgcc_s.so.1 Which version of Buildroot are you testing? I'm testing the latest master, as of commit 44f89c38dc72e042d8190f4ca15b26abdb7e69b4. Only tried with the 2014.08 release (fcd720dfcf702d796fbc625b9abc4c06cb848d84) as nothing stood out libgcc wise since, which actually looking again is wrong, as there was the whole move to a two stage gcc build which probably worked all of this? I'm going to do some rebuilding with newer versions and see also if it is something in my .config. I do though get the same problem with uClibc too, probably have done something silly... For reference, my full (current) config is: BR2_mipsel=y BR2_mips_32r2=y BR2_DL_DIR="$(CONFIG_DIR)/../dl" BR2_CCACHE=y BR2_CCACHE_DIR="$(CONFIG_DIR)/../ccache" BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y BR2_TOOLCHAIN_BUILDROOT_WCHAR=y # BR2_UCLIBC_INSTALL_UTILS is not set BR2_ENABLE_LOCALE_PURGE=y BR2_ENABLE_LOCALE_WHITELIST="C" BR2_TARGET_GENERIC_HOSTNAME="bratwurst" BR2_TARGET_GENERIC_ISSUE="Welcome to BRatWuRsT" BR2_INIT_NONE=y # BR2_TARGET_GENERIC_GETTY is not set # BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set BR2_ROOTFS_OVERLAY="$(CONFIG_DIR)/../overlay" BR2_ROOTFS_POST_BUILD_SCRIPT="$(BRATWURST_BOARD_DIR)/post-build.sh" BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BRATWURST_BOARD_DIR)/post-image.sh" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_SAME_AS_HEADERS=y BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BRATWURST_BOARD_DIR)/linux.config" BR2_LINUX_KERNEL_VMLINUZ=y BR2_PACKAGE_DNSMASQ=y BR2_PACKAGE_DROPBEAR=y BR2_PACKAGE_DROPBEAR_DISABLE_REVERSEDNS=y BR2_PACKAGE_PPPD=y BR2_TARGET_ROOTFS_JFFS2=y BR2_TARGET_ROOTFS_JFFS2_FLASH_64=y # BR2_TARGET_ROOTFS_TAR is not set BR2_PACKAGE_EXTERNAL_NFTABLES=y BR2_PACKAGE_LINUX_ATM=y Had the problem before adding EXTERNAL_NFTABLES/LINUX_ATM, so I doubt this is causing a problem, but if you need to, you can get those hooks at https://github.com/jimdigriz/bratwurst Okay, found the problem. Not a clean build environment, and I was using the following as a quick and dirty 'clean': http://lists.busybox.net/pipermail/buildroot/2012-September/058323.html If I distclean then build, it all works fine. Really sorry for wasting your time. (In reply to comment #5) > Okay, found the problem. > > Not a clean build environment, and I was using the following as a quick and > dirty 'clean': > > http://lists.busybox.net/pipermail/buildroot/2012-September/058323.html We always rejected merging such "tricks", specifically because they cause people to not do proper full rebuilds when necessary :-) > If I distclean then build, it all works fine. > > Really sorry for wasting your time. No problem, thanks for investigating on your side, and thanks in the first place for taking the time to report the issues you're seeing. I'm marking the bug as "worksforme". |