Happy to do it. Just prior to attempting another build, I
altered my build environment a bit. I installed libtool-1.3.5
and explicitly set the following environment variables:
setenv
LIBDIR "/sw/lib:/usr/lib"
setenv DYLD_LIBRARY_PATH "$LIBDIR"
setenv
CFLAGS "-I/sw/include
-I/usr/include"
setenv
LDFLAGS
"-L/sw/lib -L/usr/lib"
setenv
CXXFLAGS
"$CFLAGS"
setenv
CPPFLAGS
"$CXXFLAGS"
setenv
SED "/usr/bin/sed"
I also added these to the environment prefs for Fink Commander.
Then, from the terminal, I issued the command "fink install
libiconv". Yet, again, the build failed. The
following are the last few lines of output from the build
process:
136: creating config.h
137: ./configure: cd: /Volumes/Ellipsis/unix/Fink: No such file or directory
138: ### execution of ./configure failed, exit code 1
139: Failed: compiling libiconv-1.7-7 failed
137: ./configure: cd: /Volumes/Ellipsis/unix/Fink: No such file or directory
138: ### execution of ./configure failed, exit code 1
139: Failed: compiling libiconv-1.7-7 failed
Of course, I knew I had no directory name "Fink" at
that level, and then assumed something was happening in patching the
configure file. I moved my "/sw" directory to the root
of "/Volumes/Ellipsis" (also replacing the symbolic link on
the boot drive to point to the new location). Once I did this, I
haven't had but a single problem upgrading the base packages for
fink: libiconv, gettext, dpkg, bzip2, apt, etc. I built
and installed all these packages from the terminal. When I
updated via cvs through Fink Commander, building and installing
the new gettext went without a hitch. Only building a new
version of unzip caused a problem: crashing my loginwindow and
forcing a re-login. However, installing unzip from the terminal
using "fink install" worked fine.
What went wrong is still a mystery to me. All I do know is
that once I moved the "/sw" directory to the root of the
volume, all has seemed to work fine.
-- Charles
On 2003.08.20 (21:23 -0400), Alexander K. Hansen wrote:
By default you wouldn't have anything there; and sometimes libraries in
/usr/local/lib take precedence over those in /sw/lib, causing similar
problems to what you saw.
Can you make another attempt to upgrade libiconv (possibly using gcc
3.1) and post the output to the mailing list? It may be something
that's been seen before.
--
Alexander K. Hansen <[EMAIL PROTECTED]
On Wed, 2003-08-20 at 18:50, Charles Baldwin wrote:
> As a matter of fact, I do not. I thought perhaps I would but
> checking I verified that both /usr/local/lib and /usr/local/include
> are empty directories. My question now would be, should I have
[Edited]
