5 ms·

That'd kind of defeat the whole point of linking a binary. Were you using cabal to build executables? What shared libs were missing on remote machines?

by pestaa 14y ago

djhworld 14y ago
When I just do a simple hello world app, I get this error ghc helloworld.hs -o helloworld <scp binary and ssh to remote machine> ./helloworld ./helloworld: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory However if I compile statically, I get a different error ghc helloworld.hs --make -optc-static -optl-static -optl-pthread -static -o helloworld <scp binary and ssh to remote machine> ./helloworld FATAL: kernel too old Segmentation fault This guy experiences similar issues. http://gaiustech.wordpress.com/2010/09/03/on-deployment/ http://gaiustech.wordpress.com/2010/09/03/on-deployment/
- Evbn 14y ago
  How old is your kernel, anyway?
  - djhworld 14y ago
    Running 2.6 I believe, but these servers are not managed by me, they're owned and administered by my workplace, so I don't have any say on upgrades etc
- makomk 14y ago
  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.
  - djhworld 14y ago
    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.
    - makomk 14y ago
      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.
      - mdwrigh2 14y ago
        I don't believe Go's GC suite of compilers use glibc at all, for the record.

That'd kind of defeat the whole point of linking a binary. Were you using cabal to build executables? What shared libs were missing on remote machines?

by pestaa 14y ago

That'd kind of defeat the whole point of linking a binary. Were you using cabal to build executables? What shared libs were missing on remote machines?

djhworld 14y ago

When I just do a simple hello world app, I get this error ghc helloworld.hs -o helloworld <scp binary and ssh to remote machine> ./helloworld ./helloworld: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory However if I compile statically, I get a different error ghc helloworld.hs --make -optc-static -optl-static -optl-pthread -static -o helloworld <scp binary and ssh to remote machine> ./helloworld FATAL: kernel too old Segmentation fault This guy experiences similar issues. http://gaiustech.wordpress.com/2010/09/03/on-deployment/ http://gaiustech.wordpress.com/2010/09/03/on-deployment/

Evbn 14y ago
How old is your kernel, anyway?
- djhworld 14y ago
  Running 2.6 I believe, but these servers are not managed by me, they're owned and administered by my workplace, so I don't have any say on upgrades etc
makomk 14y ago
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.
- djhworld 14y ago
  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.
  - makomk 14y ago
    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.
    - mdwrigh2 14y ago
      I don't believe Go's GC suite of compilers use glibc at all, for the record.