On 04/27/2011 11:51 AM, Nick Sabalausky wrote:
"Kai Meyer"<k...@unixlords.com> wrote in message
news:ip9bro$1lak$1...@digitalmars.com...
On 04/26/2011 02:28 PM, Nick Sabalausky wrote:
Ok, so I guess statically linking against the stuff isn't the way to go,
and
apparently DLL hell is worse on linux. Sooo...What do I do?
In the other thread, Spacen said: "The way to do this is to link against
the
oldest libc you need to
support, thus making the binaries forward compatible"
I know my way around Linux as a user, but with deeper system stuff like
that
I'm pretty much lost. I don't have a clue how to do what Spacen suggests
or
how to determine what version of libc I need. Can anyone help me out with
that?
Can you backup, and help me understand what the first problem was? The one
you thought was solvable by statically linking against glibc?
It was the thread "D CGI test: linux.so.2: bad ELF interpreter: No such file
or directory".
Reposted here:
-------------------------
I've made a little test CGI app:
import std.conv;
import std.stdio;
void main()
{
auto content = "<b><i>Hello world</i></b>";
auto headers =
`HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: `~to!string(content.length);
while(readln().length> 1) {}
writeln(headers);
writeln();
writeln(content);
}
Works on Windows command line and through IIS. And it works on my Kubuntu
10.6 (CORRECTION: It's v10.04) command line. But if I copy the executable
from my Kubuntu box to my
web host's Debian server (CORRECTION: It's Red Hat, but there is another
server I'd like to also run on that is Debian): Running it through Apache
gives me a 500, and running it directly with ssh gives me:
linux.so.2: bad ELF interpreter: No such file or directory
I assume that error message is the cause of the 500 (can't tell for sure
because the 500 isn't even showing up in my Apache error logs). But I'm not
enough of a linux expert to have the slightest clue what that error message
is all about. I don't need to actually compile it *on* the server do I? I
would have thought that all (or at least most) Linux distros used the same
executable format - especially (K)Ubuntu and Debian.
Ya, glibc tries very hard to be forward compatible, but it is quite
often not very backwards compatible. Meaning, if you build on an older
system, it should run on newer systems (forward compatible.) But if you
build on newer systems, it's not always going to run on older systems
(backwards compatible.)
The best solution is to either use LSB (which is a big hoary mess to get
into, and isn't fully supported everywhere, and I don't think there's
anything you can do to D to make it LSB compatible), build on the oldest
distro, or build on each distro.
Ideally, for performance, you should build a binary for each distro. You
should build one for Ubuntu separately from Debian, but if you don't
ahve the time, building on Debian will likely run on Ubuntu, but not
visa versa. Statically linking or dynamic linking isn't the answer, it's
forward and backwards compatibility.
Personally, I build rpms for both RHEL/CentOS and Fedora on a
semi-regular basis, and I usually build one to distribute on RHEL/CentOS
separate from a build to distribute on Fedora.
