You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by rb...@apache.org on 2002/09/17 00:15:37 UTC
library versioning name
Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
which allows you to continue to do -lapr. Is there a reason we chose to
do something different???
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: library versioning name
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 19, 2002 at 02:53:37PM -0700, Wilfredo Sanchez wrote:
> On Monday, September 16, 2002, at 06:00 PM, Greg Stein wrote:
>...
> > Yup. But try and build those *today* and have them still link against
> > DB-3.3. You need the parallel install stuff.
>
> The problem isn't solved by making everyone use -lapr-1. You also
> have to (as noted in the document Ben sent us) make everyone #include
> <apr-1/foo.h>, otherwise you are linking to a library other than the
> one your headers correspond to.
No... you put .../apr-1/ into INCLUDES, and people #include <foo.h>
And before you speak up on the issue, let's check something out:
$ apr-config apr-config --includes
-I/usr/local/svn/include/apr-0
Looky there! It *already* does what you requested.
> So unless you are going to do that as
> well, I think the exercise is a waste of time, pretending to fix
> something, but falling short in ways that could create some
> interestingly hard to find bugs.
Preaching to the choir. Did you take a look at the implementation? :-)
> You also have to bump the version whenever the library is no longer
> backwards-compatible, such as adding an argument to an existing
> function, or deleting a function.
Ahem. http://apr.apache.org/versioning.html
And from apr_version.h:
...
*
* APR version numbering follows the guidelines specified in:
*
* http://apr.apache.org/versioning.html
*/
So it appears that we already have hard and fast rules on compatibility.
> Now the drag is that if you upgrade APR, you have to go through all
> your code and fix the #includes. That kinda sucks.
If you use "apr-config --includes" (as you should be doing), then this does
not apply.
> So maybe encapsulating the whole install in versioned directories is
> a better option.
It is a possibility, but the FHS provides for distributed installations
(e.g. into /usr or /usr/local) along with installations into /opt. I'm not
sure what it recommends for libraries (e.g. is /opt just for apps?)
Fred: how about if you take a look at the existing stuff, and see whether
that works for you :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: library versioning name
Posted by Wilfredo Sánchez <ws...@MIT.EDU>.
OK, sure. But you aren't using the -framework option, cheater. :-)
-wsv
On Friday, September 20, 2002, at 02:26 AM, Pier Fumagalli wrote:
> On Thursday, September 19, 2002, at 10:53 PM, Wilfredo Sanchez wrote:
>
>> Pier, frameworks do provide the right information for all versions,
>> but there is no compiler flag in OS X to build and link against an
>> old version, which is moderately lame. I do think it would be swell
>> if the GNU folks could be convinced to add something like -framework
>> to standard gcc, though it could probably use some improvement over
>> the current model in Darwin.
>
> Ok, now I'm going against the master :-)
>
> Linking to JDK 1.3.1 (the default)...
>
> cc \
> -L/System/Library/Frameworks/JavaVM.framework/Libraries \
> -I/System/Library/Frameworks/JavaVM.framework/Headers \
> -ljvm .....
>
> Against 1.4
>
> cc \
> -L/System/Library/Frameworks/JavaVM.framework/Versions/1.4.0/
> Libraries \
> -I/System/Library/Frameworks/JavaVM.framework/Versions/1.4.0/Headers \
> -ljvm .....
>
> Ok, I can't specify -version , but it is trivial enough! :-)
>
> Pier
Re: library versioning name
Posted by Pier Fumagalli <pi...@betaversion.org>.
On Thursday, September 19, 2002, at 10:53 PM, Wilfredo Sanchez wrote:
> Pier, frameworks do provide the right information for all versions,
> but there is no compiler flag in OS X to build and link against an old
> version, which is moderately lame. I do think it would be swell if
> the GNU folks could be convinced to add something like -framework to
> standard gcc, though it could probably use some improvement over the
> current model in Darwin.
Ok, now I'm going against the master :-)
Linking to JDK 1.3.1 (the default)...
cc \
-L/System/Library/Frameworks/JavaVM.framework/Libraries \
-I/System/Library/Frameworks/JavaVM.framework/Headers \
-ljvm .....
Against 1.4
cc \
-L/System/Library/Frameworks/JavaVM.framework/Versions/1.4.0/Libraries
\
-I/System/Library/Frameworks/JavaVM.framework/Versions/1.4.0/Headers \
-ljvm .....
Ok, I can't specify -version , but it is trivial enough! :-)
Pier
Re: library versioning name
Posted by Wilfredo Sanchez <ws...@MIT.EDU>.
On Monday, September 16, 2002, at 06:00 PM, Greg Stein wrote:
>> Now, I have few binaries that I still didn't recompile that are using
>> DB-3.3
>> (I just brought them over from an old system) but when I ldd them:
>
> Yup. But try and build those *today* and have them still link against
> DB-3.3. You need the parallel install stuff.
The problem isn't solved by making everyone use -lapr-1. You also
have to (as noted in the document Ben sent us) make everyone #include
<apr-1/foo.h>, otherwise you are linking to a library other than the
one your headers correspond to. So unless you are going to do that as
well, I think the exercise is a waste of time, pretending to fix
something, but falling short in ways that could create some
interestingly hard to find bugs.
You also have to bump the version whenever the library is no longer
backwards-compatible, such as adding an argument to an existing
function, or deleting a function.
Now the drag is that if you upgrade APR, you have to go through all
your code and fix the #includes. That kinda sucks.
So maybe encapsulating the whole install in versioned directories is
a better option.
Pier, frameworks do provide the right information for all versions,
but there is no compiler flag in OS X to build and link against an old
version, which is moderately lame. I do think it would be swell if the
GNU folks could be convinced to add something like -framework to
standard gcc, though it could probably use some improvement over the
current model in Darwin.
-wsv
Re: library versioning name
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
James Cox wrote:
>>They *remember* yes, but how do you choose *up front* which one to link
>>against?
>>
>>With parallel versioning, I can link my "early" APR app with:
>>
>>$ ld ... -lapr-0
>>
>>But my newfangled one does:
>>
>>$ ld ... -lapr-1
>>
>>
>>>...
>>>Now, I have few binaries that I still didn't recompile that are
>>
>>using DB-3.3
>>
>>>(I just brought them over from an old system) but when I ldd them:
>>
>>Yup. But try and build those *today* and have them still link against
>>DB-3.3. You need the parallel install stuff.
>>
>
>
> The problem with that is that people will more than likely be building
> against apr, rather than a specific apr version, as the API has nearly
> solidified, etc. (i'm assuming we're not too far away from bugfix/new
> feature mode).
>
> So this parallel install stuff is only for those who've been using APR as
> it's been developing. I imagine some will port their apps to the release
> release version of apr. Of course some won't too.
it's also for later down the road when we release apr 2.0.
> the point is that we still need the -lapr convention to work, to grab the
> latest version. Is there any way we can do both?
> eg, on a linux system:
>
> /usr/lib/libapr-#.so... (specific version)
> /usr/lib/libapr.so ... (latest)
>
> or something similar....
can't apr-config handle this issue? as long as people are using it to
generate their makefiles, then they're all set. of course, down the
road when there are multiple incompatable versions of apr lying around
(i don't count the ones we have now, since they're pre 1.0, and it's
expected that they will break), apr-config will have to get smarter
about it...
-garrett
RE: library versioning name
Posted by James Cox <ja...@imajes.info>.
> They *remember* yes, but how do you choose *up front* which one to link
> against?
>
> With parallel versioning, I can link my "early" APR app with:
>
> $ ld ... -lapr-0
>
> But my newfangled one does:
>
> $ ld ... -lapr-1
>
> >...
> > Now, I have few binaries that I still didn't recompile that are
> using DB-3.3
> > (I just brought them over from an old system) but when I ldd them:
>
> Yup. But try and build those *today* and have them still link against
> DB-3.3. You need the parallel install stuff.
>
The problem with that is that people will more than likely be building
against apr, rather than a specific apr version, as the API has nearly
solidified, etc. (i'm assuming we're not too far away from bugfix/new
feature mode).
So this parallel install stuff is only for those who've been using APR as
it's been developing. I imagine some will port their apps to the release
release version of apr. Of course some won't too.
the point is that we still need the -lapr convention to work, to grab the
latest version. Is there any way we can do both?
eg, on a linux system:
/usr/lib/libapr-#.so... (specific version)
/usr/lib/libapr.so ... (latest)
or something similar....
-- james
Re: library versioning name
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Sep 17, 2002 at 12:46:19AM +0100, Pier Fumagalli wrote:
> On 17/9/02 0:13, "Greg Stein" <gs...@lyra.org> wrote:
>...
> > Yes. APR is all about being a library, so supporting parallel installations
> > is practically mandatory. Take a look at Berkeley DB as a great example. I
> > have db1, db2, db-3.1, db-3.2, and db-4.0 on my machine. My applications can
> > choose the particular version that they require. The .so.# does not provide
> > for that.
> >
> > Similar issues arise for selecting the header files.
> >
> > I've got a sneaky feeling we may need to do more with the *-config scripts,
> > but I'm not yet sure there. May need to write Havoc to get his feedback.
>
> I'm slightly against this approach for the OSes I use (Solaris and MacOS/X,
> dunno if it's possible to do on others) because, for instance, both ELF and
> Mach-O binaries "remember" the name of the library I linked against when
> properly versioned (and that is _not_ what libtool does, that's why I hate
> that .... thing)...
They *remember* yes, but how do you choose *up front* which one to link
against?
With parallel versioning, I can link my "early" APR app with:
$ ld ... -lapr-0
But my newfangled one does:
$ ld ... -lapr-1
>...
> Now, I have few binaries that I still didn't recompile that are using DB-3.3
> (I just brought them over from an old system) but when I ldd them:
Yup. But try and build those *today* and have them still link against
DB-3.3. You need the parallel install stuff.
>...
> Regarding headers, seriously, if I compile something today, I want it to
> link against the very latest version of the library, because I want all
> possible patches and updates, so I don't really see that problem...
That is your choice, but apps are build to specific APIs, and they must
compile against those specific APIs. By definition /include/apr-0/ defines a
*different* interface than /include/apr-1/. Thus, your application will be
designed for one or the other, and needs to compile against the correct
interface.
(and yah: it might be possible to build an app that compiles against both,
but that might not always be the case... could you imagine trying to build
an app for GTK 1.0 *and* GTK 2.0... screw that. you choose one.)
I was in the same camp for a while, too "soname handles it", then I really
thought more on it. soname only handles runtime linking. It doesn't handle
build selection.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: library versioning name
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Justin Erenkrantz" <je...@apache.org> wrote:
> On Tue, Sep 17, 2002 at 01:22:17AM -0700, Greg Stein wrote:
>> Are you just bitching, or do you have a better design? Let's hear it.
>
> Oh, I'm fine with --enable-layout=classic which reverts Havoc's
> model to what we had before. The key point for me is to allow
> the admin not to be forced into a particular model.
Thank you Justin...
> We can both co-exist in our little worlds - which is acceptable
> to me (and I hope to you). You have your reasons for using that
> model, I have my reasons for thinking it's overboard - which is
> that a prefix containing an explicit version resolves the parallel
> concerns (i.e. /opt/apr-0.9.0 or /opt/apr-0.9 or /opt/apr-0). If
> you don't have a versioned prefix, yes, you need Havoc's model.
That's why the idea of MacOS/X's bundles and frameworks makes _a_lot_ of
sense! :) That's just a beautiful way of organizing things...
> It does make sense to make your design the default, since that lets
> newbies configure it in a sensible (to them) manner. But, we should
> have the flexibility to allow for circumstances where it isn't
> helpful.
The thing that doesn't make me smile about having version details in the
library name is that it doesn't push developers to update their code to the
latest versions of a given library... If I'm sure I can simply do a
-lapr-0.9, why in the world would I be pushed to update to -lapr-1.0?
But anyhow, since we have a "classic" layout, I can live with that! :)
Pier
RE: library versioning name
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: 17 September 2002 10:47
> On Tue, Sep 17, 2002 at 01:22:17AM -0700, Greg Stein wrote:
> > Are you just bitching, or do you have a better design? Let's hear it.
>
> Oh, I'm fine with --enable-layout=classic which reverts Havoc's
> model to what we had before. The key point for me is to allow
> the admin not to be forced into a particular model.
>
> We can both co-exist in our little worlds - which is acceptable
> to me (and I hope to you). You have your reasons for using that
> model, I have my reasons for thinking it's overboard - which is
> that a prefix containing an explicit version resolves the parallel
> concerns (i.e. /opt/apr-0.9.0 or /opt/apr-0.9 or /opt/apr-0). If
> you don't have a versioned prefix, yes, you need Havoc's model.
>
> It does make sense to make your design the default, since that lets
> newbies configure it in a sensible (to them) manner. But, we should
> have the flexibility to allow for circumstances where it isn't
> helpful. -- justin
What can I say? +1.
Sander
Re: library versioning name
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Sep 17, 2002 at 01:22:17AM -0700, Greg Stein wrote:
> Are you just bitching, or do you have a better design? Let's hear it.
Oh, I'm fine with --enable-layout=classic which reverts Havoc's
model to what we had before. The key point for me is to allow
the admin not to be forced into a particular model.
We can both co-exist in our little worlds - which is acceptable
to me (and I hope to you). You have your reasons for using that
model, I have my reasons for thinking it's overboard - which is
that a prefix containing an explicit version resolves the parallel
concerns (i.e. /opt/apr-0.9.0 or /opt/apr-0.9 or /opt/apr-0). If
you don't have a versioned prefix, yes, you need Havoc's model.
It does make sense to make your design the default, since that lets
newbies configure it in a sensible (to them) manner. But, we should
have the flexibility to allow for circumstances where it isn't
helpful. -- justin
Re: library versioning name
Posted by Greg Stein <gs...@lyra.org>.
Are you just bitching, or do you have a better design? Let's hear it.
On Mon, Sep 16, 2002 at 10:59:10PM -0700, Justin Erenkrantz wrote:
>...
> I agree with you that Havoc's page is specifically for GNU projects
> and prohibits other (potentially better) forms of versioning. The
> GNU model is to always install things into /usr (or /usr/local). I
> believe that's bad form for reasons I've gone into before. This
> model falls flat on its face when each version has its own directory
> (as it needlessly complicates matters).
>
> Sadly, all of the GNU projects buy into this. Good luck trying to
> install anything that has automake or pkgconfig extensions in
> separate directories. All of those projects assume that every piece
> of software is in a single cluttered hierarchy.
>
> How frustrating. -- justin
--
Greg Stein, http://www.lyra.org/
Re: library versioning name
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Sep 17, 2002 at 12:46:19AM +0100, Pier Fumagalli wrote:
> Regarding headers, seriously, if I compile something today, I want it to
> link against the very latest version of the library, because I want all
> possible patches and updates, so I don't really see that problem...
>
> This document <http://www106.pair.com/rhp/parallel.html> only talks about
> Linux, which is a platform I luckily don't use nor know, but AFAICS, it
> should work on all of them: works on FreeBSD/NetBSD, and on NetBSD it's how
> EVERYTHING is compiled... For instance:
You want --enable-layout=classic. =) (go read config.layout)
It's my own subtle form of protest.
I agree with you that Havoc's page is specifically for GNU projects
and prohibits other (potentially better) forms of versioning. The
GNU model is to always install things into /usr (or /usr/local). I
believe that's bad form for reasons I've gone into before. This
model falls flat on its face when each version has its own directory
(as it needlessly complicates matters).
Sadly, all of the GNU projects buy into this. Good luck trying to
install anything that has automake or pkgconfig extensions in
separate directories. All of those projects assume that every piece
of software is in a single cluttered hierarchy.
How frustrating. -- justin
Re: library versioning name
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 17/9/02 0:13, "Greg Stein" <gs...@lyra.org> wrote:
> On Mon, Sep 16, 2002 at 06:00:20PM -0500, Ben Collins-Sussman wrote:
>> rbb@apache.org writes:
>>
>>> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
>>> which allows you to continue to do -lapr. Is there a reason we chose to
>>> do something different???
>>
>> Subversion switched to naming our many libraries "libsvn_foo-1.so"
>> last June, based on this rationale:
>>
>> http://www106.pair.com/rhp/parallel.html
>>
>> I suspect that gstein may have spread the same gospel to APR
>> recently. :-)
>
> Yes. APR is all about being a library, so supporting parallel installations
> is practically mandatory. Take a look at Berkeley DB as a great example. I
> have db1, db2, db-3.1, db-3.2, and db-4.0 on my machine. My applications can
> choose the particular version that they require. The .so.# does not provide
> for that.
>
> Similar issues arise for selecting the header files.
>
> I've got a sneaky feeling we may need to do more with the *-config scripts,
> but I'm not yet sure there. May need to write Havoc to get his feedback.
I'm slightly against this approach for the OSes I use (Solaris and MacOS/X,
dunno if it's possible to do on others) because, for instance, both ELF and
Mach-O binaries "remember" the name of the library I linked against when
properly versioned (and that is _not_ what libtool does, that's why I hate
that .... thing)...
Basically, on my system, I have this setup (for example with libdb):
/usr/lib/libdb.so -> libdb.so.4.0.14
/usr/lib/libdb.so.4.0 -> libdb.so.4.0.14
/usr/lib/libdb.so.4.0.14
/usr/lib/libdb.so.3.3 -> libdb.so.3.3.11
/usr/lib/libdb.so.3.3.11
Now, I have few binaries that I still didn't recompile that are using DB-3.3
(I just brought them over from an old system) but when I ldd them:
[pier@pulse] ~ $ uname -srn
SunOS pulse.betaversion.org 5.8
[pier@pulse] ~ $ ldd /opt/cyrus/bin/imapd | grep libdb
libdb.so.3.3 => /usr/lib/libdb.so.3.3.11
[pier@pulse] ~ $ ldd /opt/subversion/bin/svnadmin | grep libdb
libdb.so.4.0 => /usr/lib/libdb.so.4.0.14
[pier@pulse] ~ $
So, although I linked it against -ldb, it finds the correct version of the
library because:
[pier@pulse] ~ $ elfdump /usr/lib/libdb.so.4.0.14 | grep SONAME
[1] SONAME libdb.so.3.3
[pier@pulse] ~ $ elfdump /usr/lib/libdb.so.3.3.11 | grep SONAME
[1] SONAME libdb.so.4.0
[pier@pulse] ~ $
... Linking preserves the name in my libraries, and puts it's SONAME in the
binary linked against it, so no problems there...
Regarding headers, seriously, if I compile something today, I want it to
link against the very latest version of the library, because I want all
possible patches and updates, so I don't really see that problem...
This document <http://www106.pair.com/rhp/parallel.html> only talks about
Linux, which is a platform I luckily don't use nor know, but AFAICS, it
should work on all of them: works on FreeBSD/NetBSD, and on NetBSD it's how
EVERYTHING is compiled... For instance:
[pier@dodo] ~ $ uname -srn
NetBSD dodo.betaversion.org 1.6E
[pier@dodo] ~ $ readelf --all /usr/lib/libcurses.so | grep -i SONAME
0x0000000e (SONAME) Library soname: [libcurses.so.5]
[pier@dodo] ~ $
So, I seriously don't see why one should "encode" the version number in the
name of the library, SONAME does the trick so nicely... (I actually
recompile everything to follow SONAME, otherwise I get confused! :)
Pier
Re: library versioning name
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 16, 2002 at 06:00:20PM -0500, Ben Collins-Sussman wrote:
> rbb@apache.org writes:
>
> > Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> > which allows you to continue to do -lapr. Is there a reason we chose to
> > do something different???
>
> Subversion switched to naming our many libraries "libsvn_foo-1.so"
> last June, based on this rationale:
>
> http://www106.pair.com/rhp/parallel.html
>
> I suspect that gstein may have spread the same gospel to APR
> recently. :-)
Yes. APR is all about being a library, so supporting parallel installations
is practically mandatory. Take a look at Berkeley DB as a great example. I
have db1, db2, db-3.1, db-3.2, and db-4.0 on my machine. My applications can
choose the particular version that they require. The .so.# does not provide
for that.
Similar issues arise for selecting the header files.
I've got a sneaky feeling we may need to do more with the *-config scripts,
but I'm not yet sure there. May need to write Havoc to get his feedback.
Cheers,
-g
p.s. I suspect the Windows DLLs ought to get similarly renamed so they can
avoid future DLL hell, too.
--
Greg Stein, http://www.lyra.org/
Re: library versioning name
Posted by Ben Collins-Sussman <su...@collab.net>.
rbb@apache.org writes:
> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> which allows you to continue to do -lapr. Is there a reason we chose to
> do something different???
Subversion switched to naming our many libraries "libsvn_foo-1.so"
last June, based on this rationale:
http://www106.pair.com/rhp/parallel.html
I suspect that gstein may have spread the same gospel to APR
recently. :-)
Re: library versioning name
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 16/9/02 23:54, "Sander Striker" <st...@apache.org> wrote:
>> From: Pier Fumagalli [mailto:pier@betaversion.org]
>> Sent: 17 September 2002 00:36
>
>> On 16/9/02 23:15, "rbb@apache.org" <rb...@apache.org> wrote:
>>
>>>
>>> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
>>> which allows you to continue to do -lapr. Is there a reason we chose to
>>> do something different???
>>
>> Sgrunf???? Whatchasaying Ryan?
>>
>> $ ls -1a /opt/apache/lib/libapr*
>> /opt/apache/lib/libapr.a
>> /opt/apache/lib/libapr.la
>> /opt/apache/lib/libapr.so -> libapr.so.0.0.0
>> /opt/apache/lib/libapr.so.0 -> libapr.so.0.0.0
>> /opt/apache/lib/libapr.so.0.0.0
>> /opt/apache/lib/libaprutil.a
>> /opt/apache/lib/libaprutil.la
>> /opt/apache/lib/libaprutil.so -> libaprutil.so.0.0.0
>> /opt/apache/lib/libaprutil.so.0 -> libaprutil.so.0.0.0
>> /opt/apache/lib/libaprutil.so.0.0.0
>> $
>>
>> Unless something changed in the past 3 weeks, this is how it works with
>> Apache...
>
> I hate to say it, but something changed the past 3 weeks... ;)
Sorry, was out of touch for a while... My main BetaVersion server and the
backup one (friggin' Intel hardware) both died... Lost approximately 3 weeks
of email, the WebApp/Jerry module source code (all of it), and other random
bits and bobs... :-/
Didn't know, my bad! :)
Pier (explaining also his silence of the past month or so)
RE: library versioning name
Posted by Sander Striker <st...@apache.org>.
> From: Pier Fumagalli [mailto:pier@betaversion.org]
> Sent: 17 September 2002 00:36
> On 16/9/02 23:15, "rbb@apache.org" <rb...@apache.org> wrote:
>
> >
> > Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> > which allows you to continue to do -lapr. Is there a reason we chose to
> > do something different???
>
> Sgrunf???? Whatchasaying Ryan?
>
> $ ls -1a /opt/apache/lib/libapr*
> /opt/apache/lib/libapr.a
> /opt/apache/lib/libapr.la
> /opt/apache/lib/libapr.so -> libapr.so.0.0.0
> /opt/apache/lib/libapr.so.0 -> libapr.so.0.0.0
> /opt/apache/lib/libapr.so.0.0.0
> /opt/apache/lib/libaprutil.a
> /opt/apache/lib/libaprutil.la
> /opt/apache/lib/libaprutil.so -> libaprutil.so.0.0.0
> /opt/apache/lib/libaprutil.so.0 -> libaprutil.so.0.0.0
> /opt/apache/lib/libaprutil.so.0.0.0
> $
>
> Unless something changed in the past 3 weeks, this is how it works with
> Apache...
I hate to say it, but something changed the past 3 weeks... ;)
Sander
Re: library versioning name
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 16/9/02 23:15, "rbb@apache.org" <rb...@apache.org> wrote:
>
> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> which allows you to continue to do -lapr. Is there a reason we chose to
> do something different???
Sgrunf???? Whatchasaying Ryan?
$ ls -1a /opt/apache/lib/libapr*
/opt/apache/lib/libapr.a
/opt/apache/lib/libapr.la
/opt/apache/lib/libapr.so -> libapr.so.0.0.0
/opt/apache/lib/libapr.so.0 -> libapr.so.0.0.0
/opt/apache/lib/libapr.so.0.0.0
/opt/apache/lib/libaprutil.a
/opt/apache/lib/libaprutil.la
/opt/apache/lib/libaprutil.so -> libaprutil.so.0.0.0
/opt/apache/lib/libaprutil.so.0 -> libaprutil.so.0.0.0
/opt/apache/lib/libaprutil.so.0.0.0
$
Unless something changed in the past 3 weeks, this is how it works with
Apache...
Pier