Re: GUB and mipsel architecture

[Graham Percival]

On Mon, May 17, 2010 at 08:45:37AM +0200, Federico Bruni wrote:
> I'm wondering if it is worth having a mipsel package on lilypond.org
> (when 2.14 comes out, maybe).
> I'd be happy to do it, if I can. A chance to help and learn something
> new.

This should be discussed on -devel rather than -user.

I would be happy to build+include mipsel packages, as long as
somebody else modifies GUB to handle it, and they fix any breakage
in those packages.  If they stop GUB from compiling a release, I
would simply comment out the mipsel compilation and release the
rest.

However, cross-compiling is a fairly involved process and requires
a great deal of technical knowledge.  Don't expect much help,
because very few people have any experience with it.


> #########################################################################
> 
> Tail of target/tools/log/librestrict.log >>>>>>>>
>     ./xstatconv.c:224: error: 'struct stat' has no member named '__pad2'
>     ./xstatconv.c:266: error: 'struct stat' has no member named
> '__unused4'
>     ./xstatconv.c:269: error: 'struct stat' has no member named
> '__unused5'
>     Command barfed:
> cd /home/fede/src/gub/target/tools/build/librestrict-1.9.a && gcc -W
> -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so
> restrict-stat.c || gcc -W -Wall  -I. -fPIC -shared -o
> librestrict-stat.so restrict-stat.c
> <<<<<<<< Tail of target/tools/log/librestrict.log
> 
> *** Failed target: tools::librestrict
> 
> ##########################################################################
> 
> Just in case, I attach also target/tools/build/librestrict-1.9.a/xstatconv.c
> 
> How can I fix it?

I would begin by searching for this error on google.  Also, where
in the code does this error occur?  What do you see around lines
260-270 in xstatcon.c ?  also, what headers does this file
include, and are those headers available?


> PS (a report on a different subject)

Please don't report multiple issues in the same email.

> I've read that you have changed the ./configure in 2.13.21
> In previous versions, when I run ./autogen.sh, ./configure failed to 
> recognise my architecture,
> even though some information were printed on terminal (can't remember)
> and especially: `uname -m mips64`
> Since this version I don't have this warning.
> Maybe next time I can try removing the --build=mips64 option and see what 
> happen.

Err... is this a report, or a memo to yourself?  By all means, try
removing that build option and see what happens.  As you said,
we've updated the ./configure script, so I wouldn't be surprised
if the host architecture detection is better.

Cheers,
- Graham