NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
36,523 Commits 5 Branches 387 Tags 141 MiB
Makefile 64%
Python 15.3%
C 9.2%
Shell 6%
PHP 2.8%
Other 2.4%
b291525ac7
Go to file
Thomas Petazzoni b291525ac7 toolchain: replace absolute symlinks by relative symlinks during sysroot copy 
In commit 32bec8ee2f
("toolchain-external: copy ld*.so* for all C libraries") we changed
how the musl dynamic linker symbolic link was being created. Instead
of having specific logic in Buildroot, we switched to simply copying
the ld*.so.* symbolic link from staging to target, as well as the
target of this symbolic link.

However, it turns out that by default, musl creates its dynamic linker
symbolic link with an absolute path as the target of the link:
/lib/libc.so.

Therefore, external Musl toolchains built with Buildroot look like
this:

  lrwxrwxrwx 1 thomas thomas      12 Jul  4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so

The principle of the copy_toolchain_lib_root function, which is used
to copy libraries from staging to target, is to copy symbolic links
and follow their targets. In this case, it means we end up copying
/lib/libc.so (from the host machine) into the target folder. From
there on, there are two cases:

 1. /lib/libc.so exists in your host system. It gets copied to the
    target. But later on, Buildroot also copies /lib/libc.so from
    staging to target, overwriting the bogus libc.so. So everything
    works fine, even though it's admittedly ugly.

 2. /lib/libc.so doesn't exist in your host system. In this case, the
    build fails with no clear error message.

This problem does not happen with Musl toolchains built by
Crosstool-NG, because Crosstool-NG replaces the absolute target of the
dynamic linker symbolic link by a relative path.

However, since we want to support existing Buildroot Musl toolchains
and generally work with the fact that Musl by default installs an
absolute symlink, the following commit improves the
copy_toolchain_sysroot function to replace symbolic links with an
absolute destination to use a relative destination. I.e, in staging,
the ld-musl-armhf.so.1 symbolic link looks like this:

lrwxrwxrwx 1 thomas thomas 14 Jul  5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so

Fixes:

  http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-05 23:19:53 +02:00
arch
board board: Add nanopi-m1 Support 2017-07-05 18:15:54 +02:00
boot grub2: install in $(HOST_DIR) instead of $(HOST_DIR)/usr 2017-07-05 16:06:47 +02:00
configs board: Add nanopi-m1 Support 2017-07-05 18:15:54 +02:00
docs manual: remove references to host/usr paths 2017-07-05 16:06:28 +02:00
fs Globally replace $(HOST_DIR)/usr/share with $(HOST_DIR)/share 2017-07-05 15:21:31 +02:00
linux linux: bump default version to 4.11.9 2017-07-05 20:23:54 +02:00
package xvisor: fix build on AArch64 2017-07-05 22:30:55 +02:00
support check-host-rpath: no longer allow $(HOST_DIR)/usr 2017-07-05 16:54:12 +02:00
system package/ifupdown-scripts: new package 2017-07-04 23:38:18 +02:00
toolchain toolchain: replace absolute symlinks by relative symlinks during sysroot copy 2017-07-05 23:19:53 +02:00
utils utils/brmake: print the error code of the build 2017-07-05 00:15:05 +02:00
.defconfig
.gitignore
.gitlab-ci.yml board: Add nanopi-m1 Support 2017-07-05 18:15:54 +02:00
.gitlab-ci.yml.in .gitlab-ci.yml: use the Buildroot CI image published on Docker Hub 2017-07-02 23:45:27 +02:00
CHANGES CHANGES: update with removal of $(HOST_DIR)/usr 2017-07-05 16:54:21 +02:00
Config.in Config.in: add BR2_HOST_GCC_AT_LEAST_7 2017-07-05 16:20:27 +02:00
Config.in.legacy package/mke2img: remove package 2017-07-05 00:54:01 +02:00
COPYING
DEVELOPERS DEVELOPERS: Add Adrian Perez de Castro for webkitgtk 2017-07-05 20:20:26 +02:00
Makefile legal-info: add hash for our own license file 2017-07-05 16:31:40 +02:00
Makefile.legacy
README

README 

Buildroot is a simple, efficient and easy-to-use tool to generate embedded
Linux systems through cross-compilation.

The documentation can be found in docs/manual. You can generate a text
document with 'make manual-text' and read output/docs/manual/manual.text.
Online documentation can be found at http://buildroot.org/docs.html

To build and use the buildroot stuff, do the following:

1) run 'make menuconfig'
2) select the target architecture and the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) find the kernel, bootloader, root filesystem, etc. in output/images

You do not need to be root to build or run buildroot.  Have fun!

Buildroot comes with a basic configuration for a number of boards. Run
'make list-defconfigs' to view the list of provided configurations.

Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: buildroot@buildroot.org
You can also find us on #buildroot on Freenode IRC.

If you would like to contribute patches, please read
https://buildroot.org/manual.html#submitting-patches