You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@redhat.com> on 2009/02/17 17:03:42 UTC
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
On Tue, Feb 17, 2009 at 03:27:34PM -0000, Mladen Turk wrote:
> Author: mturk
> Date: Tue Feb 17 15:27:33 2009
> New Revision: 745119
>
> URL: http://svn.apache.org/viewvc?rev=745119&view=rev
> Log:
> Add --disable-version option to configure.
> This allows to create non versioned apr libs using libtool
Why is this useful? Joe
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Feb 23, 2009 at 17:40, Mladen Turk <mt...@apache.org> wrote:
>...
> OK. I've remove it,
> although still don't understand why something optional is
> such a big deal, namely because it doesn't change anything
> regarding default build.
When the ABI can potentially change, then application developers need
to be wary of what they're linking against. As long as we can
confidently tell people "the ABI is rock solid", then those devs won't
have to worry. Introducing ABI variability into the APR ecosystem is a
Bad Thing.
>> If you are bundling up a custom application, you can easily add some
>> later shell script to move around files however you want them to be called.
>
> It's not that easy. It requires patching the configure.in,
> but we'll have to live with that. The point is that moving isn't
> enough. One needs to rewrite the apr-config and .lai file as well,
> so making a patch to configure.in is much easier.
If APR is being packaged into a .jar for private use, then what do you
need apr-config for?
Cheers,
-g
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Mladen Turk <mt...@apache.org>.
Paul Querna wrote:
> Joe Orton wrote:
>> On Wed, Feb 18, 2009 at 10:00:49AM +0100, Mladen Turk wrote:
>>> Joe Orton wrote:
>>>> So you really need a hack to the configure script which introduces a
>>>> new way to break ABI compatibility with the standard build, just so
>>>> you can avoid copying some symlinks in an obtuse distribution
>>>> mechanism? I don't see it.
>>> First of all it's not a hack.
>>> It's a perfectly legitimate way how you can build a shared library.
>>>
>>> Any other discussion would only lead to philosophical and
>>> political rather then technical reasons.
>>> It's off by default, and if you don't need it, don't use it.
>>
>> If you don't have any technical justification for this other than "it
>> lets me avoid copying a symlink" then I'm -1 on this change:
>>
>> 1) A non-versioned library build has a different ABI to the standard
>> build, because the library SONAME changes.
>> 2) Ballooning the number of possible APR ABIs is bad.
>>
>> 3) It is trivially simple to work around the problem of having to copy
>> symlinks without adding complexity to the APR build system.
>>
>> We discuss changes on their technical merits. Saying "it's perfectly
>> legitimate" doesn't add much to that debate. It would be "perfectly
>> legitimate" to introduce a configure switch to make the library SONAME
>> be "libfluffy-pink-clouds-1.so"; no laws would be broken that I'm
>> aware of.
>
> +1, I agree with Joe on this. This switch should not be present.
OK. I've remove it,
although still don't understand why something optional is
such a big deal, namely because it doesn't change anything
regarding default build.
> If
> you are bundling up a custom application, you can easily add some later
> shell script to move around files however you want them to be called.
>
It's not that easy. It requires patching the configure.in,
but we'll have to live with that. The point is that moving isn't
enough. One needs to rewrite the apr-config and .lai file as well,
so making a patch to configure.in is much easier.
Regards
--
^(TM)
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Paul Querna <ch...@force-elite.com>.
Joe Orton wrote:
> On Wed, Feb 18, 2009 at 10:00:49AM +0100, Mladen Turk wrote:
>> Joe Orton wrote:
>>> So you really need a hack to the configure script which introduces a
>>> new way to break ABI compatibility with the standard build, just so you
>>> can avoid copying some symlinks in an obtuse distribution mechanism? I
>>> don't see it.
>> First of all it's not a hack.
>> It's a perfectly legitimate way how you can build a shared library.
>>
>> Any other discussion would only lead to philosophical and
>> political rather then technical reasons.
>> It's off by default, and if you don't need it, don't use it.
>
> If you don't have any technical justification for this other than "it
> lets me avoid copying a symlink" then I'm -1 on this change:
>
> 1) A non-versioned library build has a different ABI to the standard
> build, because the library SONAME changes.
>
> 2) Ballooning the number of possible APR ABIs is bad.
>
> 3) It is trivially simple to work around the problem of having to copy
> symlinks without adding complexity to the APR build system.
>
> We discuss changes on their technical merits. Saying "it's perfectly
> legitimate" doesn't add much to that debate. It would be "perfectly
> legitimate" to introduce a configure switch to make the library SONAME
> be "libfluffy-pink-clouds-1.so"; no laws would be broken that I'm aware
> of.
+1, I agree with Joe on this. This switch should not be present. If
you are bundling up a custom application, you can easily add some later
shell script to move around files however you want them to be called.
-Paul
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Mladen Turk <mt...@apache.org>.
Joe Orton wrote:
> On Wed, Feb 18, 2009 at 10:00:49AM +0100, Mladen Turk wrote:
>> Joe Orton wrote:
>>> So you really need a hack to the configure script which introduces a
>>> new way to break ABI compatibility with the standard build, just so you
>>> can avoid copying some symlinks in an obtuse distribution mechanism? I
>>> don't see it.
>> First of all it's not a hack.
>> It's a perfectly legitimate way how you can build a shared library.
>>
>> Any other discussion would only lead to philosophical and
>> political rather then technical reasons.
>> It's off by default, and if you don't need it, don't use it.
>
> If you don't have any technical justification for this other than "it
> lets me avoid copying a symlink" then I'm -1 on this change:
>
I didn't think it is that important (well I thought it was
self understood). Anyhow ...
If you think of APR as a system library used by multiple
applications, then this usage is bogus of course.
I doubt anyone would even consider doing that.
However if you create a self-contained application that uses
APR, and distribute that application detached from the
system then it's up to you to maintain the versioning.
Weather that's a smart decision its up to app producer
to decide.
As an example take a look at httpd build by --with-included-apr
APR in this case is detached from whatever apr exists in the
universe. IMO it's pointless to keep apr so symlinks, just like
we don't maintain them for modules.
However that wasn't the reason for this.
I'm working on a project (will be part of jakarta)
that uses virtual file system (you might guess it doesn't
support the symlinks) for distributing the java and
native code together in a single archive. Symlinks are not
supported and referencing the .so directly by
version number introduces complexity both during build and
runtime loading.
So, IMHO at the end this doesn't differentiate from the
--disable-threads on a system that has threading support.
If someone chooses to build apr without threads it must
be aware it broke the ABI.
Regards
--
^(TM)
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Feb 18, 2009 at 10:00:49AM +0100, Mladen Turk wrote:
> Joe Orton wrote:
>> So you really need a hack to the configure script which introduces a
>> new way to break ABI compatibility with the standard build, just so you
>> can avoid copying some symlinks in an obtuse distribution mechanism? I
>> don't see it.
>
> First of all it's not a hack.
> It's a perfectly legitimate way how you can build a shared library.
>
> Any other discussion would only lead to philosophical and
> political rather then technical reasons.
> It's off by default, and if you don't need it, don't use it.
If you don't have any technical justification for this other than "it
lets me avoid copying a symlink" then I'm -1 on this change:
1) A non-versioned library build has a different ABI to the standard
build, because the library SONAME changes.
2) Ballooning the number of possible APR ABIs is bad.
3) It is trivially simple to work around the problem of having to copy
symlinks without adding complexity to the APR build system.
We discuss changes on their technical merits. Saying "it's perfectly
legitimate" doesn't add much to that debate. It would be "perfectly
legitimate" to introduce a configure switch to make the library SONAME
be "libfluffy-pink-clouds-1.so"; no laws would be broken that I'm aware
of.
Regards, Joe
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Mladen Turk <mt...@apache.org>.
Joe Orton wrote:
> On Tue, Feb 17, 2009 at 05:15:53PM +0100, Mladen Turk wrote:
>> Joe Orton wrote:
>>> On Tue, Feb 17, 2009 at 03:27:34PM -0000, Mladen Turk wrote:
>>>> Author: mturk
>>>> Date: Tue Feb 17 15:27:33 2009
>>>> New Revision: 745119
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=745119&view=rev
>>>> Log:
>>>> Add --disable-version option to configure.
>>>> This allows to create non versioned apr libs using libtool
>>> Why is this useful? Joe
>>>
>> Like log says; for creating non versioned .so.
>
> That doesn't tell me why it's useful, that tells me what it does.
>
I don't think the usage is relevant. It's up to user to
decide weather it will ship its application with embedded
apr or rely on a system one.
>> If packing the apr inside .jar for example (don't ask me why cause
>> it's work-in-progress) symlinks are unsupported, ending up in
>> duplicate file copies.
>
> So you really need a hack to the configure script which introduces a new
> way to break ABI compatibility with the standard build, just so you can
> avoid copying some symlinks in an obtuse distribution mechanism? I
> don't see it.
>
First of all it's not a hack.
It's a perfectly legitimate way how you can build a shared library.
Any other discussion would only lead to philosophical and
political rather then technical reasons.
It's off by default, and if you don't need it, don't use it.
Regards
--
^(TM)
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Feb 17, 2009 at 05:15:53PM +0100, Mladen Turk wrote:
> Joe Orton wrote:
> > On Tue, Feb 17, 2009 at 03:27:34PM -0000, Mladen Turk wrote:
> >> Author: mturk
> >> Date: Tue Feb 17 15:27:33 2009
> >> New Revision: 745119
> >>
> >> URL: http://svn.apache.org/viewvc?rev=745119&view=rev
> >> Log:
> >> Add --disable-version option to configure.
> >> This allows to create non versioned apr libs using libtool
> >
> > Why is this useful? Joe
> >
>
> Like log says; for creating non versioned .so.
That doesn't tell me why it's useful, that tells me what it does.
> If packing the apr inside .jar for example (don't ask me why cause
> it's work-in-progress) symlinks are unsupported, ending up in
> duplicate file copies.
So you really need a hack to the configure script which introduces a new
way to break ABI compatibility with the standard build, just so you can
avoid copying some symlinks in an obtuse distribution mechanism? I
don't see it.
Regards, Joe
Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Posted by Mladen Turk <mt...@apache.org>.
Joe Orton wrote:
> On Tue, Feb 17, 2009 at 03:27:34PM -0000, Mladen Turk wrote:
>> Author: mturk
>> Date: Tue Feb 17 15:27:33 2009
>> New Revision: 745119
>>
>> URL: http://svn.apache.org/viewvc?rev=745119&view=rev
>> Log:
>> Add --disable-version option to configure.
>> This allows to create non versioned apr libs using libtool
>
> Why is this useful? Joe
>
Like log says; for creating non versioned .so.
If packing the apr inside .jar for example
(don't ask me why cause it's work-in-progress)
symlinks are unsupported, ending up in
duplicate file copies.
Regards
--
^(TM)