help-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: prob. with gettext libiconv circular dependancies in Darwin (Mac OS


From: Guy Harrison
Subject: Re: prob. with gettext libiconv circular dependancies in Darwin (Mac OS X)
Date: Wed, 30 Jun 2004 13:58:49 +0100
User-agent: KNode/0.7.2

Gary Ebert wrote:

> Hello all:
> I hope this is the right forum for this question.  I am trying to
> install gtk+ on Darwin 6.8 (Mac Os X 10.2.8) -- so I can install
> gnu-gradebook for my wife.  I have X-windows up and running fine and I
> think I have all of the rest of the prerequisites installed but I just
> can't get libiconv and gettext working.
> 
> 
> After running configure I get the the following error:
> checking for iconv_open in -liconv... no
> configure: error: *** No iconv() implementation found in C library or
> libiconv

The sordid details will be in config.log (object folder). Sometimes libs do
exist but don't get seen.

> So according to the documentation (for libiconv) I should make and
> install libiconv.  Then make and install gettext.  And finally make and
> install libiconv again (after doing a make distclean in libiconv).  So
> the long and the short of it is that it doesn't work.  I keep getting
> the same errors over and over again. The errors are included below.  Any
> help would be greatly appreciated!  I just don't know what is going
> wrong.  I've installed many other packages w/ no problem on this
> computer (and many others) but I just don't understand this one.
> 
> I do all of the builds etc. as root (not sudo'd for those of you who
> know what I mean)
> 
> Finally if this is the wrong forum for this problem please accept my
> apology and direct me to the correct forum!
> 
> Thanks in advance,
> 
> Gary
> 
> --
> Gary Ebert
> Silver Spring, MD
> garyebert@verizon.net
> 
> 
> ***********************errors begin
> 
> ok in libiconv (version 1.9.1)
> 
> ./configure probs

Er, is 'probs' a mac thing?

> checking for GNU gettext in libc... no
> checking for iconv... (cached) no, consider installing GNU libiconv
> checking for GNU gettext in libintl... no
> 
> make probs
> none no errors no warnings

RE above.

$ make
 
> make install probs
> 
> ocalhost:local/src/libiconv-1.9.1] gary# make install
> builddir="`pwd`"; cd libcharset && make all && make install-lib
> libdir="$builddir/lib" includedir="$builddir/lib"
> cd lib && make all
> make[2]: Nothing to be done for `all'.
> cd lib && make all
> make[2]: Nothing to be done for `all'.
> cd lib && make install-lib libdir='/usr/local/src/libiconv-1.9.1/lib'
> includedir='/usr/local/src/libiconv-1.9.1/lib'
> /bin/sh ../autoconf/mkinstalldirs /usr/local/src/libiconv-1.9.1/lib
> /bin/sh ../libtool --mode=install /usr/bin/install -c -m 644
> libcharset.la /usr/local/src/libiconv-1.9.1/lib/libcharset.la
> /usr/bin/install -c -m 644 .libs/libcharset.1.0.0.dylib
> /usr/local/src/libiconv-1.9.1/lib/libcharset.1.0.0.dylib
> /usr/bin/install: .libs/libcharset.1.0.0.dylib: No such file or directory

Is there such a file? If there is then it looks like a libtool install
issue. If not then a make issue (which may be down to a libtool link
issue).

> make[2]: *** [install-lib] Error 71
> make[1]: *** [install-lib] Error 2
> make: *** [lib/localcharset.h] Error 2
> 
> huh?
> 
> I've also tried running configure with the prefix set to /usr/local (as
> opposed to /usr/local/src/libiconv-1.9.1) with the same results

Remember to "make uninstall" on the failed install attempts (before
reconfiguring/distclean) so as not to leave partial installations all over
the place. Such things can bite later when a subsequent 'configure' (for
another package) spots a partial one in preference to a complete one.

> now for gettext (version 0.14.1)
> ./configure probs
> checking for iconv... no, consider installing GNU libiconv
> shows up several times
> 
> make probs
> (cd .libs/libasprintf.lax/libstdc++.a && ar x /usr/local/lib/libstdc++.a)
> . . .
> 
> /usr/bin/ld: Undefined symbols:
> _main
> ___eprintf

An OSX forum would likely know the problem here straight off. No way to be
certain but taking everything in account it tends to point toward a linker
issue (via libtool). Now, it may be as trivial a fix as tweeking some
settings, or it could involve some patches. Best to see if there aren't
official releases. Reason for that is from experience: when I first
encountered cygwin I just hacked my way through failed builds. Things
worked just fine but I'd done it differently, which meant everytime I
grabbed an official package which relied on a hacked one, I had to hack the
official to suit. Fwiw, using cygwin as an example again, on occasion the
fault is as trivial as wrong file extender: build system has a bug and uses
unix scheme then can't find that file later. eg: foo/foo.exe
libfoo.so*/libfoo.dll/libfoo.dylib (or whatever).


-- 
Guy Harrison


reply via email to

[Prev in Thread] Current Thread [Next in Thread]