Skip to content
  1. May 31, 2016
  3. May 30, 2016
    • Yann E. MORIN's avatar
      toolchain/helper: don't follow symlinks when copying libs to target · 49648d4b
      Yann E. MORIN authored 
      In 2a87b64f (toolchain-external: align library locations in target and
staging dir), copying the libraries from the sysroot to the target was
changed to a simple find-based solution.

To be sure that the staging directory was entered to find the libraries,
in case the variable was pointing to a symlink, the -L clause to find
was used.

However, that causes extraneous libraries to be copied over.

For example, a ct-ng toolchain would have this sysroot (e.g for an arm
32-bit toolchain):

    .../sysroot/lib/
    .../sysroot/lib32 -> lib
    .../sysroot/lib64 -> lib
    .../sysroot/usr/lib/
    .../sysroot/usr/lib32 -> lib
    .../sysroot/usr/lib64 -> lib

Which we would carry as-is to our own sysroot.

But then, in target, our skeleton creates the /lib/ and /usr/lib
directories, with the necessary lib32 or lib64 symlink pointing to it.
In this case, a lib32->lib symlink is created, but no lib64 symlink
since this is a 32-bit architecture.

To copy the required libraries from staging into target, we scan the
staging directory for all occurences of the required libraries, and copy
them over to target, keeping the same directory layout relative to the
sysroot.

For example:
    .../sysroot/usr/lib/libfoo.so   -->  .../target/usr/lib/libfoo.so
    .../sysroot/usr/lib32/libbar.so -->  .../target/usr/lib32/libbar.so
    .../sysroot/usr/lib64/libbuz.so -->  .../target/usr/lib64/libbuz.so

So, when we copy over the libraries from our staging to the target
directory, the "find -L .../sysroot -name libblabla.so.*" would find
multiple instances of libblabla, each in the /usr/lib /usr/lib32 and
/usr/lib64 locations (they are all the exact same file, though).

Since we do have the /usr/lib32->lib symlink, all is OK (but there are
two copies going on, which could be avoided). However, since we do not
have the /usr/lib64->lib symlink, the /usr/lib64/ directory is created.

This was very difficult to observe, as no /lib64/ directory is created,
only the /usr/lib64/ one was. To top it off, this only happens with a
merged /usr, which does not seem like not a common case without systemd.

Since the reason to use -L was to be sure to enter our staging
directory, we just need to ensure that the path ends up with a slash, as
was already talked about in this thread:
    http://lists.busybox.net/pipermail/buildroot/2016-April/159737.html



After further discussion, it turns out that the original patch came along
because of the confusion between output/staging (which is a symlink) and
$(STAGING_DIR) which expands to output/host/usr/<tupple>/sysroot (which is
never a symlink), so the symlink handling isn't really needed at all.

[Peter: drop description comment, extend description]
Signed-off-by: default avatar"Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      49648d4b
    • Bernd Kuhls's avatar
      package/rpm: needs gcc >= 5.x on SuperH · 15b6f3ba
      Bernd Kuhls authored 
      Compilation triggers an ICE in gcc with gcc 4.9

../db/dist/../lock/lock_deadlock.c: In function '__lock_detect_rpmdb':
../db/dist/../lock/lock_deadlock.c:354:1: internal compiler error: Segmentation fault
 }
 ^

using this defconfig

BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_RPM=y

Compiling rpm with gcc5 works fine using this defconfig:

BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_GCC_VERSION_5_X=y
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_RPM=y

This patch adds a dependency to gcc >= 5.x to fix
http://autobuild.buildroot.net/results/e4b/e4b7705e3e148755ae34d498c860a3b9b915e0b0/



[Peter: simpify kconfig, add comment explaining why]
Signed-off-by: default avatarBernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      15b6f3ba
    • Bernd Kuhls's avatar
      package/gstreamer/gst-ffmpeg: needs gcc >= 5.x on SuperH · 89eeadfc
      Bernd Kuhls authored 
      Compilation triggers an ICE in gcc with gcc <= 4.9 using this defconfig

BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PACKAGE_GSTREAMER=y
BR2_PACKAGE_GST_FFMPEG=y
BR2_PACKAGE_GST_FFMPEG_GPL=y

The problem is known upstream, a fix was never committed to gcc <= 4.9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151

Compiling gst-ffmpeg with gcc5 works fine using this defconfig:

