Presumably only a windows problem? No build issues w/ FC16_x64
Yes, only a windows problem -- we distribute a make.exe in the windows .zip file, and the one I included last time had some dll problems. It should be fixed in the v0_2_1 packages.
In the windows version, I also noticed a problem with the master/top demo Makefile for Windows. For me, it errored out trying to build the first demo. The error was:
C:\propgcc\demos\make
make -C toggle/cog_c_toggle # TODO build fails. fix later.
make[1]: Entering directory 'C:/propgcc/demos/toggle/cog_c_toggle'
make[1]: *** No rule to make target '#'. Stop.
make[1]: Leaving directory 'C:/propgcc/demos/toggle/cog_c_toggle'
make: *** [all] Error 2
I think I fixed it by putting the comment "# TODO build fails. fix later." on its own line in ./propgcc/demos/Makefile. Its been a while since my make101 class, but I dont _exactly_ remember if you can have comments on the same line as commands. Seems to work now, though.
Is there some specific reason why the propgcc compile has warnings as binutils (specifically) the ldlang.c file the warnings as errors are turned back on?
This causes osx 10.4 to fail because the declaration for links overshadows the global declaration. This same problem passed by in a previous file, although it got reported as a warning, it didn't prevent the compile.
any suggestions (other than remove the -werror flag)
I generally like to fix the actual problem instead of hacking makefiles after the fact.
Several people have reported problems with warnings as errors. This seems to be something to do with automake and/or configure differences on various platforms. On Ubuntu, at least, werror is not enabled, nor is it on Windows with mingw.
I'll try to dig in to this. You may have some luck with adding "disable-werror" to the configure options in jbuild.sh before doing the build. Unfortunately adding "enable-werror" does not reproduce the bug :-(.
It's possible it has to do with the version of bison/yacc/lex on the target system. I did find mention of this somewhere, and although I've upgraded yacc, lex and bison, (all of which were in bad need of upgrading) the problem has not gone away. I'm just puzzled why it showed up in one case, but not in an identical warning set earlier in the build process. Perhaps the lex/yacc bug still persists, only in much rarer circumstances.
Another thing I've noticed lately though is that most automake things think my system is a 10.3 system instead of it's actual 10.4, which is quite puzzling, though I don't know if it's relevant in this particular instance.
One thing is sure though, by the time I get this compiled properly, my system will be a whole lot more up to date. My python installation needed a facelift too, since 10.4 came with 2.3, and m4 also needed updated. This is fun, but it sure is work.
Comments
F
Yes, only a windows problem -- we distribute a make.exe in the windows .zip file, and the one I included last time had some dll problems. It should be fixed in the v0_2_1 packages.
Thanks,
Eric
In the windows version, I also noticed a problem with the master/top demo Makefile for Windows. For me, it errored out trying to build the first demo. The error was:
I think I fixed it by putting the comment "# TODO build fails. fix later." on its own line in ./propgcc/demos/Makefile. Its been a while since my make101 class, but I dont _exactly_ remember if you can have comments on the same line as commands. Seems to work now, though.
Anyway, that particular TODO comment is obsolete (it's done :-)) so I've just removed it.
Thanks,
Eric
This causes osx 10.4 to fail because the declaration for links overshadows the global declaration. This same problem passed by in a previous file, although it got reported as a warning, it didn't prevent the compile.
any suggestions (other than remove the -werror flag)
I generally like to fix the actual problem instead of hacking makefiles after the fact.
I'll try to dig in to this. You may have some luck with adding "disable-werror" to the configure options in jbuild.sh before doing the build. Unfortunately adding "enable-werror" does not reproduce the bug :-(.
Eric
Another thing I've noticed lately though is that most automake things think my system is a 10.3 system instead of it's actual 10.4, which is quite puzzling, though I don't know if it's relevant in this particular instance.
One thing is sure though, by the time I get this compiled properly, my system will be a whole lot more up to date. My python installation needed a facelift too, since 10.4 came with 2.3, and m4 also needed updated. This is fun, but it sure is work.