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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
