Ports to other architectures was Re: Fedora Core on the Alpha

[Lennert Buytenhek]

On Tue, Aug 10, 2004 at 06:10:28PM -0500, Dennis Gilmore wrote:

> > We have a couple of alpha machines (an AlphaStation XP 1000 and an
> > AlphaServer ES40) currently running SuSE 8.1 which would be nice to
> > upgrade. Some time ago I remember reading something about a interest in
> > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2
> > alpha port?
> 
> not sure on the alpha port  but ive just ordered a sun box and im most
> likely going to put linux on it,  so im intreseted in a sparc port.
> perhaps  people involved in porting to non x86 based architectures
> could give progress reports  and  tips on areas that need work.

I'm reasonably far with the xscale big endian (armv5teb) port.  Most
things just work, it just takes a lot of time to compile-test things
as I only have one 600MHz processor to work with (and crosscompiling
is not an option because a lot of packages are simply broken with
respect to that, hardcoding CC=gcc, etc.)

I had to do quite some backtracking along the way.  The one thing that
really bit me was that rpm's config.guess believes that there is no
such thing as armv5teb-redhat-linux-gnu, instead insisting on
armv5teb-unknown-linux-gnu.  This causes the compiled version of rpm
not to include stuff in /usr/lib/rpm/redhat/, which causes the host
triple to be armv5teb-unknown-linux instead of *-linux-gnu, and that
subtly breaks a LOT of stuff (such as libtool refusing to build
shared libs, which then cascades into a lot of other places.)

One thing that's also confusing is packages that depend on themselves.
For example, I had a lot of trouble building tzdata without having
a copy of tzdata installed -- it seems that its make check checks not
the version that is being built, but the version of tzdata that has
already been installed.  No version of tzdata installed -> make check
fails.  Manually installing it and then retrying the build -> works.

Something I didn't figure out yet is this: some packages that use X
end up with compiler flags like such:

CPPFLAGS=" -I/usr/X11R6/include -Dlinux -D__arm__ -D__arm32__ -U__arm -Uarm -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXVENDORNAME=The X.Org Foundation -DXVENDORNAMESHORT=X.Org "

configure then fails with:

checking for C compiler default output file name... configure: error: C compiler cannot create executables

quite simply because "X.Org" and "Foundation" are not valid gcc options.
Ho hum.


--L