apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: Apache Portable Runtime artifacts
Date Sun, 09 Nov 2008 17:39:41 GMT
Alan D. Cabrera wrote:
> 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.


I think you are misunderstanding.

On Windows, binary compatibility is something that Microsoft does.

On Linux, each individual Linux vendor maintains their own binary 
compatibility.

This means a binary built on Debian might not work on Ubuntu, and 
definitely will not run on Redhat or Suse.

A binary built on $Vendor_Linux version 1, might work on version 2 -- 
but thats up to the vendor to maintain the appropriate libraries, and 
the only one that seems to do this somewhat consistently is Redhat or Suse.

This is even before you start talking about dependencies -- libapr on 
linux depends on libuuid1.  libapr-util can optionally depend on 
BerkeleyDB, Oracle, MySQL, Postgres, SQLite, OpenLDAP, etc.

This is a non-trivial endeavor.

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

I think you are under estimating the ability to make portable binaries 
on linux.

It is *possible*, but mostly if you static link *everything*, going so 
far to maybe even static link in dietlibc or something -- because glibc 
is a massive pain to static link, because their developers don't see the 
value in it.

And if you want to make a binary that runs on Linux 2.4 and Linux 2.6, 
the only possibility is to restrict yourself to 2.4 features, ie, no 
epoll, and to use a static dietlibc.

-Paul


Mime
View raw message