Re: [Denemo-devel] the release

[Richard Shann]

I have found that if I re-run the failing compile steps in the directory
they failed in during the make, then they succeed
for example

gcc   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute
-DHAVE_CONFIG_H -I. -I.
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/.
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/../include
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/../libcpp/include     \
>   -DTARGET_NAME=\"i686-mingw32\" \
>   -c /home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/toplev.c -o
toplev.o

actually succeeds in generating 

/home/rshann/gub/target/mingw/build/cross/gcc-4.1.1/gcc/toplev.o

and likewise for 

 gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute
-DHAVE_CONFIG_H -I. -I.
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/.
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/../include
-I/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/../libcpp/include     
/home/rshann/gub/target/mingw/src/cross/gcc-4.1.1/gcc/combine.c -o combine.o

succeeds in generating combine.o (these are the commands that failed
during make).
re-starting make denemo after building these two .o files in this way
got me to another barf (gcc.log file):

...
MapLocate[/home/rshann/gub/target/mingw/install/cross/gcc-4.1.1-root/usr/bin] 
no files matching pattern: *
Running dump_file
  ('install',
'/home/rshann/gub/target/mingw/status/cross/gcc-4.1.1-gcc-4.1.1', 'w')
  {'permissions': 420}
 *** Stage: package (cross/gcc, mingw)
invoking false
Command barfed: false
Traceback (most recent call last):
  File "bin/gub", line 230, in exceptional_build
    build (settings, options, files)
  File "bin/gub", line 226, in build
    b.build_source_packages (names)
  File "bin/../gub/buildrunner.py", line 334, in build_source_packages
    self.spec_build (spec_name)
  File "bin/../gub/buildrunner.py", line 262, in spec_build
    deferred_runner.execute_deferred_commands ()
  File "bin/../gub/runner.py", line 167, in execute_deferred_commands
    cmd.execute (self.logger)
  File "bin/../gub/commands.py", line 75, in execute
    ignore_errors=self.ignore_errors)
  File "bin/../gub/loggedos.py", line 37, in system
    raise misc.SystemFailed (m)
SystemFailed: Command barfed: false

Which I don't know what to do with - I can handle reluctant compilers,
but what this is I don't know...

Richard




On Mon, 2009-11-02 at 12:35 +0000, Richard Shann wrote:
> On Sat, 2009-10-31 at 23:07 +0000, Richard Shann wrote:
> > I cannot get gub to build, and I don't think we can announce a release
> > without a windows binary. 
> > If we can't make progress via gub I will try and build denemo via the
> > old hand-built methods.
> 
> Well, hand-building on windows has failed too, because of gtksourceview,
> which we introduced for editing scheme, and which would require me to do
> more installing of gtk stuff under windows.
> I really don't want to put my effort in there. 
> 
> Perhaps we have to debug gub. After git pull in gub and make denemo the
> first signs of trouble are:
> 
> git: /home/rshann/gub/target/tools/root/usr/lib/libz.so.1: no version
> information available (required by git)
> /bin/sh: line 0: cd: /home/rshann/gub/downloads/denemo/git: No such file
> or directory
> it ends with
> 
> Command barfed: cd /home/rshann/gub/target/mingw/build/cross/gcc-4.1.1
> && make -j2
> tooldir='/home/rshann/gub/target/mingw/root/usr/cross/i686-mingw32'
> gcc_tooldir='/usr/i686-mingw32'
> 
> Which is a crash by the linker trying to build the compiler
>  - from the entry in the target/mingw/log/cross/gcc.log:
> 
> gcc   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
> -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute
> -DHAVE_CONFIG_H  -o cc1plus \
>             cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o
> cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o
> cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o
> cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o
> cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o
> cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o
> attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o
> c-dump.o winnt-cxx.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o
> cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o
> tree-inline.o cc1plus-checksum.o main.o
> libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
> collect2: ld terminated with signal 11 [Segmentation fault]
> make[2]: *** [cc1] Error 1
> 
> It seems like it would be a good idea to return to earlier versions of
> the tools - for example the ones that were working at the time of our
> last release. I don't know how this is managed though.
> 
> If anyone can help, please do.
> 
> Richard
> 
> 
> 
> 
> > Richard
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/denemo-devel
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel