From: Daniel Macks <dmacks@ne...> - 2011-03-25 00:02:32
On Thu, 24 Mar 2011 19:32:28 -0400, Jack Howarth
On Thu, Mar 24, 2011 at 10:01:11PM 0100, Matthias Ringwald wrote:
> > could you try to help dyld finding libiconv by:
> > > fink install libiconv
> > > export DYLD_INSERT_LIBRARIES=/sw64/lib/libiconv.dylib
> > > pdftk...
> > I don't have a 64bit fink installation and cannot test this but
it looks like libgcj from the gcc45 package doesn't link explicitly
against libiconv and that's why it's not found. on my 10.6.6 it works
for i386 for some reason.
> The gcj compiler should have -L/sw/lib -liconv in its spec.
> gcj-fsf-4.5 -v --main=testme -O testme.java
-dynamic -arch x86_64 -macosx_version_min 10.6.7
-weak_reference_mismatches non-weak -o a.out -lcrt1.10.5.o
/var/tmp//ccVQdp14.o /var/tmp//ccfB7sJP.o -lgcc_s.10.5 -lgcc_ext.10.5
-lgcc -lgcj -lm -L/sw/lib -liconv -lpthread -lz -allow_stack_execute
-ldl -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
That seems to leave "anything that uses libgcj" at risk of library
search ordering confusion. The setup requires /sw/lib's libiconv.dylib,
but -L on the command-line take precedence over the spec flags. Also,
it makes a silent build-time requirement for /sw/lib/libiconv.dylib.
The package that uses a certain compiler has to know to
BuildDepends:libiconv-dev even though the package might have absolutely
no direct use of iconv? And when it's not found, it fails at either
build or runtime with a completely useless (unless you know this game)
error? I'm not sure anything is gained by avoiding directly linking
against a library that is directly used, rather than silently passing
the buck down the line.