On 11-Nov-07, at 10:27 PM, Daniel Macks wrote: > The main > gain would be when a mid-level library stops using some low-level > library as its back-end...high-level stuff wouldn't list the low-level > lib, so these hidden changes wouldn't affect dependencies (build or > run) of the high-level things.
You are right, of course, that's the gain. Take libcurl as an example. If it is rebuilt for a newer crypto library, there would be no need to, in turn, rebuild stuff that does https:// using libcurl. Without this flag, assuming the install_name of the crypto lib changed, all users of libcurl would also need to be rebuilt. Yay! Then, as jfm noted, libtool will jump up and bite you. The dependency_libs line in libcurl will have the crypto library's .la file listed, so anything wanting to link libcurl will also need the crypto libs .la file etc etc. Debian patches their libtool so that it does not list these indirect deps in dependency_libs, unfortunately this patch sometimes breaks other systems, one of which, at least used to be, darwin. Libtool on darwin links everything in the dependency chain direclty (this was done because the linker required it at the time for two level namespace linking), this is reduced slightly in libtool-2.x (vaporware) by the use of -dylib_file. As far as I know, nobody is currently looking at fixing these libtool issues (too much crap in dependency_libs, link_all_deplibs being broken etc.) Peter ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel