On Sun, Apr 19, 2009 at 02:19:44PM -0400, Charles Lepple wrote: > I just finished installing Fink on 10.5/intel, and for grins, I tried > installing geda-gschem from some of the unofficial bindists. > > I uncovered a missing dependency in one of my package descriptions, > but I also found that something was pulling in the old gtk+-shlibs > package. > > Turns out that libstroke has two libraries, and one of them ties in > with GTK+. However, I noticed that 'otool -L' doesn't seem to print > this dependency information: > > $ otool -L /sw/lib/libgstroke.0.dylib > /sw/lib/libgstroke.0.dylib: > /sw/lib/libgstroke.0.dylib (compatibility version 1.0.0, current > version 1.5.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.1.1) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version > 1.0.0) > > But, > > $ nm /sw/lib/libgstroke.0.dylib |grep -w U > > shows a bunch of Xlib and GTK+ references. > > Is there another command besides 'otool -L' that I should use for > checking library dependencies on 10.5?
'otool -L' only lists the libs that are dynamically linked. It's quite possible to build a library and leave symbols unresolved (i.e., not link against the lib that defines them). It's then up to whatever uses the lib to link also the lib that does define them. So libgstroke isn't broken, but whatever uses libgstroke must somehow know to -lX11 -lgtk (or whatever) as well as -lgstroke. I use 'otool -hv', and if it does *not* say NOUNDEFS, there is almost certainly some symbol that is resolved by a lib that isn't dynamically linked. I use 'nm -m LIB.dylib | grep -v \(from | grep undefined' to see all the symbols that are not resolved by any of the dynamically linked libs. Not linking the dependent libs that define your symbols isn't truely broken, but it's not ideal because it makes users/packagers have to guess (and it also can make a lib unusable by dlopen or other mechanisms). However, sometimes it's unavoidable: two libs using symbols from each other (can't have circular linking) or one being runtime-loaded by the other as a plugin rather than dyld link (therefore can see symbols in the lib that loads it I think). IIRC, libgstroke intended to be usable with either glib/gtk+ or glib2/gtk+2, so if it links gtk+, then using it with gtk+2 is problematic because those two libs aren't binary-compatible. OTOH, it does compile using gtk+ headers, using it with gtk+2 is risky still. Probably best to roll a separate install_name of that pkg in a variant so can have gtk+ and gtk+2 libs, each fully linked to resolve all symbols. dan -- Daniel Macks [email protected] http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel
