Re: GUB success.

[Erik Sandberg]

On Saturday 26 August 2006 01:07, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > Hi,
> >
> > Now gub works here (on my IA32 partition), so I can commit code again.
> >
> > I couldn't easily force a rebuild. If I have a patch I want to test, what
> > should I do? I applied the patch to downloads/lilypond-HEAD, but I
> > couldn't find a good way to force make or make linux to rebuild (the only
> > way I could find was rm -r target/).
>
> The best way is to change downloads/lilypond-HEADS/.cvs-checksum.
>
> That file is a checksum of all CVS/Entries files, and if it's changed,
> GUB assumes it has to rebuild the thing.

OK, thanks.

I'm having a different problem now: I'm trying to get GUB to work in x86-64. 
I'm facing two problems, which both happen during make bootstrap:
- I tried to insert a patch in patches/ to make guile build, but I don't 
understand how to have it applied: I added a line in specs/guile.py which 
imitated the one for guile-reloc.patch, but neither guile-reloc.patch nor 
guile-x86_64 was applied before guile was built, hence the build failed.
- I could temporarily fix the above problem, but now there's a failure in the 
compilation of odcctools:
 *** Stage: compile (odcctools)
[...]
gcc -Wall -Wno-import  -DHAVE_CONFIG_H -D__LITTLE_ENDIAN__=1 
-D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ 
-D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_ -DSTDC_HEADERS 
-I..//include 
-I/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/include
 -include 
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/include/extern.h
 
-I/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/include/foreign
 -g -O2 -fno-builtin-round -fno-builtin-trunc   -c -o 
writeout.o 
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:
 
In function ‘writeout’:
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:131:
 
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:264:
 
warning: cast from pointer to integer of different size
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:
 
In function ‘writeout_to_mem’:
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:382:
 
warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:
 
In function ‘make_table_of_contents’:
/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:1021:
 
error: ‘union <anonymous>’ has no member named ‘ran_name’
[...]

Strangely, this didn't happen when building in 32-bit mode.

> It would be nice if there were a less ad-hoc way of dealing with this.
> Perhaps we could build GUB from a git repo of lilypond instead?

Hm. For the moment, it would be sufficient for me if I just could tell gub to 
use the lily source from some given directory, using an environment variable 
or something. (i.e.: cd gub; export 
GUB_LILY_SRC=/home/erik/lily/lily-work-in-progress/ ; make linux ; make doc)
Hm, perhaps I can already do this by substituting download/lilypond-HEAD/ with 
a symlink to the desired source.

Using git would be a good solution too. It would also be an excuse for me to 
get started with git in my development (which presumably is a lot better than 
my current playing around with diff'n'patch)

-- 
Erik