make problem with latest alpha package?

Comments

• frank freedman Posts: 1,983

  2011-12-13 07:25 edited 2011-12-13 07:25

  Presumably only a windows problem? No build issues w/ FC16_x64
  F
• ersmith Posts: 6,161

  2011-12-13 08:31 edited 2011-12-13 08:31

  frank freedman wrote: »

  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.
  
  Thanks,
  Eric
• Daniel Harris Posts: 207

  2011-12-13 12:20 edited 2011-12-13 12:20

  Thanks for posting Jazzed!
  
  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.
• ersmith Posts: 6,161

  2011-12-14 03:35 edited 2011-12-14 03:35

  Hmmm, funny that you had that problem Daniel -- I thought the Windows make program should act the same as the Linux one.
  
  Anyway, that particular TODO comment is obsolete (it's done :-)) so I've just removed it.
  
  Thanks,
  Eric
• softcon Posts: 217

  2011-12-18 14:06 edited 2011-12-18 14:06

  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.
• ersmith Posts: 6,161

  2011-12-18 16:13 edited 2011-12-18 16:13

  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 :-(.
  
  Eric
• softcon Posts: 217

  2011-12-18 17:39 edited 2011-12-18 17:39

  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.