Bug 295550 – sys-devel/gcc-4.3.4/4.4.2: libffi fails to build for arm with binutils-2.20

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Diego Elio Pettenò (RETIRED) 2009-12-03 13:03:57 UTC]

See attached logs.

[Comment 1 Diego Elio Pettenò (RETIRED) 2009-12-03 13:07:01 UTC]

Created attachment 211854 [details]
Build log

[Comment 2 Diego Elio Pettenò (RETIRED) 2009-12-03 13:08:28 UTC]

Created attachment 211855 [details]
Info

[Comment 3 Diego Elio Pettenò (RETIRED) 2009-12-03 14:50:53 UTC]

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. 

[Comment 4 SpanKY 2009-12-03 21:04:59 UTC]

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 ...

[Comment 5 Diego Elio Pettenò (RETIRED) 2009-12-03 21:17:14 UTC]

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 :(

[Comment 6 Diego Elio Pettenò (RETIRED) 2009-12-04 22:40:52 UTC]

Created attachment 212104 [details, diff]
Patch to fix the problem

[Comment 7 Steev Klimaszewski (RETIRED) 2009-12-09 06:07:43 UTC]

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

[Comment 8 Raúl Porcel (RETIRED) 2009-12-10 17:30:24 UTC]

(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

[Comment 9 Samuli Suominen (RETIRED) 2009-12-13 16:53:41 UTC]

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...

[Comment 10 Diego Elio Pettenò (RETIRED) 2009-12-13 16:57:11 UTC]

Samuli, this happens with the crossdev-compiled ebuild, so it needs to get fixed somehow for gcj to work in that case.

[Comment 11 SpanKY 2010-05-29 03:56:02 UTC]

Diego: upstream is waiting for you to post your patch to the right place

[Comment 12 Raúl Porcel (RETIRED) 2010-11-20 11:51:18 UTC]

I forwarded it: http://sourceware.org/ml/libffi-discuss/2010/msg00160.html

[Comment 13 SpanKY 2013-12-22 21:02:39 UTC]

it should be fixed in newer versions now