Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140628125308.3c6a1f0d@free-electrons.com>
Date: Sat, 28 Jun 2014 12:53:08 +0200
From: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To: musl@...ts.openwall.com
Subject: Issues with the 1.1.2 pre-built musl toolchains

Hello,

In Buildroot, we do have support for the pre-built musl toolchains
available from http://musl.codu.org/. Up until the musl 1.1.1
toolchains, everything was working fine, but unfortunately the musl
1.1.2 toolchains are no longer working correctly, for two reasons:

 * The first reason is that the sysroot support has been disabled,
   while this sysroot support was initially requested by us to be able
   to use those pre-built toolchains in Buildroot. Buildroot simply
   cannot support non-sysroot capable pre-built toolchains. Moreover,
   the commit that indicates why sysroot support is not desirable
   (https://bitbucket.org/GregorR/musl-cross/commits/16ccdedb5fae1fbf72fe61ceec35025e3b6a1557)
   indicates that it's related to a path issue in the libstdc++.la
   file, but I fail to see any difference between the libstdc++.la file
   of the 1.1.1 musl toolchains (which do have sysroot support), and
   the libstdc++.la file of the 1.1.2 musl toolchains (which no longer
   have sysroot support) :

 === musl 1.1.1 toolchains ===

thomas@...te:~/dl/arm-linux-musleabi-1.1.1$ ./bin/arm-musl-linuxeabi-gcc -v
[...]
Configured with: ../configure --prefix=/opt/cross/musl/arm-linux-musleabi --target=arm-linux-musleabi --with-sysroot=/opt/cross/musl/arm-linux-musleabi/arm-linux-musleabi --enable-languages=c,c++ --disable-libmudflap --disable-libsanitizer --disable-multilib --disable-lto-plugin --with-arch=armv4t
[...]
thomas@...te:~/dl/arm-linux-musleabi-1.1.1$ cat arm-linux-musleabi/lib/libstdc++.la
# libstdc++.la - a libtool library file
# Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libstdc++.so.6'

# Names of this library.
library_names='libstdc++.so.6.0.19 libstdc++.so.6 libstdc++.so'

# The name of the static archive.
old_library='libstdc++.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=' -lm'

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libstdc++.
current=6
age=0
revision=19

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/opt/cross/musl/arm-linux-musleabi/arm-linux-musleabi/lib'

 === musl 1.1.2 toolchains ===

thomas@...te:~/dl/arm-linux-musleabi-1.1.2$ ./bin/arm-linux-musleabi-gcc -v
[...]
Configured with: ../configure --prefix=/opt/cross/musl/arm-linux-musleabi --target=arm-linux-musleabi --enable-languages=c,c++ --disable-libmudflap --disable-libsanitizer --disable-nls --disable-multilib --disable-lto-plugin --with-arch=armv4t
[...]
thomas@...te:~/dl/arm-linux-musleabi-1.1.2$ cat arm-linux-musleabi/lib/libstdc++.la
# libstdc++.la - a libtool library file
# Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libstdc++.so.6'

# Names of this library.
library_names='libstdc++.so.6.0.19 libstdc++.so.6 libstdc++.so'

# The name of the static archive.
old_library='libstdc++.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=' -lm'

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libstdc++.
current=6
age=0
revision=19

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/opt/cross/musl/arm-linux-musleabi/arm-linux-musleabi/lib'

   As you can see, the libdir is identical in both .la files, so
   disabling the sysroot support hasn't changed anything, so I believe
   some incorrect assumption was made in commit
   https://bitbucket.org/GregorR/musl-cross/commits/16ccdedb5fae1fbf72fe61ceec35025e3b6a1557.

 * The second problem is that the kernel headers seem to no longer be
   present in the toolchains. I've seen that musl-cross has switched to
   using the sanitized kernel headers from Sabotage but the end result
   is that there are no longer any headers in usr/include/linux. For
   example, Buildroot looks at <linux/version.h> to see the kernel
   version of the headers, and uses that to ensure the user doesn't use
   kernel headers that are too old to build certain
   applications/libraries that need recent kernel headers. The
   disappearance of <linux/version.h> is problematic for this specific
   usage, but I believe the disappearance of *all* <linux/foo.h>
   headers is probably going to cause build issues as well. See:

thomas@...te:~/dl/arm-linux-musleabi-1.1.1$ LANG=C cat arm-linux-musleabi/usr/include/linux/version.h 
#define LINUX_VERSION_CODE 199686
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
thomas@...te:~/dl/arm-linux-musleabi-1.1.2$ LANG=C cat arm-linux-musleabi/usr/include/linux/version.h 
cat: arm-linux-musleabi/usr/include/linux/version.h: No such file or directory

Would it be possible to revert back to the build process of the 1.1.1
musl toolchains, which were working perfectly fine?

Thanks a lot,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.