[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