gcc error on Intel Mac
 

Hi everyone :)

I've run into trouble, while trying to install the new and funky gettext-0.15. I've never had problems installing gettext from source before, but I've only recently moved from my iBook to this MacBook. I brought a lot of my stuff with me, but installed the Dev Tools 2.3 update after the migration.

When I ran "sudo ./configure", I got:

I can post the config.log if that would be useful. I have gcc 4.01, on a MacBook running OSX 10.4.7, all updates current. I've tried this configure several times, but always get the same result. I haven't installed anything else from source since the migration, so this might be showing up a migration problem, for all I know. I doubt if the problem is specific to gettext, as it's a very simple package, for all its funkiness specific to my translation tasks, and an enquiry to the Translation Project list didn't start any hares.

Any advice or information would be very much appreciated. :)

The error message looks dismayingly like the one you get when you have no XCode installed at all.

BTW, the new XCode 2.4 is just out the door, perhaps it helps.

I suppose there are no fink/darwinport versions recent enough to do what you need ?

Thanks, voldenuit, that probably is the problem. I expect something was broken in the migration. I didn't realize XCode 2.4 was out: I han't received the email from MacUpdate, so you're ahead of them there. :)

I'm going to download it overnight. Hopefully tomorrow, when I install 2.4, my problems will be over. But installing 2.3 didn't solve everything. Do I need to tell XCode in some way to install from scratch? Maybe it's just updating my existing install, which may have holes in it.

Whoops, forot to answer your second question. No, unfortunately neither fink nor Darwinports have caught up with this release.

OK, it looks like something in my Dev Tools got broken during migration. Apparently, one shouldn't try to bring across from PowerPC machines to Intel-based ones anything more complex than your data files. The setup assistant doesn't tell you that, so I tried to bring most things. I find out what's broken when I try to use it. :S

In this situation, something was broken in Dev Tools, even though I had installed the 2.3 update after the migration. Before installing Dev Tools 2.4 (just out), I deleted the contents of my /Developer directory. For some reason I wasn't able to delete the dir. itself, but that didn't seem to matter. I was a bit worried, when I saw in "Custom Install" that the Dev Tools update would be 0 kb, but after the update, my /configure process ran perfectly, and make ran for a while, but bugged out on error

So, perhaps something is still broken in my Dev Tools. I had no problems installing this package (gettext) on my iBooks. To eliminate the Dev Tools possibility, my next step was to uninstall all Dev Tools as shown in each Dev Tools ReadMe (see info. quoted below). Each one, down the bottom, tells you how to uninstall the Tools, using a perl script included in /Developer, or from the CD/DVD/.dmg . This ran very quickly in the Terminal window.

Then I reinstalled the latest Dev Tools, and noticed to my satisfaction that the Dev Tools section itself this time was 272 MB, not 0 kb.

However, I struck the same error. I then decided to restart, to see if that cleaned up the reinstall, or solved problems in general, as it often does if a process has got itself tied up in knots.

The next episode in this thrilling series after I restart... ;)

----

Uninstalling Xcode Tools

To uninstall Xcode Tools on your system, from a Terminal window type:
To uninstall from the DVD, CD, or disk image that contains Xcode Tools, from a Terminal window type:
NOTE: The uninstaller that ships with previous versions of Xcode Tools or Developer Tools will not clean
everything off of your system properly. You should either use the one on the Xcode Tools 2.4 DVD, or you
should use the one installed when you installed Xcode Tools 2.4.

NOTE: Running the uninstall script from Xcode Tools will uninstall any previous installations of Mac OS X
Developer Tools or Xcode Tools releases.

----

"Makefile:1442: *** missing separator. Stop."

So there's a syntax error in the Makefile.

That would probably be gettext-tools/examples/Makefile, around line 1442. I bet there's a string like @SOMETHING@ that was supposed to be replaced by the command to do SOMETHING, except configure forgot to replace it. Or a variable whose contents have this problem. Let's see...

Check earlier in that Makefile to see how each of thost variables is defined, and look for mis-defined or blank ones.

