apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Bowsher <ma...@ukf.net>
Subject Re: Apache Portable Runtime artifacts
Date Tue, 11 Nov 2008 01:37:23 GMT
Alan D. Cabrera wrote:
> On Nov 9, 2008, at 6:43 AM, Max Bowsher wrote:
>> Alan D. Cabrera wrote:
>>> On Nov 8, 2008, at 2:55 PM, Max Bowsher wrote:

>> (There's also the question of what architecture/processor naming scheme
>> to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg
>> --print-architecture", "uname -m", and Java's os.arch manage to be
>> inconsistent more often than not.)
> I'm not sure that we need to choose one over the other.  Let me ask you
> this, why would we need fine grained detail such as  "i386 vs. i586 vs.
> i686"?  Is that really necessary?

Oops, I didn't communicate clearly. What I meant was that on a typical
system, depending on what piece of software you ask, you will get
different answers, for example, dpkg --print-architecture showing i386,
Java's os.arch showing i586 and uname -m showing i686. Hence, we need to
establish consistency about which string we intend to use to represent
the general concept of IA-32.

>> More of an issue, though, is the dependencies on other system libraries,
>> and what versions thereof, the APR artifact may have. For example, the
>> APR shared lib on my Ubuntu system depends on glibc >= 2.4, and libuuid1.
>> This means it won't work on Debian etch / Ubuntu dapper, for example, or
>> other distros of similar age, nor would it work if libuuid1 was missing
>> - quite unlikely, I admit, but possible.
>> Whilst these dependencies are not *that* onerous, especially once Debian
>> lenny succeeds etch as stable, they do illustrate the problem.
> I'm not sure why APR would allow such a system dependancy.  APR is
> supposed to make application developers' lives easier.  Why would I have
> to worry about libuuid1 missing?  I'm new to APR and am getting my head
> around what it will and will not do for me.

It's perfectly normal and expected for C libraries to depend on other C
libraries. It's only in the world of JNI where this becomes potentially

>> In particular, beware that the specific version of glibc required isn't
>> something determined just by the apr source, but by the version being
>> compiled against, and even the compiler flags being used.
>> For example, if the chosen option was to force a glibc 2.3.x compatible
>> build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
>> setting the -fno-stack-protector compiler option would disable the
>> features that currently cause us to require glibc 2.4 at run-time if
>> present at compile-time.
>> That might be a viable option for producing an adequately compatible
>> binary for Maven deployment.
> Version 2.3.x strikes me as really old.  Unless I'm missing something,
> we, in my case, won't have to deal with that corner case.

Really? You think you'll avoid ever having a user who's running Debian
stable? I think that's a touch unrealistic.

> To give some more color to what I want to do, I want to make OSGi
> bundles for APR.  I would use OSGi's native code loading mechanism to
> "dispatch" the correct library.

Can you recommend any docs to that give an overview of this mechanism?


View raw message