All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
@ 2015-12-22 12:35 Thomas De Schampheleire
  2016-01-05 12:37 ` Thomas De Schampheleire
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Thomas De Schampheleire @ 2015-12-22 12:35 UTC (permalink / raw)
  To: buildroot

From: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

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.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: "Yann E. Morin" <yann.morin.1998@free.fr>

---
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-fp

where 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(-)

diff --git a/Makefile b/Makefile
index dc657d9..63f4c54 100644
--- a/Makefile
+++ b/Makefile
@@ -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)
diff --git a/package/gcc/gcc-initial/gcc-initial.mk b/package/gcc/gcc-initial/gcc-initial.mk
index 1e58d8b..cf441ed 100644
--- a/package/gcc/gcc-initial/gcc-initial.mk
+++ b/package/gcc/gcc-initial/gcc-initial.mk
@@ -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))
diff --git a/package/skeleton/skeleton.mk b/package/skeleton/skeleton.mk
index 790afaf..b1395b5 100644
--- a/package/skeleton/skeleton.mk
+++ b/package/skeleton/skeleton.mk
@@ -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))
diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
index 1452ec6..f582ce9 100644
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk
@@ -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
diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk
index 745b685..e20268e 100644
--- a/toolchain/toolchain-external/toolchain-external.mk
+++ b/toolchain/toolchain-external/toolchain-external.mk
@@ -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)
-- 
1.9.5

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2015-12-22 12:35 [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib Thomas De Schampheleire
@ 2016-01-05 12:37 ` Thomas De Schampheleire
  2016-01-12 23:12 ` Romain Naour
  2016-01-17 14:45 ` Thomas Petazzoni
  2 siblings, 0 replies; 15+ messages in thread
From: Thomas De Schampheleire @ 2016-01-05 12:37 UTC (permalink / raw)
  To: buildroot

On Tue, Dec 22, 2015 at 1:35 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> From: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>
> 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.
>
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> Cc: "Yann E. Morin" <yann.morin.1998@free.fr>
>
> ---
> 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-fp
>
> where 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(-)
>
> diff --git a/Makefile b/Makefile
> index dc657d9..63f4c54 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -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)
> diff --git a/package/gcc/gcc-initial/gcc-initial.mk b/package/gcc/gcc-initial/gcc-initial.mk
> index 1e58d8b..cf441ed 100644
> --- a/package/gcc/gcc-initial/gcc-initial.mk
> +++ b/package/gcc/gcc-initial/gcc-initial.mk
> @@ -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))
> diff --git a/package/skeleton/skeleton.mk b/package/skeleton/skeleton.mk
> index 790afaf..b1395b5 100644
> --- a/package/skeleton/skeleton.mk
> +++ b/package/skeleton/skeleton.mk
> @@ -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))
> diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
> index 1452ec6..f582ce9 100644
> --- a/toolchain/helpers.mk
> +++ b/toolchain/helpers.mk
> @@ -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
> diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk
> index 745b685..e20268e 100644
> --- a/toolchain/toolchain-external/toolchain-external.mk
> +++ b/toolchain/toolchain-external/toolchain-external.mk
> @@ -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)
> --
> 1.9.5
>

bump

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2015-12-22 12:35 [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib Thomas De Schampheleire
  2016-01-05 12:37 ` Thomas De Schampheleire
@ 2016-01-12 23:12 ` Romain Naour
  2016-01-14 19:35   ` Thomas De Schampheleire
  2016-01-17 14:45 ` Thomas Petazzoni
  2 siblings, 1 reply; 15+ messages in thread
From: Romain Naour @ 2016-01-12 23:12 UTC (permalink / raw)
  To: buildroot

Hi Thomas, All,

Le 22/12/2015 13:35, Thomas De Schampheleire a ?crit :
> From: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> 
> 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.

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:

Reviewed-by: Romain Naour <romain.naour@gmail.com>

Best regards,
Romain

> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> Cc: "Yann E. Morin" <yann.morin.1998@free.fr>
> 
> ---
> 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-fp
> 
> where 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(-)
> 
> diff --git a/Makefile b/Makefile
> index dc657d9..63f4c54 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -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)
> diff --git a/package/gcc/gcc-initial/gcc-initial.mk b/package/gcc/gcc-initial/gcc-initial.mk
> index 1e58d8b..cf441ed 100644
> --- a/package/gcc/gcc-initial/gcc-initial.mk
> +++ b/package/gcc/gcc-initial/gcc-initial.mk
> @@ -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))
> diff --git a/package/skeleton/skeleton.mk b/package/skeleton/skeleton.mk
> index 790afaf..b1395b5 100644
> --- a/package/skeleton/skeleton.mk
> +++ b/package/skeleton/skeleton.mk
> @@ -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))
> diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
> index 1452ec6..f582ce9 100644
> --- a/toolchain/helpers.mk
> +++ b/toolchain/helpers.mk
> @@ -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
> diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk
> index 745b685..e20268e 100644
> --- a/toolchain/toolchain-external/toolchain-external.mk
> +++ b/toolchain/toolchain-external/toolchain-external.mk
> @@ -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)
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-12 23:12 ` Romain Naour
@ 2016-01-14 19:35   ` Thomas De Schampheleire
  0 siblings, 0 replies; 15+ messages in thread
