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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
