You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Peter Samuelson <pe...@p12n.org> on 2008/04/14 03:55:05 UTC
Re: svn commit: r30574 - trunk/build/ac-macros
[arfrever@tigris.org]
> * build/ac-macros/neon.m4
> (SVN_NEON_CONFIG): Set NEON_LIBS to `$neon_config --libs 2>/dev/null` if
> `$neon_config --la-file 2>/dev/null` prints nothing.
I'm a little confused - why not just run $neon_config --libs
unconditionally? Doesn't it always do the right thing?
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn commit: r30574 - trunk/build/ac-macros
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 14, 2008 at 10:20:08PM +0100, Joe Orton wrote:
> On Mon, Apr 14, 2008 at 10:40:24PM +0200, Stefan Sperling wrote:
> > On Mon, Apr 14, 2008 at 07:45:29PM +0100, Joe Orton wrote:
> > > > Linking against libneon.la doesn't cause these problems.
> > >
> > > Right - doing anything else is wrong. This change is not necessary for
> > > any released version of neon, so I can only presume it's to work around
> > > the broken Debian packaging of neon? If so it's certainly a bad idea;
> > > tolerating bad packaging behaviour just encourages it. Just get people
> > > to complain to Debian about the broken packaging, it will give them more
> > > motivation to fix it.
> >
> > I'm confused. FreeBSD seems to not install .la files at all[1].
>
> Good luck out there :)
Turns out my statement was wrong. My FreeBSD system *does* have plenty
of .la files in the /usr/local/lib directory.
> Some people who have experience of building complex cross-platform build
> systems think that libtool .la files are useful and design build systems
> to use them in various ways. Some people building single-platform Unix
> distributions think that libtool .la files are the root of all evil,
> because of some side-effects of their use which propagate shared library
> dependencies.
>
> So, the distro people (Fedora included, this is not just some
> anti-Debian bias of mine) expend a lot of engineering effort trying to
> eradicate .la files (rather than, e.g. changing libtool to avoid the
> undesirable side-effects). These two worlds then necessarily come into
> conflict when the build systems designed to use .la files start failing
> in their absence.
>
> I hope that's a fair characterisation of the situation ;)
Thanks. It's a pity so many people seem to insist on working around
libtool issues rather than fix their root causes. But given that I
tried to solve libtool issues with Subversion once as well, and failed,
I know how much fun that is...
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: svn commit: r30574 - trunk/build/ac-macros
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 14, 2008 at 10:40:24PM +0200, Stefan Sperling wrote:
> On Mon, Apr 14, 2008 at 07:45:29PM +0100, Joe Orton wrote:
> > > Linking against libneon.la doesn't cause these problems.
> >
> > Right - doing anything else is wrong. This change is not necessary for
> > any released version of neon, so I can only presume it's to work around
> > the broken Debian packaging of neon? If so it's certainly a bad idea;
> > tolerating bad packaging behaviour just encourages it. Just get people
> > to complain to Debian about the broken packaging, it will give them more
> > motivation to fix it.
>
> I'm confused. FreeBSD seems to not install .la files at all[1].
Good luck out there :)
> You are saying this is wrong. So does the Debian packaging policy[2].
I think that may be out-of-date with current Debian practice.
> Yet this neon.m4 patch was made because of an error building on Debian!
>
> I don't know what the correct thing to do is, but it seems strange that
> there are so deeply contradicting opinions on the issue.
Some people who have experience of building complex cross-platform build
systems think that libtool .la files are useful and design build systems
to use them in various ways. Some people building single-platform Unix
distributions think that libtool .la files are the root of all evil,
because of some side-effects of their use which propagate shared library
dependencies.
So, the distro people (Fedora included, this is not just some
anti-Debian bias of mine) expend a lot of engineering effort trying to
eradicate .la files (rather than, e.g. changing libtool to avoid the
undesirable side-effects). These two worlds then necessarily come into
conflict when the build systems designed to use .la files start failing
in their absence.
I hope that's a fair characterisation of the situation ;)
FWIW, in the Fedora neon package we use a trivial one-line sed command
to avoid propagating shared library dependencies, without removing the
.la file and breaking builds. This is the same solution I advocated to
Peter in the Debian bug report on this subject, way back when.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r30574 - trunk/build/ac-macros
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 14, 2008 at 07:45:29PM +0100, Joe Orton wrote:
> > Linking against libneon.la doesn't cause these problems.
>
> Right - doing anything else is wrong. This change is not necessary for
> any released version of neon, so I can only presume it's to work around
> the broken Debian packaging of neon? If so it's certainly a bad idea;
> tolerating bad packaging behaviour just encourages it. Just get people
> to complain to Debian about the broken packaging, it will give them more
> motivation to fix it.
I'm confused. FreeBSD seems to not install .la files at all[1].
You are saying this is wrong. So does the Debian packaging policy[2].
Yet this neon.m4 patch was made because of an error building on Debian!
I don't know what the correct thing to do is, but it seems strange that
there are so deeply contradicting opinions on the issue.
[1]: There are no .la files on my FreeBSD-7 system, and this post
implies that they skip them intentionally:
http://marc.info/?l=freebsd-ports&m=110295739806911&w=2
[2]: http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: svn commit: r30574 - trunk/build/ac-macros
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 14, 2008 at 10:57:49AM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> 2008-04-14 05:55 Peter Samuelson <pe...@p12n.org> napisał(a):
> > [arfrever@tigris.org]
> > > * build/ac-macros/neon.m4
> > > (SVN_NEON_CONFIG): Set NEON_LIBS to `$neon_config --libs 2>/dev/null` if
> > > `$neon_config --la-file 2>/dev/null` prints nothing.
> >
> > I'm a little confused - why not just run $neon_config --libs
> > unconditionally? Doesn't it always do the right thing?
>
> It doesn't.
> It wrongly prints additional data (LDFLAGS and dependent libraries).
That's necessary and correct when libneon is built statically; the
dependent libraries must be pulled in explicitly.
...
> Linking against libneon.la doesn't cause these problems.
Right - doing anything else is wrong. This change is not necessary for
any released version of neon, so I can only presume it's to work around
the broken Debian packaging of neon? If so it's certainly a bad idea;
tolerating bad packaging behaviour just encourages it. Just get people
to complain to Debian about the broken packaging, it will give them more
motivation to fix it.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r30574 - trunk/build/ac-macros
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2008-04-14 05:55 Peter Samuelson <pe...@p12n.org> napisał(a):
> [arfrever@tigris.org]
> > * build/ac-macros/neon.m4
> > (SVN_NEON_CONFIG): Set NEON_LIBS to `$neon_config --libs 2>/dev/null` if
> > `$neon_config --la-file 2>/dev/null` prints nothing.
>
> I'm a little confused - why not just run $neon_config --libs
> unconditionally? Doesn't it always do the right thing?
It doesn't.
It wrongly prints additional data (LDFLAGS and dependent libraries).
neon-config.in [1]:
<snip>
--libs)
LIBS="-lneon @NEON_LIBS@"
# Don't add standard library paths
if test "$prefix" != "/usr"; then
LIBS="-L${libdir} ${LIBS}"
fi
echo @user_LDFLAGS@ ${LIBS}
;;
</snip>
Linking against libneon.la doesn't cause these problems.
[1] http://svn.webdav.org/repos/projects/neon/trunk/neon-config.in