On Aug 30, 2009, at 6:20 PM, David R. Morrison wrote:


On Aug 31, 2009, at 6:22 AM, Martin Costabel wrote:

Jack Howarth wrote:
 Considering that Apple's X11 developers are recommending that
we tell user to nuke their installations and rebuild everything
from scratch under Snow Leopard as well as never install .la
files, why don't we take this opportunity to do just that. It may
cause some minor breakage in fink unstable (which should be
easily fixable), but we could modify fink to automatically purge
any *.la files from the packaged files in the debs created. Sure
we will need to correct some info file to remove the *.la from
the file list but that will be trivial. We really should embrace
this opportunity to purge out *.la files from 10.6 and later
releases.

Is anyone aware of a large-scale test of what happens if we indeed let libtool build all those *.la files and then simply remove them, despite
each one of them screaming

 # Please DO NOT delete this file!
 # It is necessary for linking the library.

? Are there situations where they are really useful or perhaps even needed?


I think we could cope without .la files if we had to, provided that they were all gone. But I don't see any good reason for following those apple developer's suggestion in this case.

What we might consider doing, though, is this: removing any references to non-fink-created .la files from fink-created .la files. I haven't really thought through how hard it would be, but there may be some nice incantation we could put at the end of install scripts which would do it.

I've been cleaning the .la files in my library packages for a while now. I use perl -pi -e "s/dependency_libs=.*$/dependency_libs=''/" %i/ lib/*.la in InstallScript, which just clears dependency_libs altogether. This is almost always safe, as long as you DON'T build static libraries. When linking to static libraries, dependency_libs is necessary since static libs don't encode where to resolve external symbols. Shared libraries DO encode this, so they don't need to link to indirect libraries. As a side benefit, You no longer need to BuildDepend on indirect dependencies, which makes it much easier when some dependency down the chain changes.

So, for example, you can depend on libcurl4 or svn15 and not have to care about their dependencies. I can change (and have done so) their dependencies without breaking anything.

Do note that you also need to check foo-config and/or libfoo.pc files for such dependencies too, and that can't easily be automated. Oh, and sometimes with libtool2 generated .la files you have to clean inherited_linker_flags too.

Daniel

Attachment: smime.p7s
Description: S/MIME cryptographic signature

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to