You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2009/01/16 10:02:04 UTC
Re: svn commit: r35279 - trunk/build/ac-macros
Okay. Checked in now. Jeremy: please update the log msg as
appropriate; I don't have all the details to write a good one.
Stefan: does this fix it for you?
Also.. jeremy: maybe there is a different flag? LIBS or LIBDIR or
somesuch? Maybe LDFLAGS is right, but just wanted to make sure the
change was at the right granularity.
Cheers,
-g
On Fri, Jan 16, 2009 at 10:59, Greg Stein <gs...@gmail.com> wrote:
> Author: gstein
> Date: Fri Jan 16 01:59:01 2009
> New Revision: 35279
>
> Log:
> Fix linking against serf on some platforms.
>
> * build/ac-macros/serf.m4: add serf's libdir to LDFLAGS
>
> Modified:
> trunk/build/ac-macros/serf.m4
>
> Modified: trunk/build/ac-macros/serf.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/serf.m4?pathrev=35279&r1=35278&r2=35279
> ==============================================================================
> --- trunk/build/ac-macros/serf.m4 Thu Jan 15 21:56:39 2009 (r35278)
> +++ trunk/build/ac-macros/serf.m4 Fri Jan 16 01:59:01 2009 (r35279)
> @@ -48,6 +48,7 @@ AC_DEFUN(SVN_LIB_SERF,
> SVN_SERF_INCLUDES="-I$serf_prefix/include/serf-0"
> SVN_SERF_LIBS="-lserf-0"
> SVN_SERF_EXPORT_LIBS="-L$serf_prefix/lib -lserf-0"
> + LDFLAGS="$LDFLAGS -L$serf_prefix/lib"
> elif test $serf_found = "reconfig"; then
> serf_found=yes
> fi
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=1028296
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1028304
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Jeremy Whitlock <jc...@gmail.com>.
> Building against Neon without libneon.la was possible since r34994...
Yeah but you couldn't build without it until r35262.
--
Take care,
Jeremy Whitlock
http://www.thoughtspark.org
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Arfrever Frehtes Taifersar Arahesis <Ar...@GMail.Com>.
2009-01-17 19:29:54 Jeremy Whitlock napisał(a):
> > Look. This is quite simple: .la files are not necessary to a system.
> > 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.
>
> Agreed. This was the reasoning behind the change in the first place.
> I think the new solution is the best of both worlds. If you have the
> luxury of having the .la files, use them but if not, tell the linker
> what is necessary to link against serf and be done with it. We can
> now build against binary installations of neon and serf with and
> without the.la files which makes it easier for anyone to build/install
> Subversion.
Building against Neon without libneon.la was possible since r34994...
--
Arfrever Frehtes Taifersar Arahesis
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Jeremy Whitlock <jc...@gmail.com>.
> 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.
Well, the solution works with and without the .la files so we are in a
good situation. As for this comment, I can see libtool's stance of:
If you don't have the .la files, don't be upset if libtool can't do
its job. The problem is that if we require the .la files, we place a
great deal of work on the binary maintainers. A lot of package
maintainers build in one dir, install into another. That renders the
.la files useless unless you do some sed magic on them. Can it be
done? Sure but requiring a maintainer to massage the .la files and
then ship them only for Subversion is a tough pill to swallow. As it
stood before the changes, anyone without the .la files would have to
rebuild neon and serf just to get Subversion to build and install.
Again, another tough pill to swallow in some cases. The new solutions
works and works with both scenarios with and without the .la files. I
think we're good.
> 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[*].
Thanks for working with me on getting this resolved the right way for
all known parties.
> 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.
I'll take the blame here. Sorry for the hold up. This is one of
those "it works on my box" scenarios where I had to go to another
operating system to reproduce the problem you were running into. I'll
take note to check my Linux box next time I change linker logic before
committing. To my defense though, my Mac handled it just find. :P
--
Take care,
Jeremy Whitlock
http://www.thoughtspark.org
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Jan 17, 2009 at 04:00:10AM +0100, Greg Stein wrote:
> On Sat, Jan 17, 2009 at 01:29, Stefan Sperling <st...@elego.de> wrote:
> > On Fri, Jan 16, 2009 at 03:05:33PM +0000, Philip Martin wrote:
> >> Stefan Sperling <st...@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.
Stefan
[*] 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.
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Jeremy Whitlock <jc...@gmail.com>.
> Look. This is quite simple: .la files are not necessary to a system.
> 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.
Agreed. This was the reasoning behind the change in the first place.
I think the new solution is the best of both worlds. If you have the
luxury of having the .la files, use them but if not, tell the linker
what is necessary to link against serf and be done with it. We can
now build against binary installations of neon and serf with and
without the.la files which makes it easier for anyone to build/install
Subversion.
--
Take care,
Jeremy Whitlock
http://www.thoughtspark.org
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Jan 17, 2009 at 01:29, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Jan 16, 2009 at 03:05:33PM +0000, Philip Martin wrote:
>> Stefan Sperling <st...@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.
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.
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?
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1029920
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 16, 2009 at 03:05:33PM +0000, Philip Martin wrote:
> Stefan Sperling <st...@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.
Stefan
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Philip Martin <ph...@codematters.co.uk>.
Stefan Sperling <st...@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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1028807
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 16, 2009 at 11:02:04AM +0100, Greg Stein wrote:
> Okay. Checked in now. Jeremy: please update the log msg as
> appropriate; I don't have all the details to write a good one.
>
> Stefan: does this fix it for you?
Yes, it fixes the build for me, thanks.
I'm still wondering though why we need to avoid .la files.
My understanding is that libtool is supposed to be used
with .la files (they have a comment at the top saying you
should not delete them).
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)?
If no one can answer this question, I would say that I find
it disturbing that we are relying on a tool which we don't
know how to use properly.
Stefan
Re: svn commit: r35279 - trunk/build/ac-macros
Posted by Jeremy Whitlock <jc...@gmail.com>.
:> Okay. Checked in now. Jeremy: please update the log msg as
> appropriate; I don't have all the details to write a good one.
It looks fine to me.
> Also.. jeremy: maybe there is a different flag? LIBS or LIBDIR or
> somesuch? Maybe LDFLAGS is right, but just wanted to make sure the
> change was at the right granularity.
Well, LDFLAGS is what is used by zlib when in a similar situation so
that's what I went with. I also think LDFLAGS is probably the better
solution because all we need to do is tell the linker where the
libraries are located. Once that is done, -lserf-0 is found properly.
As of r35291, I have a solution that is the best of both worlds. The
default is to use libtool but if the necessary libserf-0.la file is
missing, fall back to the changes made yesterday which appears to be
graceful and in line with how other deps do this.
--
Take care,
Jeremy Whitlock
http://www.thoughtspark.org