Re: [Haskell-cafe] Static linking problem // CentOS 5.5 - GHC 6.12.3
frode k mailingl...@klevstul.com writes: However I do of course want to run it through CGI on a webserver. I'm running lighttpd. If I try to run the file compiled above I get 500 - Internal Server Error, most likely since the enviroment is not correct for dynamic linked files: Why wouldn't the environment (i.e. available dynamic libraries) be correct for the web server? Hence I wanted to use static linking ( http://www.haskell.org/haskellwiki/Web/Literature/Static_linking ). However trying to compile using the -optl-static option fails: There are two main categories of error messages above: 1 : ...requires at runtime the shared libraries from the glibc version used for linking Yes, Linux (or rather, glibc) doesn't really support static linking any more, and relies on hard-coded paths to libraries for unicode stuff and name resolution and authentication. You can override this with environment variables, though. Perhaps this is helpful: http://blog.malde.org/index.php/2010/05/22/snagged/ 2a : undefined reference to `pthread_' 2b : undefined reference to `pthread_mutex_lock' ghc ... -optl-static -optl-pthread ^ Not sure why you have to add this manually, but it's been this way for years - at least since ghc 6.8, I think. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static linking problem // CentOS 5.5 - GHC 6.12.3
On Wed, Mar 16, 2011 at 8:05 AM, Ketil Malde ke...@malde.org wrote: frode k mailingl...@klevstul.com writes: However I do of course want to run it through CGI on a webserver. I'm running lighttpd. If I try to run the file compiled above I get 500 - Internal Server Error, most likely since the enviroment is not correct for dynamic linked files: Why wouldn't the environment (i.e. available dynamic libraries) be correct for the web server? You are right, dynamically linked files do work. It must be something with Lighttpd that prevents the Haskell compiled CGI code to be executed. When I moved the exact same CGI file to the cgi-bin directory on my Apache it ran without problems. If I do find out why I can not run Haskell CGI on Lighttpd I will send an update on this. Thanks for your feedback. Regards, Frode ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static linking problem // CentOS 5.5 - GHC 6.12.3
Why wouldn't the environment (i.e. available dynamic libraries) be correct for the web server? beacuse it runs CGI programs in a chroot jail? Then you need to copy the .so files into the jail, cf. http://www.cyberciti.biz/tips/howto-setup-lighttpd-php-mysql-chrooted-jail.html J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static linking problem // CentOS 5.5 - GHC 6.12.3
I had missed out some settings in the configuration files of lighttpd. Summary: - I renamed the Haskell test file to haskell.hcgi - I edited /etc/lighttpd/conf.d/cgi.conf and added two entries in the cgi.assign section, one for .hcgi and one for .hs (the latter one only to enable running of .hs files / uncompiled Haskell code for testing purposes). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - cgi.assign = ( .pl = /usr/bin/perl, .cgi = /usr/bin/perl, .rb = /usr/bin/ruby, .erb = /usr/bin/eruby, .py = /usr/bin/python, .hcgi= , .hs = /usr/haskell/bin/runhaskell) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - After a lighttpd restart I can now access both .hs files (for testing purposes, since performance assumingly won't be top notch here) and compiled .hcgi files. If I did not need to use perl for .cgi I could have change the setting for .cgi pointing to empty () in stead of adding a new entry for .hcgi / Haskell CGI. Regards, Frode ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Static linking problem // CentOS 5.5 - GHC 6.12.3
I've installed GHC version 6.12.3 on CentOS 5.5 x86_64. I'm trying to run a very simple Haskell program as CGI following the guide at: http://www.haskell.org/haskellwiki/Practical_web_programming_in_Haskell My .hs file I'm trying to use looks like this: -- import Network.CGI import Text.XHtml page :: Html page = body h1 Hello World! cgiMain :: CGI CGIResult cgiMain = output $ renderHtml page main :: IO () main = runCGI $ handleErrors cgiMain -- If I compile it using dynamic linking I can run it from the command line, since the environment is correct: # ghc haskell_v2.hs --make -o haskell_v2.cgi Linking haskell_v2.cgi ... # ./haskell_v2.cgi Content-type: text/html; charset=ISO-8859-1 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; body h1 Hello World!/h1 /body /html [root@vps-1040050-2953 haskellTest]# However I do of course want to run it through CGI on a webserver. I'm running lighttpd. If I try to run the file compiled above I get 500 - Internal Server Error, most likely since the enviroment is not correct for dynamic linked files: # ldd haskell_v2.cgi librt.so.1 = /lib64/librt.so.1 (0x2aff22c25000) libutil.so.1 = /lib64/libutil.so.1 (0x2aff22e2e000) libdl.so.2 = /lib64/libdl.so.2 (0x2aff23031000) libgmp.so.3 = /usr/lib64/libgmp.so.3 (0x2aff23236000) libm.so.6 = /lib64/libm.so.6 (0x2aff2346f000) libc.so.6 = /lib64/libc.so.6 (0x2aff236f2000) libpthread.so.0 = /lib64/libpthread.so.0 (0x2aff23a4a000) /lib64/ld-linux-x86-64.so.2 (0x2aff22a08000) # file haskell_v2.cgi haskell_v2.cgi: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped Hence I wanted to use static linking ( http://www.haskell.org/haskellwiki/Web/Literature/Static_linking ). However trying to compile using the -optl-static option fails: # ghc haskell_v2.hs --make -optl-static -fforce-recomp -o haskell_v2.cgi [1 of 1] Compiling Main ( haskell_v2.hs, haskell_v2.o ) Linking haskell_v2.cgi ... /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(HsNet.o): In function `hsnet_getaddrinfo': HsNet.c:(.text+0x11): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sAwu_info': (.text+0xd45d): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syh4_info': (.text+0x4364): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sygm_info': (.text+0x424f): warning: Using 'gethostent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syx3_info': (.text+0x5318): warning: Using 'sethostent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sxz5_info': (.text+0x12c6): warning: Using 'endhostent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syJY_info': (.text+0x605d): warning: Using 'getnetbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sycm_info': (.text+0x3e75): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sybC_info': (.text+0x3de7): warning: Using 'getnetent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syyg_info': (.text+0x5458): warning: Using 'setnetent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sxz5_info': (.text+0x1296): warning: Using 'endnetent' in statically linked applications requires at runtime the
Re: [Haskell-cafe] Static Linking Problem
On Thu, Nov 12, 2009 at 8:57 AM, David Virebayre dav.vire+hask...@gmail.com wrote: On Wed, Nov 11, 2009 at 5:44 PM, Svein Ove Aas svein@aas.no wrote: My recommendation would be to take glibc off the list of statically linked libraries. How do you do that ? By specifying the entire list manually, and not naming glibc. -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static Linking Problem
On Tue, Nov 10, 2009 at 4:29 PM, Ketil Malde ke...@malde.org wrote: MightyByte mightyb...@gmail.com writes: After a bit of googling, I came to the conclusion that I needed to compile it with ghc --make -static -optl-static Foo.hs. Using only -static or -optl-static by themselves did not generate a statically linked binary. But when I compile with both those parameters I get a bunch of linker errors: [..] (.text+0x59c): undefined reference to `pthread_mutex_lock' For some reason, GHC doesn't link with the pthreads library, so you need to compile (link) with two options: -opt-static -optl-pthread Excellent, that appears to have solved my problem. It still gives me the warning: (.text+0x3068): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking But glibc is pretty standard, so I don't think this will be a problem for me. Thanks for the help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static Linking Problem
On Wed, Nov 11, 2009 at 3:22 PM, MightyByte mightyb...@gmail.com wrote: (.text+0x3068): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking But glibc is pretty standard, so I don't think this will be a problem for me. Thanks for the help. You may have unexpected results. That warning occurs because some of glibc (namely, the getaddrinfo bit) is dynamically linked regardless of what you want; this is apparently to make NSS work, or something along those lines. However, if you then link the rest of glibc statically, you get dependencies between your program and the installed glibc, for internal, unstable APIs. (!) This is generally a Big No. Doing this means your program definitely won't be compatible with older versions of glibc, but it probably wouldn't be either way. However, in this case it also won't be compatible with *newer* versions of glibc. My recommendation would be to take glibc off the list of statically linked libraries. -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static Linking Problem
On Wed, Nov 11, 2009 at 5:44 PM, Svein Ove Aas svein@aas.no wrote: My recommendation would be to take glibc off the list of statically linked libraries. How do you do that ? David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Static Linking Problem
I am trying to statically compile a simple haskell program so I can use it on a Linux computer without haskell and it's associated libraries. Here is a small example program that illustrates my problem: module Main where import Network.Fancy main = do withDgram (IP 127.0.0.1 1234) (flip send Hello network\n) After a bit of googling, I came to the conclusion that I needed to compile it with ghc --make -static -optl-static Foo.hs. Using only -static or -optl-static by themselves did not generate a statically linked binary. But when I compile with both those parameters I get a bunch of linker errors: /home/mightybyte/.cabal/lib/network-fancy-0.1.4/ghc-6.10.4/libHSnetwork-fancy-0.1.4.a(Fancy.o): In function `s6ks_info': (.text+0x3068): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `init_mparams': (.text+0x3e): undefined reference to `pthread_mutex_lock' /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `init_mparams': (.text+0x52): undefined reference to `pthread_mutex_unlock' /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `init_mparams': (.text+0xd3): undefined reference to `pthread_mutex_init' /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `ffi_closure_free': (.text+0x59c): undefined reference to `pthread_mutex_lock' etc... I've tried this on both Fedora and Arch Linux and I get the same error. Anyone know how to solve this problem? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static Linking Problem
MightyByte mightyb...@gmail.com writes: After a bit of googling, I came to the conclusion that I needed to compile it with ghc --make -static -optl-static Foo.hs. Using only -static or -optl-static by themselves did not generate a statically linked binary. But when I compile with both those parameters I get a bunch of linker errors: [..] (.text+0x59c): undefined reference to `pthread_mutex_lock' For some reason, GHC doesn't link with the pthreads library, so you need to compile (link) with two options: -opt-static -optl-pthread -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
