xfig / date / libintl problem on a MacBook Pro

Ryan Schmidt ryandesign at macports.org
Thu Nov 4 17:51:49 PDT 2010


On Nov 4, 2010, at 19:41, Joel Friedman wrote:

> One of our math department IT guys found a fix:
> 
> From: http://blog.tsunanet.net/2009_04_01_archive.html
> (1) Edit /opt/local/etc/macports/macports.conf and add this line at the end of the file:
> binpath /bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin:/opt/local/sbin:/usr/X11R6/bin
> (2) port deactivate gettext
> (3) port install gettext
> (4) Remove the line you added in step 1.
> (5) Re-run the initial command you were running to resume the upgrade of whatever you were upgrading.
> 
> This worked and xfig works!

Let me see... the default binpath is:

binpath		/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin

So your change adds the old X11R6 path to the end (probably irrelevant to the issue) and moves the MacPorts /opt/local directories to after the system directories. So I guess the point of this change was to let the system's date command be found ahead of the one in the MacPorts directories. Ok. Probably not a fix I would have suggested, since we still need to figure out why you have a broken date command in /opt/local and how to fix it, but I'm glad it worked for you in this instance.

> The only problem is that /opt/local/sbin/date
> is still broken

You mean /opt/local/bin/date? There should not be a date command in /opt/local/sbin; it's not a server program, it's a regular program.

> (but I can bypass that with /bin/date or /opt/local/bin/gdate,
> so it's not so bad).

Hm, /opt/local/bin/gdate is provided by the coreutils port. /opt/local/bin/date, if it exists at all, should also have come from the coreutils port and should be exactly the same as gdate, so I'm surprised you're having trouble with one and not the other. In fact, /opt/local/bin/date should only exist if you installed coreutils with the +with_default_names variant, and the use of that variant is not recommended, so if you do want to have coreutils, I'd recommend you reinstall it without the +with_default_names variant. And if you don't particularly need coreutils, then just uninstall it.

You can also use "port provides /opt/local/bin/date" to confirm that it came from the coreutils port. If it came from a different port, uninstall that other port. If MacPorts says it did not provide that file, just delete it.


> I'd welcome suggestions for a fix.  Again, I've tried uninstalling and
> reinstalling, to no avail.

You've uninstalled and reinstalled coreutils already? Or just MacPorts base itself? Just reinstalling MacPorts base won't affect any of your installed ports.




More information about the macports-users mailing list