GNOME Bugzilla – Bug 430781
po/Makefile broken: "/bin/sh: line 1: -o: command not found"
Last modified: 2011-12-03 18:14:40 UTC
Please describe the problem: 1.)po Makefile broken The Makefile in the po directory is fubar and I have no idea how to fix it. workaround: grabbed the entire po directory from a configured 0.125 2.) something wrong with header-pane.cc pan/gui/header-pane.cc:655: error: 'gtk_tree_view_get_visible_range' was not declared in this scope workaround: sorry this one has me stumped grepping the source shows that this is the only instance of that function name anywhere. Steps to reproduce: 1. ./configure 2. make Actual results: make fails with bash saying line 1: -o: command not found, after workaround, says: (bunch of happy compilation noises) header-pane.cc: In member function 'virtual void pan::HeaderPane::on_tree_change(const pan::Data::ArticleTree::Diffs&)': header-pane.cc:655: error: 'gtk_tree_view_get_visible_range' was not declared in this scope make[3]: *** [header-pane.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Expected results: happy compilation noise Does this happen every time? yes Other information:
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of 429449 ***
My bad for reporting 2 problems in one bug, the gtk problem is indeed fixed in 0.128, thanks bunches. :) The po makefile is still incorrect and causes the following error (verbatim this time). I'll attach the makefile that I've got, would anything else help? I can set up ssh on my machine and poke a hole in the firewall and set up a dyndns address if you guys don't have access to a mac. Err, that may have sounded snide, it wasn't meant that way. anyway, the 0.125 po directory I just dropped in gave me a working frankenbuild that i'm using so I'm also lowering the severity (since there is a workaround that anybody using beta software should be able to figure out) jjlaptop:~/Applications/pan-0.128 jj$ make make all-recursive Making all in po file=`echo am | sed 's,.*/,,'`.gmo \ && rm -f $file && -o $file am.po /bin/sh: line 1: -o: command not found make[2]: *** [am.gmo] Error 127 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
Created attachment 86780 [details] the Makefile from the po subdirectory, also Makefile.in and Makefile.in.in zipped for convenience
I don't know what the cause for that is, either, but IMO it's not a Pan issue per se. This is a duplicate of another bug ticket that I've bumped upstream to get a second opinion. *** This bug has been marked as a duplicate of 426609 ***
It's not a duplicate of bug 426609. The issue here is that GMSGFMT is substituted as an empty string, meaning it isn't found. I believe AM_GLIB_GNU_GETTEXT is the macro that checks for this. The intltool m4 macros do not.
pan's configure.in uses AM_GLIB_GNU_GETTEXT. I don't know what the fix for this is and would welcome help.
Hi, I think we will need to see your config.log for the failing situation, please, if you could put it up here as an attachment. Outside of the log, some things to double-check: (1) be sure you're using gnome-common from svn as the pan2 build instructions webpage says … but they did issue a new release of gnome-common-2.18.0 that might be sufficient (older ones were most definitely _not_, hence the need to build it from svn). (2) don't rely on pkg-mgrs if they don't provide the latest GNU auto* tools (autogen, autoconf, automake, libtool, etc.) -- fetch & build these yourself manually if needed (but for darwin/osx you'll need the fink/macports hack that renames libtool[ize] to glibtool[ize]) then: export LIBTOOLIZE=glibtoolize to force scripts to see it that way, because you do _not_ want to override Apple's non-gnu libtool). (3) $PATH can find your msgfmt built from gettext -- and hopefully you've built the latest version of this (0.15), too, in the proper order vis-à-vis iconv (read READMEs; don't just rely on a pkg-mgr to do it: you'll need to build one then the other then clean/distclean the first to build all over again, this is the only way to get them to recognise each other). (4) as a brute-force workaround I mentioned some weeks ago on the maillist, try: export GMSGFMT=/path/to/your/bin/msgfmt (yes the 'G' points to the 'non-g' msgfmt ;) ) … and maybe just as well to do these while you're at it: export ICONV=/path/to/your/bin/iconv export INTLTOOL_ICONV=/path/to/your/bin/iconv export MSGFMT=/path/to/your/msgfmt export MSGMERGE=/path/to/your/msgmerge export XGETTEXT=/path/to/your/xgettext … before running ./configure again. fwiw my build-environment login does this & more every time I set it up. I could probably write one of those yellow & black "Dummies" books showing how to build open source projects on darwin/osx, there's quite a bit I've learned so far. (Please don't be offended: not implying anyone's level of education by mentioning this.) And by all means do report back here if any of this helps. :)
Holy crap! that's a lot of work. err, ok. I'll up the configure log, that's easy. Do you know of any gotchas that might break my existing fink install when I try this, and how to avoid them? Because there's prolly 80 hours of compile time sitting on my Mac that I REALLY don't want to break. Looks like I'll be learning a lot about my 'puter in the next few days. <sheepish grin>
Created attachment 87665 [details] config.log as requested OK, now I'll start working on building pan from scratch, I'll post again when I've got either an answer or a question I can't google, and freenode's #macosx can't answer.
Created attachment 88461 [details] config.log, pan-0.130 on MacOS X 10.4.9 (Intel) with MacPorts Attached the config.log showing this bug in pan-0.130 for MacOS X 10.4.9, MacPorts. It is interesting that this config.log shows that msgfmt was actually found (see lines 496 and 806).
(In reply to comment #10 from David Shochat) > Created an attachment (id=88461) [edit] > config.log, pan-0.130 on MacOS X 10.4.9 (Intel) with MacPorts > > Attached the config.log showing this bug in pan-0.130 for MacOS X 10.4.9, > MacPorts. > It is interesting that this config.log shows that msgfmt was actually found > (see lines 496 and 806). But look in your config.log at lines 877 & 928, those are the ones that count in this bug. Well, all you're doing is making me hate pkg-mgrs more & more. ;) I don't see pan-0.130 in the portfile at <http://svn.macosforge.org/repository/macports/trunk/dports/news/pan2/Portfile> ... it currently shows pan-0.129 still, so this is why I'm assuming you're trying to build 0.130 manually from svn or Charles' official tarball. The patches that MacPorts would apply are not needed if other requisite components at current releases are built properly. I don't know why they won't enforce this. Just about everything Gnome-wise seems to build fine right out of the tarballs and/or svn/cvs. I explained in detail the steps for building pan2 from svn for Jerry in my Comment #7 posted above in this ticket. I don't even see gnome-common as a dependency in the portfile, I explained the need for this above and won't repeat it here. I think this is unique for pan2/svn only; I wouldn't expect gnome-common to be in the long list of prerequisites anywhere else. Other things I question in your config.log -- not to put blame on anyone, but only wondering why MacPorts/Fink/etc. don't enforce more requisites than they do: (1) are you sure you have latest XCode installed? my version of gcc shows "build 5367" in my config.log, yours shows "build 5363". I don't know if Apple would change this just because you have x86 and I have ppc, I think the gcc build should show the same number. # file /usr/bin/gcc /usr/bin/gcc: symbolic link to `gcc-4.0' # file /usr/bin/gcc-4.0 /usr/bin/gcc-4.0: Mach-O fat file with 2 architectures I wouldn't think the same fat binary would have two different build numbers this way, but what do I know how Apple generates these tools. (2) why can't your gcc accept implicit definition of 'exit()'? see starting at line 133 in your config.log. I have no such problem here. (3) starting at line 160, why does your stdlib.h have that problem? mine does not. (4) your config.log can't find libintl.h (starting at line 531). I build latest iconv/gettext/etc. myself, again as explained to Jerry in my Comment #7 above. But building things manually without a pkg-mgr will install them in known standard places (usually /usr/local) where they will be found, so I have no problem here. If however MacPorts/Fink/etc. builds iconv/gettext/etc., their build system needs to provide additional -I include paths for configure to find them properly -- I see no -I/opt/whatever during the detecting of libintl.h in your config.log, but later on your log _does_ show including the necessary extra -I/opt stuff during detecting of glib/gtk/etc. Because your config.log can't find libintl.h, I can only presume your system does not have a current level of iconv/gettext/etc. installed with headers (-devel pkgs), which _will_ cause further troubles as many GNU apps need them, and so this comes full circle for this ticket because this is where msgfmt comes and why maybe the $[G]MSGFMT env-vars are not set properly for you. (5) But remember MacPorts/Fink/etc. have tons of overriding parms & patches that interfere with configure scripts & makefiles, so again I want to blame the pkg-mgr system for messing up this detection logic, coming full circle again in my "beef" against using any pkg-mgr at all. So again I repeat: try building everything by hand *without* pkg-mgr's involvement, put them in /usr/local, let those components be installed naturally without such artificial coercion. As my Comment #7 says. ;) (6) Otherwise this bug may need to be routed to the MacPorts team for *more* patching so it can detect your libintl.h and also to set $[G]MSGFMT on its own. Since I don't use pkg-mgrs and don't believe/trust them, they probably won't listen to me. ;) (7) Using a pkg-mgr further causes problems because they usually wipe-out your own env-var settings. This means some of my workarounds in my comment #7 can't be used under MacPorts/Fink/etc. because your exported settings would disappear when you invoke their tools. Don't ask me why, this is probably the top-most reason I don't use them. Would you be able to rebuild everything manually as my comment #7 suggests? Else I can only suggest opening a bug with MacPorts from this point. They may in turn involve the other gnome teams esp. if gnome-common or intltool are needing help to scan non-standard /opt paths (wherever Charles has been bumping some of these build problems). But right now I put the blame on MacPorts and Fink. Sorry for being so obnoxious about it, but maybe this will show how strongly against using pkg-mgrs I am. ;)
Created attachment 91070 [details] Ubuntu 7.04 Feisty desktop i386 config.log showing GMSGFMT='' as well. Ubuntu 7.04 Feisty desktop i386 config.log also shows GMSGFMT='' as well after running .configure from pan 0.131 source.
No offense intended SciFi; after about 5 hours work over about two months, all I've got is most of the prereqs downloaded, about 8 headaches, and the working copy of .128 that I started with. Package managers are wonderful for the happily clueless. :D Love and luck, I'll continue to support you guys financially, and with bugreports with what followup I can. You're all doing Good Things® and I appreciate you for them, but I am NOT a programmer. Be Masterful, Do Good, and Have Abundance. -Jerry
Googling "ubuntu feisty GMSGFMT=''" gave me http://ubuntuforums.org/archive/index.php/t-417124.html "The guy says to install the gettext package. I did and it is now compiling." Ubuntu 7.04 (Feisty) installs gettext-base by default, but does not install gettext. So, after 'sudo apt-get install gettext', I now have pan 0.131 compiled and running.
W00t, we finally have resolution on this.