Summary: | sys-devel/gcc-4.3.4/4.4.2: libffi fails to build for arm with binutils-2.20 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | [OLD] GCC Porting | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arm, ssuominen, steev |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://gcc.gnu.org/PR42289 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build log
Info Patch to fix the problem |
Description
Diego Elio Pettenò (RETIRED)
2009-12-03 13:03:57 UTC
Created attachment 211854 [details]
Build log
Created attachment 211855 [details]
Info
Seems like this change ( http://sourceware.org/ml/binutils/2009-07/msg00002.html ) broke the build: while .fnstart and .fnend are present in the code (.fnstart added by a macro) it still outputs the error. gcj is _very_ low on the list of priorities (one might say i largely ignore it). so cross-compiling gcj is pretty useless. if there's a patch, i dont mind including it ... Mostly opened this to avoid forgetting it; sincerely I'm afraid this is a bug with binutils-2.20, since 2.18-r3 builds libffi fine. And I don't think it's even cross-related :( Created attachment 212104 [details, diff]
Patch to fix the problem
I'm not sure if this is entirely the correct bug or not - but I ran into a similar issue with the Efika MX which is an arm v7 - in my choort, libffi fails to build, however applying this patch from upstream GCC fixes the issue http://gcc.gnu.org/viewcvs?view=revision&revision=152075 Tested compiling libffi-3.0.9_rc3 and it builds fine so the patch only applies to 3.0.8 (In reply to comment #7) > I'm not sure if this is entirely the correct bug or not - but I ran into a > similar issue with the Efika MX which is an arm v7 - in my choort, libffi fails > to build, however applying this patch from upstream GCC fixes the issue > > http://gcc.gnu.org/viewcvs?view=revision&revision=152075 > > Tested compiling libffi-3.0.9_rc3 and it builds fine so the patch only applies > to 3.0.8 > I've fixed that one sys-devel/gcc[libffi] is a) blocked by dev-lang/python because _ctypes doesn't work with it, see b) b) package.use.masked in profiles/base/ because of ld.so.conf conflict (ordering). one could describe building sys-devel/gcc as [libffi] enabled as system breaking feature now because of a). i don't know if there's any point in trying to maintain the gcc version of it as we have dev-libs/libffi going well now... Samuli, this happens with the crossdev-compiled ebuild, so it needs to get fixed somehow for gcj to work in that case. Diego: upstream is waiting for you to post your patch to the right place I forwarded it: http://sourceware.org/ml/libffi-discuss/2010/msg00160.html it should be fixed in newer versions now |