97e9db4332
libpthsem has been affected since quite a while by build issues, but
occuring only on Nathaniel Roach's autobuilder. The failure message
is:
error: #error "Unsupported Linux (g)libc version and/or platform"
This message comes from pth_mctx.c file, which implements five methods
for machine context initialization:
VARIANT 1: THE STANDARDIZED SVR4/SUSv2 APPROACH
VARIANT 2: THE SIGNAL STACK TRICK
VARIANT 3: LINUX SPECIFIC JMP_BUF FIDDLING
VARIANT 4: INTERACTIVE SPECIFIC JMP_BUF FIDDLING
VARIANT 5: WIN32 SPECIFIC JMP_BUF FIDDLING
The "Unsupported (g)libc version and/or platform" only appears when
"VARIANT 4" is used, since VARIANT 4 only supports a very limited
number of platforms. So when building with Nathaniel's autobuilder,
VARIANT 4 is chosen.
However, when you build libpthsem on some other machine than
Nathaniel's autobuilder, VARIANT 2 is chosen, and works regardless of
the glibc version or architecture.
VARIANT 2 is chosen when:
!PTH_MCTX_DSP(sjljlx) &&\
!PTH_MCTX_DSP(sjljisc) &&\
!PTH_MCTX_DSP(sjljw32)
On both Nathaniel's autobuilder, and on a different machine, the
PTH_MCTX_MTH macro gives sjlj:
#define PTH_MCTX_MTH_use PTH_MCTX_MTH_sjlj
However, on a "normal" machine, the PTH_MCTX_DSP macro gives ssjlj:
#define PTH_MCTX_DSP_use PTH_MCTX_DSP_ssjlj
While on Nathaniel's autobuilder, it gives:
#define PTH_MCTX_DSP_use PTH_MCTX_DSP_sjljlx
This explains why VARIANT 4 is being used on Nathaniel's autobuilder,
while VARIANT 2 is used when building on other platforms.
The decision of the value for PTH_MCTX_DSP is derived as follows in
configure.ac:
AC_CHECK_SJLJ(sjlj=yes, sjlj=no, sjlj_type)
[...]
elif test ".$sjlj" = .yes; then
mctx_mth=sjlj
mctx_dsp=$sjlj_type
[...]
AC_DEFINE_UNQUOTED(PTH_MCTX_DSP_use, [PTH_MCTX_DSP_$mctx_dsp], [define for machine context dispatching])
So basically, the value of PTH_MCTX_DSP is $sjlj_type, as returned by
the AC_CHECK_SJLJ autoconf macro, implemented in
acinclude.m4. However, reading this macro is quite informative: it
does a number of tests that are not cross-compile
friendly. Especially, it looks at the kernel version with 'uname -r'
to decide whether the Linux system is braindead or not. If the system
runs a 2.2.x kernel or newer 2.x, or a 3.x kernel, everything is fine,
the system is not braindead, and sjlj_type is set to ssjlj. However,
if the build system runs a 4.x kernel, then it is considered as
braindead, and sjlj_type is set to sjljlx.
And indeed, Nathaniel's autobuilder is running a 4.x kernel, while all
other autobuilders run 2.x or 3.x kernels.
Since for all sane Linux systems, this AC_CHECK_SJLJ macro concludes
that the setjmp/longtmp type is ssjlj, this commit takes the simplest
route of forcing this value, skipping the broken detection.
Note that we're overriding ac_cv_check_sjlj instead of using the
--with-mctx-* options, since the latter do not work properly in the
context of Nathaniel's autobuilder, as the broken cross-compilation
tests continue to cause problems.
Fixes:
http://autobuild.buildroot.org/results/3dd/3dd66d70c2e36f2d9fb0a0fe01bbdec009d55067/
and many similar build failures
This patch has been tested by Nathaniel Roach in the context of his
autobuilder instance which was causing the original problem.
Tested-by: Nathaniel Roach <nroach44@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
|
||
|---|---|---|
| arch | ||
| board | ||
| boot | ||
| configs | ||
| docs | ||
| fs | ||
| linux | ||
| package | ||
| support | ||
| system | ||
| toolchain | ||
| .defconfig | ||
| .gitignore | ||
| CHANGES | ||
| Config.in | ||
| Config.in.legacy | ||
| COPYING | ||
| Makefile | ||
| Makefile.legacy | ||
| README | ||
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. The documentation can be found in docs/manual. You can generate a text document with 'make manual-text' and read output/docs/manual/manual.text. Online documentation can be found at http://buildroot.org/docs.html To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the target architecture and the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) find the kernel, bootloader, root filesystem, etc. in output/images You do not need to be root to build or run buildroot. Have fun! Buildroot comes with a basic configuration for a number of boards. Run 'make list-defconfigs' to view the list of provided configurations. Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org You can also find us on #buildroot on Freenode IRC.