toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
From: Thomas De Schampheleire <[email protected]>
Currently, following symbolic links are created in both target and staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> lib
The decision for lib32 or lib64 is based on the target architecture configuration in buildroot (BR2_ARCH_IS_64).
In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (likewise for lib64-fp).
More generally, for external toolchains, the correct symbolic link is from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current toolchains always use either lib32 or lib64.
Feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different. Hence, these must be kept.
Fix the problem as follows:
- For internal toolchains: no functional change, but move the symlink creation from Makefile to package gcc-initial.
- For external toolchains: create a symlink creation helper in toolchain/helpers.mk, which first creates lib32->lib or lib64->lib as appropriate, and then creates ARCH_LIB_DIR->lib if that is different from lib32/lib64.
---
v9:
- remove redundant mkdir's (handled by skeleton) (Yann) v8:
- use helper only for external toolchain and incorporate ARCH_LIB_DIR definition (Arnout)
- keep lib32/lib64->lib symlink anyway
v7: rebase
v6: rebase only
v5:
- move internal toolchain logic into gcc-initial.mk
- also silence the internal toolchain link steps with $(Q) v4:
- merge both helpers into one
- remove the separate target for the internal toolchain and hook into gcc-initial
- re-add deleted comment about MIPS64/n32
v3:
- update commit message wrapping
- change dependency on $(BUILD_DIR) to a order-only dependency v2:
- fix 'lib32-fp' leftover in toolchain-buildroot
- silence commands creating symlink with $(Q)
- fix case where ARCH_LIB_DIR is 'lib'
Note: in output/staging/usr/ there would still be more directories than I think are really necessary. This behavior is not changed by this patch, it was already present before.
For example, with the mentioned Octeon III toolchain, output/staging/usr/ contains:
bin bin32 bin32-fp bin64-fp,
lib lib32-fp lib64-fp
libexec libexec32 libexec32-fp libexec64-fp
sbin sbin32 sbin32-fp sbin64-fpwhere bin/lib/libexec/sbin seem to be the 64-bit equivalents of bin32/lib32/libexec32/sbin32.
This is related to the behavior of copy_toolchain_sysroot in toolchain/helpers.mk. It already attempts to filter out lib32 and lib64, but does not care about any bin/sbin/libexec directories, nor about such names as lib32-fp.
As the behavior is not changed by this patch, and as I'm not fully aware about which directories are really needed in all cases, I am not touching this area.
--- Makefile | 8 -------- package/gcc/gcc-initial/gcc-initial.mk | 12 +++++++++++ package/skeleton/skeleton.mk | 4 ---- toolchain/helpers.mk | 23 ++++++++++++++++++++++ toolchain/toolchain-external/toolchain-external.mk | 10 ++++++++++ 5 files changed, 45 insertions(+), 12 deletions(-)
Makefile +0 -8
@@ -448,14 +448,6 @@ world: target-post-image $(BUILD_DIR) $(TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST): @mkdir -p $@ -# We make a symlink lib32->lib or lib64->lib as appropriate -# MIPS64/n32 requires lib32 even though it's a 64-bit arch. -ifeq ($(BR2_ARCH_IS_64)$(BR2_MIPS_NABI32),y) -LIB_SYMLINK = lib64 -else -LIB_SYMLINK = lib32 -endif - # Populating the staging with the base directories is handled by the skeleton package $(STAGING_DIR): @mkdir -p $(STAGING_DIR)
package/gcc/gcc-initial/gcc-initial.mk +12 -0
@@ -64,4 +64,16 @@ HOST_GCC_INITIAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_A HOST_GCC_INITIAL_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS +# The creation of lib32/lib64 symlinks into target and staging directories +# needs to be done before the C library is installed. Hooking into the libc +# hooks directly is tricky because there are multiple C libraries supported. +# Instead, hook into the install step of host-gcc-initial. +define HOST_GCC_INITIAL_CREATE_STAGING_TARGET_SYMLINK + $(Q)ln -snf lib $(STAGING_DIR)/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(STAGING_DIR)/usr/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(TARGET_DIR)/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(TARGET_DIR)/usr/$(TOOLCHAIN_LIB_SYMLINK) +endef +HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INITIAL_CREATE_STAGING_TARGET_SYMLINK + $(eval $(host-autotools-package))
package/skeleton/skeleton.mk +0 -4
@@ -82,8 +82,6 @@ define SKELETON_INSTALL_TARGET_CMDS --chmod=u=rwX,go=rX --exclude .empty --exclude '*~' \ $(SKELETON_PATH)/ $(TARGET_DIR)/ $(call SKELETON_USR_SYMLINKS_OR_DIRS,$(TARGET_DIR)) - ln -snf lib $(TARGET_DIR)/$(LIB_SYMLINK) - ln -snf lib $(TARGET_DIR)/usr/$(LIB_SYMLINK) $(INSTALL) -m 0644 support/misc/target-dir-warning.txt \ $(TARGET_DIR_WARNING_FILE) endef
@@ -99,8 +97,6 @@ define SKELETON_INSTALL_STAGING_CMDS $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/sbin $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include $(call SKELETON_USR_SYMLINKS_OR_DIRS,$(STAGING_DIR)) - ln -snf lib $(STAGING_DIR)/$(LIB_SYMLINK) - ln -snf lib $(STAGING_DIR)/usr/$(LIB_SYMLINK) endef SKELETON_TARGET_GENERIC_HOSTNAME = $(call qstrip,$(BR2_TARGET_GENERIC_HOSTNAME))
toolchain/helpers.mk +23 -0
@@ -1,5 +1,28 @@ # This Makefile fragment declares toolchain related helper functions. +# Create the necessary symlink from (usr/)lib32|lib64|lib32-fp|... to lib +# In general, for external toolchains, the correct link name is $ARCH_LIB_DIR. +# However, there are some broken packages that expect lib32/lib64 anyway. +# Therefore, create lib32->lib or lib64->lib (as appropriate) and additionally +# $(ARCH_LIB_DIR)->lib. +# +# MIPS64/n32 requires lib32 even though it's a 64-bit arch. +ifeq ($(BR2_ARCH_IS_64)$(BR2_MIPS_NABI32),y) +TOOLCHAIN_LIB_SYMLINK = lib64 +else +TOOLCHAIN_LIB_SYMLINK = lib32 +endif +# $1: destination directory (TARGET_DIR / STAGING_DIR) +create_lib_symlinks = \ + DESTDIR="$(strip $1)" ; \ + ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \ + ln -snf lib "$${DESTDIR}/$(TOOLCHAIN_LIB_SYMLINK)" ; \ + ln -snf lib "$${DESTDIR}/usr/$(TOOLCHAIN_LIB_SYMLINK)" ; \ + if [ "$${ARCH_LIB_DIR}" != "lib" -a "$${ARCH_LIB_DIR}" != "$(TOOLCHAIN_LIB_SYMLINK)" ]; then \ + ln -snf lib "$${DESTDIR}/$${ARCH_LIB_DIR}" ; \ + ln -snf lib "$${DESTDIR}/usr/$${ARCH_LIB_DIR}" ; \ + fi + # The copy_toolchain_lib_root function copies a toolchain library and # its symbolic links from the sysroot directory to the target # directory. Note that this function is used both by the external
toolchain/toolchain-external/toolchain-external.mk +10 -0
@@ -689,6 +689,14 @@ define TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS $(call copy_toolchain_sysroot,$${SYSROOT_DIR},$${ARCH_SYSROOT_DIR},$${ARCH_SUBDIR},$${ARCH_LIB_DIR},$${SUPPORT_LIB_DIR}) endef +define TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK + $(call create_lib_symlinks,$(STAGING_DIR)) +endef + +define TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK + $(call create_lib_symlinks,$(TARGET_DIR)) +endef + # Special installation target used on the Blackfin architecture when # FDPIC is not the primary binary format being used, but the user has # nonetheless requested the installation of the FDPIC libraries to the
@@ -803,6 +811,7 @@ endef TOOLCHAIN_EXTERNAL_BUILD_CMDS = $(TOOLCHAIN_BUILD_WRAPPER) define TOOLCHAIN_EXTERNAL_INSTALL_STAGING_CMDS + $(TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK) $(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER) $(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)
@@ -812,6 +821,7 @@ endef # and the target directory, we do everything within the # install-staging step, arbitrarily. define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_CMDS + $(TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK) $(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT)
Signature · 1 line
1.9.5
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 219 lines · Thomas De Schampheleire
From: Thomas De Schampheleire <[email protected]>
Currently, following symbolic links are created in both target and staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> libThe decision for lib32 or lib64 is based on the target architecture configuration in buildroot (
BR2_ARCH_IS_64).In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in
BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (likewise for lib64-fp).More generally, for external toolchains, the correct symbolic link is from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current toolchains always use either lib32 or lib64.
Feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if
ARCH_LIB_DIRis different. Hence, these must be kept.Fix the problem as follows:
- For internal toolchains: no functional change, but move the symlink creation fromMakefileto package gcc-initial.
- For external toolchains: create a symlink creation helper intoolchain/helpers.mk, which first createslib32->liborlib64->libas appropriate, and then createsARCH_LIB_DIR->libif that is different from lib32/lib64.Signed-off-by Thomas De Schampheleire <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Arnout Vandecappelle <[email protected]>Cc "Yann E. Morin" <[email protected]>---
v9:
- remove redundant mkdir's (handled by skeleton) (Yann) v8:
- use helper only for external toolchain and incorporateARCH_LIB_DIRdefinition (Arnout)
- keep lib32/lib64->lib symlink anyway
v7: rebase
v6: rebase only
v5:
- move internal toolchain logic into gcc-initial.mk
- also silence the internal toolchain link steps with $(Q) v4:
- merge both helpers into one
- remove the separate target for the internal toolchain and hook into gcc-initial
- re-add deleted comment about MIPS64/n32
v3:
- update commit message wrapping
- change dependency on $(BUILD_DIR) to a order-only dependency v2:
- fix 'lib32-fp' leftover in toolchain-buildroot
- silence commands creating symlink with $(Q)
- fix case whereARCH_LIB_DIRis 'lib'Note: in output/staging/usr/ there would still be more directories than I think are really necessary. This behavior is not changed by this patch, it was already present before.
For example, with the mentioned Octeon III toolchain, output/staging/usr/ contains:bin bin32 bin32-fp bin64-fp, lib lib32-fp lib64-fp libexec libexec32 libexec32-fp libexec64-fp sbin sbin32 sbin32-fp sbin64-fpwhere bin/lib/libexec/sbin seem to be the 64-bit equivalents of bin32/lib32/libexec32/sbin32.
This is related to the behavior ofcopy_toolchain_sysrootintoolchain/helpers.mk. It already attempts to filter out lib32 and lib64, but does not care about any bin/sbin/libexec directories, nor about such names as lib32-fp.
As the behavior is not changed by this patch, and as I'm not fully aware about which directories are really needed in all cases, I am not touching this area.--- Makefile | 8 -------- package/gcc/gcc-initial/gcc-initial.mk | 12 +++++++++++ package/skeleton/skeleton.mk | 4 ---- toolchain/helpers.mk | 23 ++++++++++++++++++++++ toolchain/toolchain-external/toolchain-external.mk | 10 ++++++++++ 5 files changed, 45 insertions(+), 12 deletions(-)Makefile +0
-8@@ -448,14 +448,6 @@ world: target-post-image $(BUILD_DIR) $(TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST): @mkdir -p $@ -# We make a symlink lib32->lib or lib64->lib as appropriate -# MIPS64/n32 requires lib32 even though it's a 64-bit arch. -ifeq ($(BR2_ARCH_IS_64)$(BR2_MIPS_NABI32),y) -LIB_SYMLINK = lib64 -else -LIB_SYMLINK = lib32 -endif - # Populating the staging with the base directories is handled by the skeleton package $(STAGING_DIR): @mkdir -p $(STAGING_DIR)package/gcc/gcc-initial/gcc-initial.mk +12
-0@@ -64,4 +64,16 @@ HOST_GCC_INITIAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_A HOST_GCC_INITIAL_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS +# The creation of lib32/lib64 symlinks into target and staging directories +# needs to be done before the C library is installed. Hooking into the libc +# hooks directly is tricky because there are multiple C libraries supported. +# Instead, hook into the install step of host-gcc-initial. +define HOST_GCC_INITIAL_CREATE_STAGING_TARGET_SYMLINK + $(Q)ln -snf lib $(STAGING_DIR)/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(STAGING_DIR)/usr/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(TARGET_DIR)/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(TARGET_DIR)/usr/$(TOOLCHAIN_LIB_SYMLINK) +endef +HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INITIAL_CREATE_STAGING_TARGET_SYMLINK + $(eval $(host-autotools-package))package/skeleton/skeleton.mk +0
-4@@ -82,8 +82,6 @@ define SKELETON_INSTALL_TARGET_CMDS --chmod=u=rwX,go=rX --exclude .empty --exclude '*~' \ $(SKELETON_PATH)/ $(TARGET_DIR)/ $(call SKELETON_USR_SYMLINKS_OR_DIRS,$(TARGET_DIR)) - ln -snf lib $(TARGET_DIR)/$(LIB_SYMLINK) - ln -snf lib $(TARGET_DIR)/usr/$(LIB_SYMLINK) $(INSTALL) -m 0644 support/misc/target-dir-warning.txt \ $(TARGET_DIR_WARNING_FILE) endef@@ -99,8 +97,6 @@ define SKELETON_INSTALL_STAGING_CMDS $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/sbin $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include $(call SKELETON_USR_SYMLINKS_OR_DIRS,$(STAGING_DIR)) - ln -snf lib $(STAGING_DIR)/$(LIB_SYMLINK) - ln -snf lib $(STAGING_DIR)/usr/$(LIB_SYMLINK) endef SKELETON_TARGET_GENERIC_HOSTNAME = $(call qstrip,$(BR2_TARGET_GENERIC_HOSTNAME))toolchain/helpers.mk +23
-0@@ -1,5 +1,28 @@ # This Makefile fragment declares toolchain related helper functions. +# Create the necessary symlink from (usr/)lib32|lib64|lib32-fp|... to lib +# In general, for external toolchains, the correct link name is $ARCH_LIB_DIR. +# However, there are some broken packages that expect lib32/lib64 anyway. +# Therefore, create lib32->lib or lib64->lib (as appropriate) and additionally +# $(ARCH_LIB_DIR)->lib. +# +# MIPS64/n32 requires lib32 even though it's a 64-bit arch. +ifeq ($(BR2_ARCH_IS_64)$(BR2_MIPS_NABI32),y) +TOOLCHAIN_LIB_SYMLINK = lib64 +else +TOOLCHAIN_LIB_SYMLINK = lib32 +endif +# $1: destination directory (TARGET_DIR / STAGING_DIR) +create_lib_symlinks = \ + DESTDIR="$(strip $1)" ; \ + ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \ + ln -snf lib "$${DESTDIR}/$(TOOLCHAIN_LIB_SYMLINK)" ; \ + ln -snf lib "$${DESTDIR}/usr/$(TOOLCHAIN_LIB_SYMLINK)" ; \ + if [ "$${ARCH_LIB_DIR}" != "lib" -a "$${ARCH_LIB_DIR}" != "$(TOOLCHAIN_LIB_SYMLINK)" ]; then \ + ln -snf lib "$${DESTDIR}/$${ARCH_LIB_DIR}" ; \ + ln -snf lib "$${DESTDIR}/usr/$${ARCH_LIB_DIR}" ; \ + fi + # The copy_toolchain_lib_root function copies a toolchain library and # its symbolic links from the sysroot directory to the target # directory. Note that this function is used both by the externaltoolchain/toolchain-external/toolchain-external.mk +10
-1@@ -689,6 +689,14 @@ define TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS $(call copy_toolchain_sysroot,$${SYSROOT_DIR},$${ARCH_SYSROOT_DIR},$${ARCH_SUBDIR},$${ARCH_LIB_DIR},$${SUPPORT_LIB_DIR}) endef +define TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK + $(call create_lib_symlinks,$(STAGING_DIR)) +endef + +define TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK + $(call create_lib_symlinks,$(TARGET_DIR)) +endef + # Special installation target used on the Blackfin architecture when # FDPIC is not the primary binary format being used, but the user has # nonetheless requested the installation of the FDPIC libraries to the@@ -803,6 +811,7 @@ endef TOOLCHAIN_EXTERNAL_BUILD_CMDS = $(TOOLCHAIN_BUILD_WRAPPER) define TOOLCHAIN_EXTERNAL_INSTALL_STAGING_CMDS + $(TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK) $(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER) $(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)@@ -812,6 +821,7 @@ endef # and the target directory, we do everything within the # install-staging step, arbitrarily. define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_CMDS + $(TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK) $(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT) --
Quoted 2 lines
1.9.5
bump
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
In reply to Thomas De SchampheleireHi Thomas, All,
Le 22/12/2015 13:35, Thomas De Schampheleire a ?crit :
Quoted 23 lines
From: Thomas De Schampheleire <[email protected]>
Currently, following symbolic links are created in both target and staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> libThe decision for lib32 or lib64 is based on the target architecture configuration in buildroot (
BR2_ARCH_IS_64).In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in
BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (likewise for lib64-fp).More generally, for external toolchains, the correct symbolic link is from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current toolchains always use either lib32 or lib64.
Feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if
ARCH_LIB_DIRis different. Hence, these must be kept.
Quoted 7 lines
Fix the problem as follows:
- For internal toolchains: no functional change, but move the symlink creation fromMakefileto package gcc-initial.
- For external toolchains: create a symlink creation helper intoolchain/helpers.mk, which first createslib32->liborlib64->libas appropriate, and then createsARCH_LIB_DIR->libif that is different from lib32/lib64.
Not so related to your patch though...
I reviewed some patches about x32 and ilp32 toolchains support and it seems that we need to handle at least two more weird libraries location: libx32 and libilp32. Each of these series try to define LIB_SYMLINK with their own specific value (libilp32 and libx32).
See:
x86-64 x32 ABI:
http://patchwork.ozlabs.org/patch/561904/
aarch64 ilp32 ABI:
http://patchwork.ozlabs.org/patch/506803/
http://patchwork.ozlabs.org/patch/506800/
http://patchwork.ozlabs.org/patch/506801/
In your patch, I like create_lib_symlinks helper function which avoid to define TOOLCHAIN_LIB_SYMLINK with a different value than lib32 and lib64. Instead we rely on the ARCH_LIB_DIR returned by the arch-sysroot to create additional symlinks with the correct name.
Obviously, we need to adjust the sed "magic" in toolchain_find_libdir and toolchain_find_sysroot for libilp32 and libx32 but we can do that in a followup patch series.
So, I think this patch make it easier to add the support of theses specific toolchains:
Best regards,
Romain
Quoted 189 lines
Signed-off-by Thomas De Schampheleire <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Arnout Vandecappelle <[email protected]>Cc "Yann E. Morin" <[email protected]>---
v9:
- remove redundant mkdir's (handled by skeleton) (Yann) v8:
- use helper only for external toolchain and incorporateARCH_LIB_DIRdefinition (Arnout)
- keep lib32/lib64->lib symlink anyway
v7: rebase
v6: rebase only
v5:
- move internal toolchain logic into gcc-initial.mk
- also silence the internal toolchain link steps with $(Q) v4:
- merge both helpers into one
- remove the separate target for the internal toolchain and hook into gcc-initial
- re-add deleted comment about MIPS64/n32
v3:
- update commit message wrapping
- change dependency on $(BUILD_DIR) to a order-only dependency v2:
- fix 'lib32-fp' leftover in toolchain-buildroot
- silence commands creating symlink with $(Q)
- fix case whereARCH_LIB_DIRis 'lib'Note: in output/staging/usr/ there would still be more directories than I think are really necessary. This behavior is not changed by this patch, it was already present before.
For example, with the mentioned Octeon III toolchain, output/staging/usr/ contains:bin bin32 bin32-fp bin64-fp, lib lib32-fp lib64-fp libexec libexec32 libexec32-fp libexec64-fp sbin sbin32 sbin32-fp sbin64-fpwhere bin/lib/libexec/sbin seem to be the 64-bit equivalents of bin32/lib32/libexec32/sbin32.
This is related to the behavior ofcopy_toolchain_sysrootintoolchain/helpers.mk. It already attempts to filter out lib32 and lib64, but does not care about any bin/sbin/libexec directories, nor about such names as lib32-fp.
As the behavior is not changed by this patch, and as I'm not fully aware about which directories are really needed in all cases, I am not touching this area.--- Makefile | 8 -------- package/gcc/gcc-initial/gcc-initial.mk | 12 +++++++++++ package/skeleton/skeleton.mk | 4 ---- toolchain/helpers.mk | 23 ++++++++++++++++++++++ toolchain/toolchain-external/toolchain-external.mk | 10 ++++++++++ 5 files changed, 45 insertions(+), 12 deletions(-)Makefile +0
-8@@ -448,14 +448,6 @@ world: target-post-image $(BUILD_DIR) $(TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST): @mkdir -p $@ -# We make a symlink lib32->lib or lib64->lib as appropriate -# MIPS64/n32 requires lib32 even though it's a 64-bit arch. -ifeq ($(BR2_ARCH_IS_64)$(BR2_MIPS_NABI32),y) -LIB_SYMLINK = lib64 -else -LIB_SYMLINK = lib32 -endif - # Populating the staging with the base directories is handled by the skeleton package $(STAGING_DIR): @mkdir -p $(STAGING_DIR)package/gcc/gcc-initial/gcc-initial.mk +12
-0@@ -64,4 +64,16 @@ HOST_GCC_INITIAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_A HOST_GCC_INITIAL_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS +# The creation of lib32/lib64 symlinks into target and staging directories +# needs to be done before the C library is installed. Hooking into the libc +# hooks directly is tricky because there are multiple C libraries supported. +# Instead, hook into the install step of host-gcc-initial. +define HOST_GCC_INITIAL_CREATE_STAGING_TARGET_SYMLINK + $(Q)ln -snf lib $(STAGING_DIR)/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(STAGING_DIR)/usr/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(TARGET_DIR)/$(TOOLCHAIN_LIB_SYMLINK) + $(Q)ln -snf lib $(TARGET_DIR)/usr/$(TOOLCHAIN_LIB_SYMLINK) +endef +HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INITIAL_CREATE_STAGING_TARGET_SYMLINK + $(eval $(host-autotools-package))package/skeleton/skeleton.mk +0
-4@@ -82,8 +82,6 @@ define SKELETON_INSTALL_TARGET_CMDS --chmod=u=rwX,go=rX --exclude .empty --exclude '*~' \ $(SKELETON_PATH)/ $(TARGET_DIR)/ $(call SKELETON_USR_SYMLINKS_OR_DIRS,$(TARGET_DIR)) - ln -snf lib $(TARGET_DIR)/$(LIB_SYMLINK) - ln -snf lib $(TARGET_DIR)/usr/$(LIB_SYMLINK) $(INSTALL) -m 0644 support/misc/target-dir-warning.txt \ $(TARGET_DIR_WARNING_FILE) endef@@ -99,8 +97,6 @@ define SKELETON_INSTALL_STAGING_CMDS $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/sbin $(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include $(call SKELETON_USR_SYMLINKS_OR_DIRS,$(STAGING_DIR)) - ln -snf lib $(STAGING_DIR)/$(LIB_SYMLINK) - ln -snf lib $(STAGING_DIR)/usr/$(LIB_SYMLINK) endef SKELETON_TARGET_GENERIC_HOSTNAME = $(call qstrip,$(BR2_TARGET_GENERIC_HOSTNAME))toolchain/helpers.mk +23
-0@@ -1,5 +1,28 @@ # This Makefile fragment declares toolchain related helper functions. +# Create the necessary symlink from (usr/)lib32|lib64|lib32-fp|... to lib +# In general, for external toolchains, the correct link name is $ARCH_LIB_DIR. +# However, there are some broken packages that expect lib32/lib64 anyway. +# Therefore, create lib32->lib or lib64->lib (as appropriate) and additionally +# $(ARCH_LIB_DIR)->lib. +# +# MIPS64/n32 requires lib32 even though it's a 64-bit arch. +ifeq ($(BR2_ARCH_IS_64)$(BR2_MIPS_NABI32),y) +TOOLCHAIN_LIB_SYMLINK = lib64 +else +TOOLCHAIN_LIB_SYMLINK = lib32 +endif +# $1: destination directory (TARGET_DIR / STAGING_DIR) +create_lib_symlinks = \ + DESTDIR="$(strip $1)" ; \ + ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \ + ln -snf lib "$${DESTDIR}/$(TOOLCHAIN_LIB_SYMLINK)" ; \ + ln -snf lib "$${DESTDIR}/usr/$(TOOLCHAIN_LIB_SYMLINK)" ; \ + if [ "$${ARCH_LIB_DIR}" != "lib" -a "$${ARCH_LIB_DIR}" != "$(TOOLCHAIN_LIB_SYMLINK)" ]; then \ + ln -snf lib "$${DESTDIR}/$${ARCH_LIB_DIR}" ; \ + ln -snf lib "$${DESTDIR}/usr/$${ARCH_LIB_DIR}" ; \ + fi + # The copy_toolchain_lib_root function copies a toolchain library and # its symbolic links from the sysroot directory to the target # directory. Note that this function is used both by the externaltoolchain/toolchain-external/toolchain-external.mk +10
-0@@ -689,6 +689,14 @@ define TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS $(call copy_toolchain_sysroot,$${SYSROOT_DIR},$${ARCH_SYSROOT_DIR},$${ARCH_SUBDIR},$${ARCH_LIB_DIR},$${SUPPORT_LIB_DIR}) endef +define TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK + $(call create_lib_symlinks,$(STAGING_DIR)) +endef + +define TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK + $(call create_lib_symlinks,$(TARGET_DIR)) +endef + # Special installation target used on the Blackfin architecture when # FDPIC is not the primary binary format being used, but the user has # nonetheless requested the installation of the FDPIC libraries to the@@ -803,6 +811,7 @@ endef TOOLCHAIN_EXTERNAL_BUILD_CMDS = $(TOOLCHAIN_BUILD_WRAPPER) define TOOLCHAIN_EXTERNAL_INSTALL_STAGING_CMDS + $(TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK) $(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER) $(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)@@ -812,6 +821,7 @@ endef # and the target directory, we do everything within the # install-staging step, arbitrarily. define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_CMDS + $(TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK) $(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT)
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 54 lines · Romain Naour
Hi Thomas, All,
Le 22/12/2015 13:35, Thomas De Schampheleire a ?crit :
Quoted 23 lines
From: Thomas De Schampheleire <[email protected]>
Currently, following symbolic links are created in both target and staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> libThe decision for lib32 or lib64 is based on the target architecture configuration in buildroot (
BR2_ARCH_IS_64).In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in
BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (likewise for lib64-fp).More generally, for external toolchains, the correct symbolic link is from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current toolchains always use either lib32 or lib64.
Feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if
ARCH_LIB_DIRis different. Hence, these must be kept.Quoted 7 lines
Fix the problem as follows:
- For internal toolchains: no functional change, but move the symlink creation fromMakefileto package gcc-initial.
- For external toolchains: create a symlink creation helper intoolchain/helpers.mk, which first createslib32->liborlib64->libas appropriate, and then createsARCH_LIB_DIR->libif that is different from lib32/lib64.Not so related to your patch though...
I reviewed some patches about x32 and ilp32 toolchains support and it seems that we need to handle at least two more weird libraries location: libx32 and libilp32. Each of these series try to defineLIB_SYMLINKwith their own specific value (libilp32 and libx32).See:
x86-64 x32 ABI:
http://patchwork.ozlabs.org/patch/561904/aarch64 ilp32 ABI:
http://patchwork.ozlabs.org/patch/506803/
http://patchwork.ozlabs.org/patch/506800/
http://patchwork.ozlabs.org/patch/506801/In your patch, I like
create_lib_symlinkshelper function which avoid to defineTOOLCHAIN_LIB_SYMLINKwith a different value than lib32 and lib64. Instead we rely on theARCH_LIB_DIRreturned by the arch-sysroot to create additional symlinks with the correct name.
Quoted 9 lines
Obviously, we need to adjust the sed "magic" in
toolchain_find_libdirandtoolchain_find_sysrootfor libilp32 and libx32 but we can do that in a followup patch series.So, I think this patch make it easier to add the support of theses specific toolchains:
Reviewed-by Romain Naour <[email protected]>
Thank you, Romain.
With the upcoming Febuary stabilization month and subsequent release, I would like to kindly ask (almost beg, really) that this patch be included in the release. I know that toolchain patches are not sexy, but they are important. This patch has been around for a very long time, and the associated rebasing and retesting on my part is time-consuming and very demotivating.
Thanks,
Thomas
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
In reply to Thomas De SchampheleireThomas,
Quoted 21 lines · Thomas De Schampheleire
Currently, following symbolic links are created in both target and staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> libThe decision for lib32 or lib64 is based on the target architecture configuration in buildroot (
BR2_ARCH_IS_64).In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in
BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (likewise for lib64-fp).More generally, for external toolchains, the correct symbolic link is from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current toolchains always use either lib32 or lib64.
Feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if
ARCH_LIB_DIRis different. Hence, these must be kept.
Quoted 7 lines
Fix the problem as follows:
- For internal toolchains: no functional change, but move the symlink creation fromMakefileto package gcc-initial.
- For external toolchains: create a symlink creation helper intoolchain/helpers.mk, which first createslib32->liborlib64->libas appropriate, and then createsARCH_LIB_DIR->libif that is different from lib32/lib64.
I don't quite understand the benefit of duplicating the code that creates the lib32/lib64 symlinks. It used to be part of the skeleton, which ensures the code is common to all cases (i.e internal or external cases). And now with this change, you are duplicating it in the external toolchain code and the host-gcc-initial code. What's the benefit of doing this?
Unless I missed something, this patch should be simplified to leave the creation of lib32/lib64 as is (i.e in skeleton.mk), and only the external toolchain code should be changed to create the $(ARCH_LIB_DIR) symlink when needed.
Note that the move of the LIB_SYMLINK definition from the main Makefile to toolchain/helpers.mk remains a good change IMO (I like when things are removed from the main Makefile). Or it could be moved to skeleton.mk just above where it is used. But it should be a separate change.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Hi Thomas,
Thanks for your response.
Quoted 40 lines · Thomas Petazzoni
Thomas,
Quoted 21 lines · Thomas De Schampheleire
Currently, following symbolic links are created in both target and staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> libThe decision for lib32 or lib64 is based on the target architecture configuration in buildroot (
BR2_ARCH_IS_64).In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in
BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (likewise for lib64-fp).More generally, for external toolchains, the correct symbolic link is from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current toolchains always use either lib32 or lib64.
Feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if
ARCH_LIB_DIRis different. Hence, these must be kept.Quoted 7 lines
Fix the problem as follows:
- For internal toolchains: no functional change, but move the symlink creation fromMakefileto package gcc-initial.
- For external toolchains: create a symlink creation helper intoolchain/helpers.mk, which first createslib32->liborlib64->libas appropriate, and then createsARCH_LIB_DIR->libif that is different from lib32/lib64.I don't quite understand the benefit of duplicating the code that creates the lib32/lib64 symlinks. It used to be part of the skeleton, which ensures the code is common to all cases (i.e internal or external cases). And now with this change, you are duplicating it in the external toolchain code and the host-gcc-initial code. What's the benefit of doing this?
Quoted 4 lines
Unless I missed something, this patch should be simplified to leave the creation of lib32/lib64 as is (i.e in skeleton.mk), and only the external toolchain code should be changed to create the $(ARCH_LIB_DIR) symlink when needed.
In earlier versions of the patch, I stated that the symlink creation needs to happen before gcc-initial is built. This is the reason we are hooking into gcc-initial. This was also effectively the case before the skeleton package was introduced.
However, with the introduction of the skeleton package, the symlinks are (today, without my patch) created after the toolchain is built. This puzzles me, as it does not match my earlier observations and statements. Do you know if anything else has changed in this respect?
If there is no need to create the symlink at gcc-initial time, then yes this patch can be simplified.
/Thomas
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 51 lines · Thomas De Schampheleire
Hi Thomas,
Thanks for your response.
Quoted 40 lines · Thomas Petazzoni
Thomas,
Quoted 21 lines · Thomas De Schampheleire
Currently, following symbolic links are created in both target and staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> libThe decision for lib32 or lib64 is based on the target architecture configuration in buildroot (
BR2_ARCH_IS_64).In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in
BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (likewise for lib64-fp).More generally, for external toolchains, the correct symbolic link is from (usr/)${ARCH_LIB_DIR} to lib. For internal toolchains, current toolchains always use either lib32 or lib64.
Feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if
ARCH_LIB_DIRis different. Hence, these must be kept.Quoted 7 lines
Fix the problem as follows:
- For internal toolchains: no functional change, but move the symlink creation fromMakefileto package gcc-initial.
- For external toolchains: create a symlink creation helper intoolchain/helpers.mk, which first createslib32->liborlib64->libas appropriate, and then createsARCH_LIB_DIR->libif that is different from lib32/lib64.I don't quite understand the benefit of duplicating the code that creates the lib32/lib64 symlinks. It used to be part of the skeleton, which ensures the code is common to all cases (i.e internal or external cases). And now with this change, you are duplicating it in the external toolchain code and the host-gcc-initial code. What's the benefit of doing this?
Quoted 4 lines
Unless I missed something, this patch should be simplified to leave the creation of lib32/lib64 as is (i.e in skeleton.mk), and only the external toolchain code should be changed to create the $(ARCH_LIB_DIR) symlink when needed.
Quoted 4 lines
In earlier versions of the patch, I stated that the symlink creation needs to happen before gcc-initial is built. This is the reason we are hooking into gcc-initial. This was also effectively the case before the skeleton package was introduced.
Small correction, the statement is:
+# The creation of lib32/lib64 symlinks into target and staging directories +# needs to be done before the C library is installed.
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Review
Quoted 8 lines
Quoted 4 lines
In earlier versions of the patch, I stated that the symlink creation needs to happen before gcc-initial is built. This is the reason we are hooking into gcc-initial. This was also effectively the case before the skeleton package was introduced.
Small correction, the statement is:
(quoted diff) +2
-0+# The creation of lib32/lib64 symlinks into target and staging directories +# needs to be done before the C library is installed.
And that's already the case, right? E.G. all packages depend on skeleton, including the glibc/uclibc/musl packages.
E.G. from a build with an external toolchain:
1453212927:start:extract : linux 1453212938:end :extract : linux 1453212938:start:patch : linux 1453212939:end :patch : linux 1453213000:start:extract : skeleton 1453213000:end :extract : skeleton 1453213000:start:patch : skeleton 1453213000:end :patch : skeleton 1453213000:start:configure : skeleton 1453213000:end :configure : skeleton 1453213000:start:build : skeleton 1453213000:end :build : skeleton 1453213000:start:install-staging : skeleton 1453213000:end :install-staging : skeleton 1453213000:start:install-target : skeleton 1453213001:end :install-target : skeleton 1453213002:start:extract : toolchain-external
Signature · 1 line
Bye, Peter Korsgaard
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 9 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 4 lines
Quoted 4 lines
In earlier versions of the patch, I stated that the symlink creation needs to happen before gcc-initial is built. This is the reason we are hooking into gcc-initial. This was also effectively the case before the skeleton package was introduced.
Quoted 6 lines
Review
Quoted 3 lines
Small correction, the statement is:
(quoted diff) +2
-0+# The creation of lib32/lib64 symlinks into target and staging directories +# needs to be done before the C library is installed.And that's already the case, right? E.G. all packages depend on skeleton, including the glibc/uclibc/musl packages.
Ok, so that is the missing part of the puzzle.
On 2015.05, where skeleton was not yet a package, and so the situation upon which the original patch was based, the symlinks were made in the .root target. To allow for this new symlink behavior, it had to be moved, but it had to be before the C library. The toolchain target was too late, gcc-initial was voted the 'best' place at the time.
I was not aware that glibc already depends on skeleton. Then indeed ThomasP's reasoning is correct and the patch should be simplified. I will investigate that further and resubmit.
Thanks for the feedback,
Thomas
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Thomas?, Peter, All,
On 2016-01-19 17:01 +0100, Thomas De Schampheleire spake thusly:
Quoted 25 lines · Peter Korsgaard
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 4 lines
Quoted 4 lines
In earlier versions of the patch, I stated that the symlink creation needs to happen before gcc-initial is built. This is the reason we are hooking into gcc-initial. This was also effectively the case before the skeleton package was introduced.
Quoted 6 lines
Review
Quoted 3 lines
Small correction, the statement is:
(quoted diff) +2
-0+# The creation of lib32/lib64 symlinks into target and staging directories +# needs to be done before the C library is installed.And that's already the case, right? E.G. all packages depend on skeleton, including the glibc/uclibc/musl packages.
Ok, so that is the missing part of the puzzle.
On 2015.05, where skeleton was not yet a package, and so the situation upon which the original patch was based, the symlinks were made in the .root target. To allow for this new symlink behavior, it had to be moved, but it had to be before the C library. The toolchain target was too late, gcc-initial was voted the 'best' place at the time.
Quoted 3 lines
I was not aware that glibc already depends on skeleton. Then indeed ThomasP's reasoning is correct and the patch should be simplified. I will investigate that further and resubmit.
Skeleton is currently not a dependency of host-gcc-initial, so you'd have to make it so.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Hi,
Quoted 6 lines
Quoted 3 lines
I was not aware that glibc already depends on skeleton. Then indeed ThomasP's reasoning is correct and the patch should be simplified. I will investigate that further and resubmit.
Skeleton is currently not a dependency of host-gcc-initial, so you'd have to make it so.
Ahh yes, we only add it for target packages.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 5 lines · Peter Korsgaard
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Yann" == Yann E MORIN <[email protected]> writes:
Hi,
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
I was not aware that glibc already depends on skeleton. Then indeed ThomasP's reasoning is correct and the patch should be simplified. I will investigate that further and resubmit.
Skeleton is currently not a dependency of host-gcc-initial, so you'd have to make it so.
Ahh yes, we only add it for target packages.
I did 'make clean toolchain' on x86-64 qemu defconfig but with glibc, and at the end I noticed that skeleton was built and the symlinks were correctly created.
So which package had the skeleton dependency? (Don't have a buildroot near me ATM)
/Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160119/0c0999ef/attachment.html>
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Quoted 13 lines · Thomas De Schampheleire
Quoted 2 lines · On Jan 19, 2016 19:35, "Peter Korsgaard" <[email protected]…
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Yann" == Yann E MORIN <[email protected]
Quoted 7 lines · <mailto:[email protected]>> writes:
Hi,
Quoted 3 lines
Quoted 3 lines
I was not aware that glibc already depends on skeleton. Then indeed ThomasP's reasoning is correct and the patch should be simplified. I will investigate that further and resubmit.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Skeleton is currently not a dependency of host-gcc-initial, so you'd have to make it so.
Ahh yes, we only add it for target packages.
I did 'make clean toolchain' on x86-64 qemu defconfig but with glibc, and at the end I noticed that skeleton was built and the symlinks were correctly created. So which package had the skeleton dependency? (Don't have a buildroot near me ATM)
glibc is a target package so depends on skeleton (see pkg-generic.mk, search
for skeleton).
Regards,
Arnout
Quoted 10 lines
/Thomas
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
Arnout, Thomas, All,
On 2016-01-19 23:57 +0100, Arnout Vandecappelle spake thusly:
Quoted 17 lines · Thomas De Schampheleire
Quoted 16 lines
Quoted 2 lines · On Jan 19, 2016 19:35, "Peter Korsgaard" <[email protected]…
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Yann" == Yann E MORIN <[email protected]
Quoted 10 lines · <mailto:[email protected]>> writes:
Hi,
Quoted 6 lines
Quoted 3 lines
I was not aware that glibc already depends on skeleton. Then indeed ThomasP's reasoning is correct and the patch should be simplified. I will investigate that further and resubmit.
Skeleton is currently not a dependency of host-gcc-initial, so you'd have to make it so.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Ahh yes, we only add it for target packages.
I did 'make clean toolchain' on x86-64 qemu defconfig but with glibc, and at the end I noticed that skeleton was built and the symlinks were correctly created. So which package had the skeleton dependency? (Don't have a buildroot near me ATM)
glibc is a target package so depends on skeleton (see pkg-generic.mk, search
for skeleton).
And even before glibc, linux-headers is a target package. ;-)
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v9 1/1 toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
In reply to Yann E. MORINHello,
Quoted 6 lines · Yann E. MORIN
Quoted 3 lines
I was not aware that glibc already depends on skeleton. Then indeed ThomasP's reasoning is correct and the patch should be simplified. I will investigate that further and resubmit.
Skeleton is currently not a dependency of host-gcc-initial, so you'd have to make it so.
Why? As explained on IRC, the only reason why Thomas DS did create the symlinks in host-gcc-initial is to avoid duplicating this logic in all three C library packages. But the symlinks are really only needed before building/installing the C libraries, as far as I'm aware. So creating them in the skeleton is OK.
Remember: in the current situation (i.e before Thomas DS patch), the symlinks *are* created in the skeleton. And things are working fine today, right ?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com