On Mon, 23 Aug 2010 10:22:21 -0400, Jack Howarth wrote: On Mon, Aug 23, 2010 at 10:16:47AM -0400, Stefan Bruda wrote: > > Hi, > > > > At 09:14 -0400 on 2010-8-23 Jack Howarth wrote: > > > > > > On Sun, Aug 22, 2010 at 06:40:43PM -0400, Stefan Bruda wrote: > > > > > > > > Pdftk appears to install nicely, but every time I try to run it I get: > > > > > > > > < godel:cs/techreps > pdftk rt-testing.pdf background buresearch.pdf output rr.pdf > > > > dyld: _dyld_bind_fully_image_containing_address() error > > > > dyld: Symbol not found: _libiconv > > > > Referenced from: /opt/sw64/lib/gcc4.5/lib/libgcj.11.dylib > > > > Expected in: flat namespace > > > > in /opt/sw64/lib/gcc4.5/lib/libgcj.11.dylib > > > > ./background.sh: line 3: 49768 Trace/BPT trap pdftk $1 background ~//works/Tmpls/wwwcs/buresearch.pdf output $2 > > > > > > > > > > This sounds like a confused build of pdftk against libiconv. The pdftk > > > maintainer needs to make sure that the fink libiconv headers and libraries > > > are being used and not the system ones. > > > > > > nm /usr/lib/libiconv.2.4.0.dylib | grep _libiconv > > > 00000000000fa760 D __libiconv_version > > > 000000000001597c T _libiconv_relocate > > > 0000000000015972 T _libiconv_set_relocation_prefix > > > > > > nm /sw/lib/libiconv.2.4.0.dylib | grep _libiconv > > > 00000000000fd780 D __libiconv_version > > > 000000000000bd30 T _libiconv > > > 0000000000015290 T _libiconv_close > > > 0000000000017a70 T _libiconv_open > > > 00000000000187d0 t _libiconv_relocate > > > 0000000000018700 T _libiconv_set_relocation_prefix > > > 000000000000c1e0 T _libiconvctl > > > 000000000000bd90 T _libiconvlist > > > > > > I would do a 'otools -L' on pdftk and then recursively on all of > > > the libs it links against until you identify what has incorrectly > > > linked against the system libiconv instead of fink's. > > > > Interestingly enough, the 32-bit version also links against Apple's > > libiconv: > > > > < godel:~ > otool -L /opt/sw32/bin/pdftk > > /opt/sw32/bin/pdftk: > > /opt/sw32/lib/gcc4.5/lib/libgcj.11.dylib (compatibility version 12.0.0, current version 12.0.0) > > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > > /opt/sw32/lib/gcc4.5/lib/libstdc .6.dylib (compatibility version 7.0.0, current version 7.14.0) > > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0) > > /opt/sw32/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) > > > > Which makes me wonder why the 32-bit version works after all... > > Unfortunately I removed the 64-bit version from my system so I cannot > > confirm (or infirm) anything about it. > > Stefan, > I'll try to find some time to look at the x86-64 fink pdftk build tonight. > Jack
Two separate bugs here I see. Bug 1: pdftk linking against apple's libiconv while (apparently) compiling with fink's iconv headers at some level. Or at least some similar mixup. Might be as simple as missing BuildDepends, or -I or -L ordering, in that package. Or it could be solely fallout of the second bug. Bug 2: libgcj.11.dylib is underlinked. It directly uses libiconv (as was apparently built with fink's iconv headers, or at least somehow is matched to fink's version of it), but does not itself link against libiconv. That second propagates as a silent "you must directly link against fink's libiconv whenever you link libgcj.11.dylib" situation. Safer and saner to have every lib link against whatever libs are needed to resolve its directly-used symbols. $ nm -m /sw/lib/gcc4.5/lib/libgcj.11.dylib | grep undefined | grep -v \(from (undefined) external _environ (dynamically looked up) (undefined [lazy bound]) external _libiconv (dynamically looked up) (undefined [lazy bound]) external _libiconv_close (dynamically looked up) (undefined [lazy bound]) external _libiconv_open (dynamically looked up) $ otool -L /sw/lib/gcc4.5/lib/libgcj.11.dylib /sw/lib/gcc4.5/lib/libgcj.11.dylib: /sw/lib/gcc4.5/lib/libgcj.11.dylib (compatibility version 12.0.0, current version 12.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0) /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) dan -- Daniel Macks [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
