On 27/04/2011 18:51, 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.
Yes well hmm. I've done this type of thing before, that is want to make
something run on newer systems. And lo and behold our makefile used
static linking with libc, so I can say authoritatively that in certain
circumstances it does not work. (it it only going to work without doubt
if you run it on the exact same system)
I've just been to court today (small claims) and it's been a hard day,
so before I rant on, can you tell us what version you want to run said
binary on (distro and version) and what version you are compiling on.
As an example, to solve this problem I have compiled on redhat 2ES and
all binaries now work on redhat 2-3-4 ubuntu 10.10 and so on, i.e. those
that are later in generation than redhat 2. And it all works fine.
This is what I suggest, if it is possible. i.e. compile on redhat 2, or
perhaps 3.
Perhaps if you post your build system version and flavour and target
system I'll be able to give you a better answer.
try lsb_release for this, if you aren't sure (and it's available as a
command)
jason@ionrift:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.2 LTS
Release: 10.04
Codename: lucid
otherwise cat /etc/*release*
