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 painful. >> 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? Thanks, Max.
signature.asc
Description: OpenPGP digital signature
