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