BR2_sh=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_GCC_VERSION_5_X=y
BR2_PACKAGE_GSTREAMER=y
BR2_PACKAGE_GST_FFMPEG=y
BR2_PACKAGE_GST_FFMPEG_GPL=y

This patch adds a dependency to gcc >= 5.x to fix the problem as
suggested by Thomas:
http://lists.busybox.net/pipermail/buildroot/2016-February/152584.html

Fixes
http://autobuild.buildroot.net/results/939/939da0c7771ddd97c05cedc0a7afc0ad34a21312/



[Peter: fix ML link, simplify kconfig, add comment explaining why]
Signed-off-by: default avatarBernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      89eeadfc
    • Samuel Martin's avatar
      package/lttng-babeltrace: fix static build · ef18eedc
      Samuel Martin authored 
      This change adds a patch fixing libuuid detection on static build.

Fixes:
  http://autobuild.buildroot.net/results/43b/43b98ddf9eb44152ed9ac4a98d887af14831d8da/



[Peter: add comment why autoreconf is needed]
Signed-off-by: default avatarSamuel Martin <s.martin49@gmail.com>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      ef18eedc
    • Fabio Estevam's avatar
      warpboard: README: Fix a few typos · 0a2d5759
      Fabio Estevam authored 
      

Signed-off-by: default avatarFabio Estevam <festevam@gmail.com>
Acked-by: default avatar"Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      0a2d5759
  5. May 29, 2016
    • Samuel Martin's avatar
      package/pulseview: fix build when linking against libatomic is needed · b385d13f
      Samuel Martin authored 
      With some toolchains, using atomics requires to explicitly add -latomic
to the linker flags.

This change adds a patch to pulseview adding this detection and updating
the LDFLAGS when appropriate.

This patch has be sent upstream:
  http://article.gmane.org/gmane.comp.debugging.sigrok.devel/2097

Fixes:
  http://autobuild.buildroot.org/results/1e3/1e3101261252d5f30fdf842cc99604e4f4c25eef/build-end.log



Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: default avatarSamuel Martin <s.martin49@gmail.com>
Reviewed-by: default avatarRomain Naour <romain.naour@gmail.com>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      b385d13f
    • Thomas Petazzoni's avatar
      libdrm: improve atomic handling, fix SPARCv8 build · e4d55d33
      Thomas Petazzoni authored 
      This commit improves the handling of the "atomic stuff" in the libdrm
package. libdrm can either use the atomic intrinsics (4 byte variant)
when available, or otherwise can use libatomic_ops. Note that the
dependency on atomic operations is not from libdrm itself, but only
from some specific DRM drivers only.

Amongst other things, it fixes the build of the libdrm package on
SPARCv8, therefore fixing:

  http://autobuild.buildroot.org/results/74dd29b5ea146c320fde80a87a2fc910de9b7f60/



This commit does a number of changes that are all related to each
other:

 - Removes the dependency of the Intel DRM driver on
   libatomic_ops. The Intel DRM driver builds perfectly fine without
   libatomic_ops, as long as 4-byte variant __sync operations are
   available, which is always the case on x86 and x86_84 (which are
   the only architectures on which the Intel DRM driver can be
   enabled).

 - Adds an hidden Config.in boolean option
   BR2_PACKAGE_LIBDRM_HAS_ATOMIC that allows DRM driver that need
   atomic operation to know whether atomic support is available
   (either through intrinsics or through libatomic_ops).

 - Adds an hidden BR2_PACKAGE_LIBDRM_ENABLE_ATOMIC Config.in option
   that DRM drivers that need atomic operation should select to ensure
   that the relevant dependencies are selected. It simply selects
   libatomic_ops if 4-byte atomic intrinsics are not available. We
   could let each DRM driver do this, but having an intermediate
   option avoids a bit of duplication.

 - Adds a patch that defines AO_REQUIRE_CAS before including
   <atomic_ops.h>. This is needed because libdrm uses the
   AO_compare_and_swap_full() which is only provided on all
   architectures when AO_REQUIRE_CAS is defined. The exact same fix
   was done in the erlang package in commit
   4a9df294.

 - Adds the dependency on libatomic_ops when the package is enabled,
   and passes the necessary CFLAGS on SPARCv8 to make the thing build
   properly. The same CFLAGS are passed in the nginx package and bdwgc
   package.

Cc: Waldemar Brodkorb <wbx@openadk.org>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      e4d55d33
  7. May 28, 2016
  9. May 27, 2016
  11. May 26, 2016