Re: Creating a hardfloat package
On Apr 14, 2011, at 09:32, Konstantinos Margaritis wrote:
> On 14 April 2011 01:39, Jeremiah C. Foster <email@example.com> wrote:
>> The subject says it all. I'm looking to create a package or two and
>> I'd like to use the fancy hardfloat toolchain thingy to make my
>> packages all shiny. I've been reading
>> http://wiki.debian.org/ArmHardFloatPort with rapt attentiond and note
>> that porting of packages is in progress, I thought I might even be
>> able to help out there.
> We'd greatly appreciate all the help!
>> Can someone point me to a source of documentation to describe any
>> required actions on the packagers part to enable hardfloat?
> Well, there is no documentation, but here are a few pointers:
> 1. Is armel included in the Architecture field in control? If so, it's
> *very* likely
> that the package will just build with armhf added there.
I thought that all I might need to do was change the Arch field in the control file, I'll start there.
My plan is to use debootstrap to create a Debian wheezy chroot and build packages inside that. The target I'm building on is a Tegra2 that came with Ubuntu pre-installed and I cannot remove that OS at this point so I figure adding a Debian root file system should be sufficient for my needs.
> 2. If no armel/armhf is included in there, it's possible that the
> package will still
> build with some fixes. For that reason, I usually check the corresponding
> package on Launchpad (for Ubuntu), as they have already done some good
> porting work for their armel port.
Ah, good to know.
> 3. For packages that fail on armhf but succeed on armel, it's highly likely that
> this is due to some thumb2 bug. Ubuntu is great help there, many packages
> have already been fixed on ubuntu-armel for thumb2 problems and most of
> the time it's just a case of backporting the thumb2 patches (as was the case
> with libmad and others), and now I'm working on backporting fixes for
> coq, blcr, openmsx. Dave Martin from ARM has done a great job in finding and
> fixing those.
Cool. Maybe I'll build on the Ubuntu machine directly too then.
> 4. There are some minor compiler problems right now -due to a triplet change-
> but there are working versions of 4.4,4.5,4.6 and recent binutils already. glibc
> has a problem building however (on many arches iirc) and I haven't tried the
> experimental version yet. Most packages should be fine.
> 5. Forget any java package right now, gcj is broken for armhf, we're waiting for
> a fixed libffi in order to rebuild gcj with it -and hope that it
> works. Unfortunately,
> java is a build-dep for many packages, incl subversion, db4.x, db5.x, so if
> your package needs a recent version of those, you'll just have to wait.
Java? Blech. =)
> 6. there are some fixes pending with some important packages, namely openmpi
> should be fixed for both armel/armhf (again the fixes backported from Ubuntu),
> which means that openmpi build-dep should be enabled for some other
> packages too (in particular I'm waiting for hdf5, which just got fixed
> for armhf).
> 7. Finally, there are some really tricky packages like compilers (fpc,
> ghc, clisp,
> plt-scheme, gnat, sbcl, and llvm-related packages) which would love some
> attention :)
Hrm. While I would love to win some Debian/Ubuntu/Linaro cred here, I'm somewhat skeptical of my lisp-fu. The other packages, like llvm stuff look sufficiently hairy to scare me away. Sadly I know nothing about Ada either. :(
> In short, check
> and see what fails, if there is an existing bug report ( if not, help
> us file them :).
Great! I'll see if there is some low hanging fruit. :-)
> For now, ignore the java packages, they all fail. If you're feeling
> lucky, try one
> of the compiler things (ghc6 should be fun to port, already tried but
> got segfaults
> on the cross building system :)
> Anyway, thanks for the interest and of course help is welcome on all of those!
Thank you Konstantinos, I appreciate the pointers and that you took the time to help me out.