libintl removal and a spurious libgcc

Ryan Schmidt ryandesign at
Wed Nov 21 18:33:29 PST 2007

On Nov 21, 2007, at 04:24, Alexy Khrabrov wrote:

> Greetings -- when trying to build glib2, I've stumbled upon the  
> libintl issue, which I've fixed according to

To be clear: it's not a libintl issue; it's an issue of any software  
installing a binary-incompatible newer version, and other ports that  
depend on that software having to be rebuilt, and MacPorts not having  
any built-in facility for doing so.

> The only speed-up I did was as follows: joined all port names with  
> spaces and ran single command like
> sudo port uninstall -f atk findutils gawk gettext glib2 gmake gnupg  
> gnutar gnutls gsed libgcrypt neon opencdk subversion subversion- 
> perlbindings texinfo wget whois
> Then I did port clean --archive <same long line with all port  
> names>, worked fine, too.
> Then I tried to install them anew with
> port install -f <same long line>
> (*) -- and fun started, gettext wanted to get installed again after  
> a few ports, said it can't and halted the sequence.  I've just cut  
> off the prefix of the port list and hit enter, and did this until  
> it all had run through.  Seemed OK.

"port -f install" is not recommended. Please see this ticket:

-f tells install (and upgrade) to forcibly rebuild all the  
dependencies, each time they're encountered, which could be many many  
times. You don't want this.

There's no need in your case to force the install. It'll go just fine  
without forcing.

> Unfortunately, I got a problem with iconv when I tried it recently,  
> and I've realized I might have another issue.  I got GNAT, a GCC  
> with Ada in it, for Mac from macada,org.  It installs into /usr/ 
> local/ada-4.3/, which I symlinked to /usr/local/ada/.  I might have  
> left /usr/local/ada/bin/ on the path in the shell where I did the  
> port rebuilds -- I'm no longer sure.  The strange thing is, the  
> error I get is
> /data/bruc/1/1g/unig iconv -f cp1251 -t utf8 < from > to
> dyld: Library not loaded: /usr/local/ada/lib/libgcc_s.1.0.dylib
>   Referenced from: /usr/local/lib/libiconv.2.dylib
>   Reason: image not found
> zsh: trace trap  iconv -f cp1251 -t utf8 < from > to
> There's no ibgcc_s.1.0.dylib in /usr/local/ada/lib/ at all! There are

So you have a broken libiconv in /usr/local/lib.

> /usr/local/ada/lib ls libgcc*
> libgcc_s.1.dylib  libgcc_s.10.4.dylib  libgcc_s.10.5.dylib   
> libgcc_s_ppc64.1.dylib  libgcc_s_x86_64.1.dylib
> Questions:
> -- for the list of ports such as those given by in  
> ProblemHotlist, how can we see which of them depend on anything  
> from /usr/local/ada/lib/ ?  Did it happen due to /usr/local/ada/bin/ 
> gcc on the PATH, or somehow else -- and why the non-existent 1.0  
> dylib?
> -- should I rebuild those?
> -- if I rebuild, is it OK to put all names on the line -- then how  
> do I prevent intermediate choking as in (*)?

You had a broken libiconv library directly in /usr/local and most  
software looks in /usr/local for dependencies when building. We have  
not yet found a satisfactory way to prevent software from doing this.  
Therefore, I recommend you do not have any software directly in /usr/ 
local if you want to use MacPorts. (/usr/local/anything is fine, so / 
usr/local/ada is not a problem.)

Make a new directory /usr/local-off and move all the standard  
directories (bin, etc, include, lib, libexec, man, sbin, share, var)  
out of /usr/local and into /usr/local-off. Now any software in  
MacPorts that was built against those rogue libraries should start  
breaking. When it does, rebuild that software, using:

sudo port -ncuf upgrade foo

You can also use "otool -L" against any of the libraries and binaries  
in /opt/local and see if anything in /usr/local shows up. If it does,  
rebuild the port that installed that library or binary. To find out  
what port that is, say e.g. "port provides /opt/local/lib/foo. 

More information about the macports-users mailing list