From: Thomas De Schampheleire @ 2016-01-14 19:35 UTC (permalink / raw)
  To: buildroot

On Wed, Jan 13, 2016 at 12:12 AM, Romain Naour <romain.naour@gmail.com> wrote:
> Hi Thomas, All,
>
> Le 22/12/2015 13:35, Thomas De Schampheleire a ?crit :
>> From: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>>
>> 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.
>
> 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:
>
> Reviewed-by: Romain Naour <romain.naour@gmail.com>
>

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2015-12-22 12:35 [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib Thomas De Schampheleire
  2016-01-05 12:37 ` Thomas De Schampheleire
  2016-01-12 23:12 ` Romain Naour
@ 2016-01-17 14:45 ` Thomas Petazzoni
  2016-01-19 14:15   ` Thomas De Schampheleire
  2 siblings, 1 reply; 15+ messages in thread
From: Thomas Petazzoni @ 2016-01-17 14:45 UTC (permalink / raw)
  To: buildroot

Thomas,

On Tue, 22 Dec 2015 13:35:34 +0100, Thomas De Schampheleire wrote:

> 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.

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-17 14:45 ` Thomas Petazzoni
@ 2016-01-19 14:15   ` Thomas De Schampheleire
  2016-01-19 14:17     ` Thomas De Schampheleire
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas De Schampheleire @ 2016-01-19 14:15 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

Thanks for your response.

On Sun, Jan 17, 2016 at 3:45 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Thomas,
>
> On Tue, 22 Dec 2015 13:35:34 +0100, Thomas De Schampheleire wrote:
>
>> 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.
>
> 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.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 14:15   ` Thomas De Schampheleire
@ 2016-01-19 14:17     ` Thomas De Schampheleire
  2016-01-19 14:26       ` Peter Korsgaard
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas De Schampheleire @ 2016-01-19 14:17 UTC (permalink / raw)
  To: buildroot

On Tue, Jan 19, 2016 at 3:15 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Thomas,
>
> Thanks for your response.
>
> On Sun, Jan 17, 2016 at 3:45 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Thomas,
>>
>> On Tue, 22 Dec 2015 13:35:34 +0100, Thomas De Schampheleire wrote:
>>
>>> 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.
>>
>> 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.
>
> 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 14:17     ` Thomas De Schampheleire
@ 2016-01-19 14:26       ` Peter Korsgaard
  2016-01-19 16:01         ` Thomas De Schampheleire
  0 siblings, 1 reply; 15+ messages in thread
From: Peter Korsgaard @ 2016-01-19 14:26 UTC (permalink / raw)
  To: buildroot

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

>> 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.

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

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 14:26       ` Peter Korsgaard
@ 2016-01-19 16:01         ` Thomas De Schampheleire
  2016-01-19 18:29           ` Yann E. MORIN
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas De Schampheleire @ 2016-01-19 16:01 UTC (permalink / raw)
  To: buildroot

On Tue, Jan 19, 2016 at 3:26 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
>
> Hi,
>
>>> 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.
>
> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 16:01         ` Thomas De Schampheleire
@ 2016-01-19 18:29           ` Yann E. MORIN
  2016-01-19 18:35             ` Peter Korsgaard
  2016-01-19 20:03             ` Thomas Petazzoni
  0 siblings, 2 replies; 15+ messages in thread
From: Yann E. MORIN @ 2016-01-19 18:29 UTC (permalink / raw)
  To: buildroot

Thomas?, Peter, All,

On 2016-01-19 17:01 +0100, Thomas De Schampheleire spake thusly:
> On Tue, Jan 19, 2016 at 3:26 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
> >>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
> >
> > Hi,
> >
> >>> 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.
> >
> > 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.

Skeleton is currently not a dependency of host-gcc-initial, so you'd
have to make it so.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 18:29           ` Yann E. MORIN
@ 2016-01-19 18:35             ` Peter Korsgaard
  2016-01-19 19:40               ` Thomas De Schampheleire
  2016-01-19 20:03             ` Thomas Petazzoni
  1 sibling, 1 reply; 15+ messages in thread
From: Peter Korsgaard @ 2016-01-19 18:35 UTC (permalink / raw)
  To: buildroot

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

>> 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.

-- 
Venlig hilsen,
Peter Korsgaard 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 18:35             ` Peter Korsgaard
@ 2016-01-19 19:40               ` Thomas De Schampheleire
  2016-01-19 22:57                 ` Arnout Vandecappelle
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas De Schampheleire @ 2016-01-19 19:40 UTC (permalink / raw)
  To: buildroot

On Jan 19, 2016 19:35, "Peter Korsgaard" <peter@korsgaard.com> wrote:
>
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>
> Hi,
>
> >> 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>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 18:29           ` Yann E. MORIN
  2016-01-19 18:35             ` Peter Korsgaard
@ 2016-01-19 20:03             ` Thomas Petazzoni
  1 sibling, 0 replies; 15+ messages in thread
From: Thomas Petazzoni @ 2016-01-19 20:03 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 19 Jan 2016 19:29:47 +0100, Yann E. MORIN wrote:

> > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 19:40               ` Thomas De Schampheleire
@ 2016-01-19 22:57                 ` Arnout Vandecappelle
  2016-01-19 23:02                   ` Yann E. MORIN
  0 siblings, 1 reply; 15+ messages in thread
From: Arnout Vandecappelle @ 2016-01-19 22:57 UTC (permalink / raw)
  To: buildroot

On 19-01-16 20:40, Thomas De Schampheleire wrote:
> 
> On Jan 19, 2016 19:35, "Peter Korsgaard" <peter@korsgaard.com
> <mailto:peter@korsgaard.com>> wrote:
>>
>> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr
> <mailto:yann.morin.1998@free.fr>> writes:
>>
>> Hi,
>>
>> >> 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)

 glibc is a target package so depends on skeleton (see pkg-generic.mk, search
for skeleton).

 Regards,
 Arnout

> 
> /Thomas
> 
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib
  2016-01-19 22:57                 ` Arnout Vandecappelle
@ 2016-01-19 23:02                   ` Yann E. MORIN
  0 siblings, 0 replies; 15+ messages in thread
From: Yann E. MORIN @ 2016-01-19 23:02 UTC (permalink / raw)
  To: buildroot

Arnout, Thomas, All,

On 2016-01-19 23:57 +0100, Arnout Vandecappelle spake thusly:
> On 19-01-16 20:40, Thomas De Schampheleire wrote:
> > 
> > On Jan 19, 2016 19:35, "Peter Korsgaard" <peter@korsgaard.com
> > <mailto:peter@korsgaard.com>> wrote:
> >>
> >> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr
> > <mailto:yann.morin.1998@free.fr>> writes:
> >>
> >> Hi,
> >>
> >> >> 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)
> 
>  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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2016-01-19 23:02 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-22 12:35 [Buildroot] [PATCH v9] toolchain: create symlink ARCH_LIB_DIR->lib in addition to lib32/lib64->lib Thomas De Schampheleire
2016-01-05 12:37 ` Thomas De Schampheleire
2016-01-12 23:12 ` Romain Naour
2016-01-14 19:35   ` Thomas De Schampheleire
2016-01-17 14:45 ` Thomas Petazzoni
2016-01-19 14:15   ` Thomas De Schampheleire
2016-01-19 14:17     ` Thomas De Schampheleire
2016-01-19 14:26       ` Peter Korsgaard
2016-01-19 16:01         ` Thomas De Schampheleire
2016-01-19 18:29           ` Yann E. MORIN
2016-01-19 18:35             ` Peter Korsgaard
2016-01-19 19:40               ` Thomas De Schampheleire
2016-01-19 22:57                 ` Arnout Vandecappelle
2016-01-19 23:02                   ` Yann E. MORIN
2016-01-19 20:03             ` Thomas Petazzoni

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.