armel build failure (uses internal outdated libffi)

I do have a simple patch for this, attached...

Requesting freeze exception to upload as we're past RC and final freeze to upload FTBFS resolivng bug. Changes are ARM specific, and will not interfere on any other architecture. No code changes.

I wonder why you subscribed motu-release. It's ubuntu-release these days...

Approved. Please upload.

N.B.: as a bug fix to an unseeded universe package, this doesn't require a freeze exception at all, you can just upload to the queue.

As discussed, no FFe needed.

This bug was fixed in the package plt-scheme - 4.2.4-2ubuntu1

---------------
plt-scheme (4.2.4-2ubuntu1) maverick; urgency=low

  * Use -mfloat-abi=soft for thumb2 assembler (LP: #635415)
 -- David Sugar <email address hidden> Fri, 01 Oct 2010 14:00:26 +0000

the patch is wrong. it works around a bug in libffi, which is both fixed upstream and in the Ubuntu package. so either fix the copy of libffi, or use the system libffi.

There are specific reasons the patch was done the way it was:

First, it did not make sense to modify in any way the build of plt-scheme on other architectures this close to release. We would have had to rebuild all packages dependent on it, and verify they were not broken as a result of such a change like the one originally proposed to change the linkage and use an external instance of libffi. Hence, I sought a change that only effects and resolves the issue for armel without risking effecting the builds on any other architecture.

Second, because of the way libtool works, it strips out most cflags options when compiling .S files. For this reason, the only clear way to force feed the necessary option from the debian rules was to override CC itself.

Finally, the package is being renamed and redone in Natty, as happened in Debian. Upstream renamed itself rachet starting with 5.0. Hence, my original patch, or any patch, has a short shelf life. The goal was to avoid having to do SRU's just because of armel for Maverick, and not to change the way this and dependent packages are built or linked on the other architectures in Maverick.

I couldn't find a "rachet" package; does it change anything what the name of the package is? I expect the packaging will be moved to the new name, just like this bug

It is also an entirely new baseline upstream release (5.0) as well as a rename. This patch may still apply under the new name, but when it happens all the dependent packages will also have to be rebuilt anyway, so that is when it would make sense to change it to use the external libffi and play with linking or otherwise playing with it, assuming the 5.x upstream still bundles it's own local libffi.

a fix was copied from libffi, and the previous change undone.