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).