For example, assuming the line number in the error is correct (sometimes they're off by one), the $(mkdir_p) is a likely candidate for the problem, so look around line 152 and see if it's @mkdir_p@ (mkdir -p -- or ../../build-aux/mkinstalldirs or ../../build-aux/install-sh -c are likely values. So why is mkdir_p mis-defined? Do you have any other "mkdir" commands in your PATH other than /bin/mkdir?

dmacks, thanks very much for your help. :)

I only have mkdir in /bin, and gnomevfs-mkdir in /sw/bin, both in my PATH. Nothing else. Do you think the gnomevfs one would cause a problem? It's probably a left-over from fink dependencies, anyway.

Earlier, this Makefile says: "mkdir_p = $(mkinstalldirs)".

So how is mkinstalldirs defined?

mkinstalldirs is defined as:
and I've uploaded that Makefile: you can see the whole thing at: http://www.riverland.net.au/~clytie/Makefile.

Your Makefile has:
That line 1442 is quite bogus indeed...I can't even imagine what it would supposed to be doing. A Makefile is usually generated from the Makefile.in in the same directory. Is that line there also? I don't see it in the file in the gettext-0.15 tarball.

The last section of the Makefile.in (from the same dir.) is the only part that seems to refer to it at all (AFAIK):
I don't know how that affects my system. "make --version" returns "GNU Make 3.80".

The line 1442 in your Makefile ($(MAKE) distdir1 with no indentation) is a clear syntax error...nothing at all to do with the variable substitution issues I had originally proposed. As a first attempt, try removing the line entirely. I don't think what you're doing (configuring, compiling, installing using a distribution tarball) uses any of the distdir* targets at all, so removing a line from a section of code that isn't used wouldn't affect anything.

OK, thanks dmacks, I'll report back. :)

Hmm, it doesn't seem to give an error (the top part of the output was all saying it had nothing to do, probably because it got that far before):
but as you can see, "gettext --version" still returns 0.14.5. Does the make result look OK to you?

If 'make' in the gettext-0.15 directory completes without errors, you've most likely compiled successfully.

However, 'make' just compiles, and commands typed at the command-line only look for executables in your PATH shell environment variable. I don't see where you placed this new 'gettext' in your PATH (or less-ideally, and indication that you adjusted PATH to see this new thing where it is), so 'gettext --version' is probably still/only seeing whatever other gettext commands are elsewhere on your system.

I compiled the new gettext in my user directory (~). Will that not install it in my PATH? Should I have compiled it in the root directory (/) instead? I was assuming that compiling anything on that disk would place the executable in my path. :(

I got a response on the Translation Project list: Bruno Haible says:

so I'm doing that now. Thanks for pointing out it wasn't my problem, or my system's problem, dmacks. I was going around in circles there.

It made OK this time. But I'm still getting the older version. :( Maybe I need to do my installs from /.

Nope, I tried installing from / and I still get the old version. I don't understand. :(

What exactly do you mean "installing from /"? That is the first time you've mentioned installing, which is a different issue than compiling...compiling compiles the binaries in the directory where the sources are (usually), installing places it somewhere for use.

Oh. My mistake. I meant running the install process: configure, make, make install (or whatever the INSTALL doc requires). I didn't know you had to do that in any particular directory.

I can't remember ever following the INSTALL instructions before and not seeing the change of --version. I'm confused.

Where did the "gettext" program get installed, and is that location in your PATH?

Since we last spoke, I've had to reinstall fink. It turned out that I'd brought parts of fink with me from ppc, so I couldn't use fink properly or update it. I had to delete my entire /sw dir. <wince> then reinstall from the fink Intel .dmg. I imagine this will help things in the long run, but currently it has broken quite a few. The latest gettext is not listed in fink, so I can't use it to solve this (yet).

Anyway, gettext is in my PATH (/usr/bin _and_ /sw/bin). However, as I said above, I have reservations about fink currently. Fink Commander's table is way off: it doesn't show me as having python, cvs or svn, for example. It probably says this because they're not installed in /sw, but they are installed on my disk. I think cvs came with the system, and I installed svn from source. Python is in /System/Library/Frameworks/Python.framework/Versions/2.3/bin/python but has an alias from /usr/bin . I can use cvs, svn and python, so I know they're there.

I'm starting to understand that fink operates in /sw, while software that comes with the system, and software installed from source, may be elsewhere on the disk. It reduces fink's usefulness, IMHO, if it can't identify software outside /sw.

However, at last fink is working. But I'm reluctant to install things via fink just because they don't show up in its table as installed, when I know some software exists on disk which fink isn't showing.

Fink does not and will likely never recognize arbitrary versions of software from arbitrary other providers that you have installed in arbitrary locations. There's just no way it can keep track of what is where, make sure that dependencies are correct, and that things are configured so that they can work well together. For a quick example, Apple's python is compiled for Aqua graphics whereas fink's is built for x11. Almost all of fink is built for x11, so if a fink package ran a python program intending it to be part of a larger x11 thing, it wouldn't suffice for that program to use aqua graphics.

Ah. Thanks for explaining that. It makes it difficult to know what I've lost by deleting /sw, but I expect I'll just have to replace things as I work them out. I still don't understand why installing gettext-0.15 from source didn't update my gettext, but I hope some of these things will make sense in time.

So, does this mean I need to reinstall python from fink, for any python script running on the command-line?

Well, I've worked out why my newer gettext doesn't show up. fink has installed the older one in /sw/bin, while the newer one is in /usr/bin, since I installed it manually, and /sw/bin is listed before /usr/bin in my PATH.

Since there are a lot of bits of gettext, I'm probably going to have to remove the older ones manually. :(

I wondered about putting /usr/bin ahead of /sw/bin in my PATH, but that would disable fink updating my software. <sigh>

I wish my shell would look for the most recent executable instead. :(

OK, finally fixed it. Deleted all the old bits of gettext in /sw/bin. Once I open a new shell, bash finds gettext in /usr/local/bin and:
Finally... :)

Instead of messing with things that other systems have created, put your own stuff in a different location and add that location to your PATH.

You should install your own things in /usr/local...that's why it's there:) Manually altering fink is a recipe for a small disaster because (as you now know) fink expects its things to be exactly as it set them. Manually altering apple stuff in /usr is a recipe for an even larger disaster, since apple's own software and pretty much every other software producer expects your system components to be approximately as apple sets them.

The difficulty is, as far as I can tell the PATH is used in order, and /sw/bin is first. I suppose I could create a new location and put that ahead of /sw/bin, or put /usr/local/bin ahead of /sw/bin, but I think that would stop me being able to access newer versions of software installed with fink. As long as there's an older version in the first item listed in my PATH, that will be used. That's what stopped me having access to my new gettext. So I really don't see how I can get around that.

Or have I got this wrong? :S

You want to stop thinking about getting access to whatever is newer - it doesn't work that way (as you've seen).
Instead, start thinking about it in terms of which folder you want to have precedence. If you want Fink stuff to have precedence over the Apple-supplied stuff, then put /sw/bin earlier in the PATH. If you want some other stuff (e.g. in /usr/local) to have precedence over the Fink stuff, put that location earlier in the PATH than /sw/bin
It won't stop you having access to Fink software, it will just mean that if there is a program with the same name in a folder that occurs earlier in the PATH, then that one program will be used in preference to other programs of that same name that are in other folders.

In particular, if you want some new version of 'gettext' to be used, the first thing you need to do is determine which of the various versions of 'gettext' is currently being used. If it isn't the version that you prefer (the version that you are about to update), then you either change your PATH or (more likely) you just rename the other versions (e.g. to 'gettext_fink' or whatever) so that they won't be used when you invoke 'gettext'.

The difficult thing is that packages have so many files. gettext, for example, installs a lot of tools. However, I will try renaming things in future. If I'm going to continue both using fink and installing some packages manually, putting either /sw/bin or /usr/local/bin first isn't going to solve my problem. One will give precedence to fink, and the other to my manually-installed software.

I want to continue using fink, because it handles dependencies, and is generally more reliable to use for installing packages. However, I regularly encounter software or versions of software I need which are not listed with fink, so I have to install them manually. So I end up with some software which exists in both locations. :(

It is confusing, but I will try the renaming process in future. Thankyou for your help. :)