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 Sun, 09 Nov 2008 14:43:43 GMT
Alan D. Cabrera wrote:
> On Nov 8, 2008, at 2:55 PM, Max Bowsher wrote:
>> The difficulty is that there is no standard on how to manage the
>> multitude of flavours of native binaries that are possible.
>> For example, there's architecture and OS that need to be considered, but
>> for all but then you start to get things like C library version being
>> involved. If you are looking to do anything with apr-util as well as apr
>> itself, then the problem explodes with the number of extra dependencies.
> I was thinking that the artifact name could be
> apr-<osname>-<processor>
> e.g. apr-linux-x86_64.   Or we can have a more general
> apr-<osname>-<processor>-<configuration>
> where configuration is a token that represents a particular
> configuration of options, e.g. apr-msdos-8086-aztecc.

This is the right place to start (though may I suggest <arch>-<os>
rather than <os>-<arch>, for consistency with the prior art that I'm
aware of, namely autoconf-style system names and the

(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.)

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.

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.

Leaving aside the compatibility issues for a moment, what is the
intended method for Maven projects to depend on the APR artifacts? Would
they need to specify a specific flavour hardcoded in their POM
(potentially conditionalized with a long series of profiles, though this
likely wouldn't be flexible enough to do a completely satisfactory job)?
 Or is there a better way that I'm unaware of?

> I don't use the apr-util code.  Can you explain what extra dependencies
> there are?

Many and varied, since one of apr-util's purposes is to provide an
abstracted API over databases, xml parsers, and ldap clients that may or
may not be present at compile time. It would probably be impossible to
sensibly mavenize, so let's just be happy your use-case doesn't require
it! :-)


View raw message