On Sun, Aug 30, 2009 at 07:48:33PM -0400, Daniel Johnson wrote:
>
> On Aug 30, 2009, at 7:23 PM, Jack Howarth wrote:
>
>> On Sun, Aug 30, 2009 at 06:50:42PM -0400, Daniel Johnson wrote:
>>>
>>> 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
>>>
>>
>> Would we really be able to survive entirely without static
>> libraries?
>> I would assume somethings in fink assume their presence to build. We
>> will
>> likely get some complaints if we remove them as I had to add them over
>> the
>> years to satisfy various users who wanted to create statically linked
>> binaries via fink for redistribution.
>> Jack
>
> Fink itself should almost never need static libs since the linker always
> uses a shared lib when it's available. It's actually impossible to make a
> truly static binary with OS X. And OS X usually works better with shared
> libraries since the OS can manage memory better and only load libs as
> they are needed, hence the "shared" part. Also, we can't even consider
> getting rid of .la files as long as we keep static libs around because
> libtool NEEDS that dependency info to resolve external symbols in static
> libs.
>
> Fink isn't designed for people to use parts of it outside of the Fink
> environment. If we can make that happen, fine, but we can't let that
> interfere with Fink itself.
>
> Just my opinion.
> Daniel
>
Daniel,
Then perhaps we should just have fink cvs purge *.la files when the
debs are created on x86_64 for now and see how well that works out. Considering
that folks need to do a clean bootstrap anyway because of the Xquartz issue
we might as well bit the bullet for x86_64 fink now. If folks have to many
problems in the near term they could always drop back to i386 fink until all
of the issues are solved with the .la removal in x86_64. I would be more
than happy to test that change.
Jack
------------------------------------------------------------------------------
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
