When trying to compile hfsplus-tools on ARM I get the following error: In file included from hfs_endian.c:31: In file included from /usr/include/sys/types.h:25: In file included from /usr/include/features.h:399: /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found # include <gnu/stubs-soft.h> ^ In file included from makehfs.c:32: In file included from /usr/include/sys/param.h:25: In file included from /usr/include/sys/types.h:25: In file included from /usr/include/features.h:399: /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found # include <gnu/stubs-soft.h> ^ ^Cmake[1]: *** [hfs_endian.o] Interrupt make[1]: *** [makehfs.o] Interrupt make: *** [all] Interrupt $ more /usr/include/gnu/stubs.h /* This file is automatically generated. This file selects the right generated file of `__stub_FUNCTION' macros based on the architecture being compiled for. */ #if !defined __ARM_PCS_VFP # include <gnu/stubs-soft.h> #endif #if defined __ARM_PCS_VFP # include <gnu/stubs-hard.h> #endif gnu/stubs-hard.h exists but gnu/stubs-soft.h does not
The most likely cause of this is as follows: (a) You're on a hard-float rootfs where the gcc package didn't install stubs-soft.h (since it was itself compiled for hard-float only support). (b) You failed to pass hard-float flags to the package build, compiling for soft-float instead, and when the package included (albeit indirectly) stub.h, it tried to include the soft-float headers (which don't exist because this a hard float rootfs). Have you tried compiling with `-mfpu=neon -mfloat-abi=hard' or whatever you used to build the rootfs?
To be clear this is neither glibc nor gcc's problem. Reassigning to hfsplus-tools until we get some more information.
Actually it happens on just about all packages dependant on llvm and yes all the packages I tried had the appropriate CFLAGS set
(In reply to Peter Robinson from comment #3) > Actually it happens on just about all packages dependant on llvm and yes all > the packages I tried had the appropriate CFLAGS set Then it's an LLVM bug that it doesn't set __ARM_PCS_VFP when in hard-float mode. Which is already fixed upstream: http://llvm.org/bugs/show_bug.cgi?id=13796
> Which is already fixed upstream: > http://llvm.org/bugs/show_bug.cgi?id=13796 Is it? That indicates it's fixed in 3.1 and we're already running a pre release of 3.3
(In reply to Peter Robinson from comment #5) > > Which is already fixed upstream: > > http://llvm.org/bugs/show_bug.cgi?id=13796 > > Is it? That indicates it's fixed in 3.1 and we're already running a pre > release of 3.3 It looks like you've proved it isn't? :-)
There's some discussion of this bug on Fedora devel list. https://lists.fedoraproject.org/pipermail/devel/2014-June/thread.html#199702 The belief there is that this is an LLVM bug (bug 803433, upstream http://llvm.org/bugs/show_bug.cgi?id=15557), *different* from the bug mentioned in comment 4. FWIW the bug is still present in clang-3.4-6.fc20.armv7hl, which seems to indicate it's NOT the same bug as the one in comment 4 ...
With hfsplus-tools losing the dependency on llvm this is now fixed.