On Mar 26, 2008, at 9:01 PM, David Fang wrote: >>> The package update I'm working on: >>> http://sourceforge.net/tracker/index.php?func=detail&aid=1926383&group_id=17203&atid=414256 >>> >>> The error message: >>> Error: package contains a dylib with no corresponding Shlibs entry >>> (/sw/lib/magic/tcl/exttosim.dylib -> exttosim.dylib 0.0.0) >>> If this is a private library, add >>> '!/sw/lib/magic/tcl/exttosim.dylib' to the Shlibs field. >> [more of these for other .dylib] >>> ... but I've done exactly that in Shlibs (no whitespace). >>> [puzzled look] >> >> I wonder if the validation-message is the problem. Notice that it >> first says that the target is "exttosim.dylib 0.0.0", but then later >> says that the Shlibs entry is "/sw/lib/magic/tcl/exttosim.dylib". >> Could you verify that the first line of the output of 'otool -L' on >> that file is indeed just "exttosim.dylib (compatibility version >> 0.0.0)", i.e., the simple filename rather than the full path? The >> Shlibs field is required to contain the install_name (what the file >> calls itself according to otool -L). > > % pwd > /sw/src/fink.build/root-magic74-7.4.59-1/sw/lib/magic/tcl > % otool -L exttosim.dylib > exttosim.dylib: > exttosim.dylib (compatibility version 0.0.0, current version > 0.0.0) > /usr/lib/libSystem.B.dylib (...) > /usr/lib/libgcc_s.1.dylib (...) > >> OTOH, that looks a lot like an upstream bug in the package too >> (similar to what dbreiser saw a week or so ago), where a library >> has a >> "simple filename" install_name instead of the full path to it. > > So it looks like we only get a simple filename, no full path. > What corrective action should be taken? > I only need this to work as a private shared library for this package.
What I had to do to quiet the validator in a more recent related problem was include: install_name_tool -id %p/lib/whatever/libfoo.1.dylib %i/lib/whatever/ libfoo.1.0.0.dylib as the last line of the InstallScript in the info file. If your package has a Makefile containing '-install_name exttosim.dylib' in LFLAGS, and it is accessible before you run the InstallScript, you can patch the install_name target there. I just had a package that ran qmake once for the upper level Makefile, but left Makefile generation of the lower level directories until 'make' was run on the top level. grr. Somewhere, you'll need to be certain that '- headerpad_max_install_names' is also set for LFLAGS, prior to building the library, or you may not be able to lengthen the install_name to include the full path. (If you patch -install_name before the build, you won't have this problem.) I'm relatively new at this level of info file mucking about, so there may be some information missing. I trust others will correct my misconceptions. Dave -- David Reiser [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
