Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Amusingly enough, I'm pretty sure "FATAL: kernel too old" is a problem with glibc, so it's actually the C standard library that's preventing you from running your staticly-linked Haskell binary on your server.


So the haskell RTS requires the same version of glibc on both machines to make it work?

This wouldn't be too much of a problem but I don't have administrative privileges to these servers. So when I want to write throwaway scripts or programs, I find myself turning to Go or D and they work without any quibbles.


Nope. In theory you'd have exactly the same problem with any statically-linked binaries compiled on that machine and run on that server, regardless of what language they're written in. glibc has a minimum kernel version requirement and the glibc you're statically linking against just plain isn't compatible with the kernel on the machine you're running it on. Dynamically linking to a newer glibc and running against an older one doesn't generally work either, and IIRC may even result in apps that appear to start but crash unexpectedly when they try to access versions of library calls that aren't there, again regardless of language used.

Your problems with the non-statically-linked version, on the other hand, can probably be solved by copying the appropriate libraries to a directory on the server and pointing LD_LIBRARY_PATH at it... at least until you run into glibc problems.

Basically, what you're doing isn't supported and the fact that it worked for you with languages other than Haskell is mostly luck.


I don't believe Go's GC suite of compilers use glibc at all, for the record.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: