apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Apache Portable Runtime artifacts
Date Sun, 09 Nov 2008 16:08:10 GMT

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:
>>> 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
> freehep-nar-maven-plugin).
>
> (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?

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

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

> 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 think in this case, my case, we only need to worry about a few stock  
configurations, e.g. Linux and Windows.  For me that would handle  
99.9% of my universe.  More exotic configurations can use the naming  
conventions that we are currently working out and publish on an as  
needed basis; I don't anticipate this happening often.

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.

I have to admit that "wrinkles" that you presented above seem to be  
rare corner cases in my world.


Regards,
Alan



Mime
View raw message