On Sat, Jan 17, 2009 at 04:00:10AM +0100, Greg Stein wrote:
> On Sat, Jan 17, 2009 at 01:29, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Fri, Jan 16, 2009 at 03:05:33PM +0000, Philip Martin wrote:
> >> Stefan Sperling <stsp_at_elego.de> writes:
> >> > A question I'd really like an answer to:
> >> > Does anyone know the rational behind what libtool does
> >> > and requires (using .la files to link against libraries),
> >> > and the rational behind not following these requirements
> >> > on some systems (not installing .la files on the system)?
> >> Libtool resolves library dependencies recursively. This makes libtool
> >> portable to lots of systems, but it upsets some distributions by
> >> introducing unnecessary explicit dependencies. See section 4:
> >> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#shlibdependency
> > Hmmm... I'm afraid I don't see the problem.
> > It says there was a workaround for the problem Debian is seeing (wasted
> > memory by loading some redundant code), which is to pass --as-needed
> > to ld. This does not work with libtool due to a bug in it, the bug ticket
> > they're referring to is from 2006.
> > To me this looks like either this bug is really hard to fix and
> > they are still trying to fix it after 3 years, or they are actually
> > pushing the problems of missing .la files to people like us in order
> > to save a small bit of memory -- like that was really worth the many
> > hours being wasted by Subversion developers to fix problems that are
> > specific to Debian...
> > So I don't understand what the gain is supposed to be.
> > OpenBSD runs on very low-end systems, too, and no one there deletes
> > .la files to save memory, to the best of my knowledge.
> Look. This is quite simple: .la files are not necessary to a system.
Obviously they're not needed when you're just using binaries linked
against the libs. But there's still this comment in all .la files
put there by libtool authors that seems to contradict what everyone
else keeps telling me:
# Please DO NOT delete this file!
# It is necessary for linking the library.
> My Mac doesn't ship with them, yet a hojillion things are able to link
> against my system libraries. There is no reason that we should
> *REQUIRE* those stupid .la files. Subversion was able to link against
> *most* of its dependencies without needing any .la files, *except* for
> serf and neon. Jeremy has now made it possible to link against them,
> too, when no .la files are present.
I know that that's great, because it makes Subversion work for
all known usage patterns of libtool out there. I don't object
to those changes at all.
> Could we avoid using libtool? Sure. Does it help us? Yes. As I recall,
> one of its benefits was around figuring out dependencies among dev
> libraries, vs installed libraries.
> But you know? I just don't care. I got our make file set up like 8
> years ago, and the linking rules generally work. I've forgotten most
> of that stuff cuz it just isn't interesting. So sure. Maybe we don't
> know much about the tool any more. Maybe we could work without it.
> Feel free to fix it. But until you do, I don't see what you're making
> such a big fuss about. Jeremy improved things. What's your issue?
I don't have an issue. The tree builds for me now. And like you,
I could not care less about what tools we use as long as the tools
I can use are FOSS and we can all compile our code[*].
I just find it odd that we had to go and fix anything about libtool
in the first place. Which in turn caused my build to break, which in
turn distracted me from working on #3354, which caused yet another day
of delay for the 1.6 release -- again, after the sqlite build issue the
other day, which had already had the same effect on me.
So I was starting to get a bit grumpy.
Now, I'm just trying to understand why that was the case, hence my
questions about libtool. It's simply a theoretical problem I'd like
to know an answer to.
[*] I cannot conveniently build with shared libs,
because if I do, libtool puts linker arguments in the wrong order,
causing unrelated svn libs from my system packages to be linked,
but that is a different issue. I just compile my dev builds
statically, and so far that worked well for me.
Received on 2009-01-17 05:05:53 CET