'data-files' and .stack-work were really good hints. Thank you, Erik. I rsynced the whole .stack-work dir over now and this lets me successfully run gitit on the smaller VM. Ok, when I say "run", I mean "start", but it is something. The folder in question has 500 MB, however, and I'd rather not transfer that much. After a bit of random action, it appears safe to delete files outside the gitit folder deeply nested within .stack-work, but I cannot be sure. Do you have further input on that? Can I collect these files with stack (or cabal?) automatically?
Matthias On Monday, September 5, 2016 at 3:14:52 PM UTC+2, Erik Hesselink wrote: > > This is due to the fact that gitit uses cabal's "data-files" section to > make data files available at runtime. These are installed in the path > mentioned in the error on the machine where you built, so they will be > missing on the machine where you copied the binary. This was the reason we > stopped using data-files, but obviously that won't work for you. I've > looked briefly into getting stack to write these data files to a different > (relative?) path so you could copy them over with the executable, but was > unable to find anything. Maybe someone else with more stack knowledge can > chime in on that? > > Erik > > On 1 September 2016 at 23:08, Matthias Kauer <[email protected] > <javascript:>> wrote: > >> Thank you for the insight you provided. I'm having some trouble with the >> mailing list and retyping now. >> >> I tried the straightforward approach again today. >> Built gitit with `stack install` on 1 VM then copied it over to another. >> Both Ubuntu 14.04. >> >> Running on the second VM yields: >> ``` >> vagrant@trusty:~$ ./gitit >> gitit: >> /home/vagrant/gitit/.stack-work/install/x86_64-linux/lts-4.0/7.10.3/share/x86_64-linux-ghc-7.10.3/gitit-0.12.1.1/data/default.conf: >> >> openFile: inappropriate type (Not a directory) >> ``` >> >> Is this a gitit specific error? Or am I just missing some artifacts from >> the build process? >> >> Kind regards, >> Matthias Kauer >> >> >> >> On Tuesday, August 30, 2016 at 9:24:22 PM UTC+2, Matthias Hörmann wrote: >>> >>> Hello >>> >>> If you are using the same OS on both your compile and production >>> system and do have all the non-Haskell libraries you are linking >>> installed on both >>> you should be able to just copy the binary without any special options >>> during stack build. >>> >>> I have done it for dozens of different projects. >>> >>> Usually you need libgmp3c2, libpcre3 and zlib1g on Debian-based >>> systems and possibly a database C library if the Haskell library for >>> that you are using is >>> just a wrapper around the C version. >>> >>> What kind of errors about missing files do you get? >>> >>> Matthias Hörmann >>> >>> On Tue, Aug 30, 2016 at 9:16 PM, Matthias Kauer <[email protected]> >>> wrote: >>> > Hi, >>> > I want to deploy a Haskell web application (gitit) on a small VPS and >>> I'm >>> > not sure if the task is hard or I am going about it the wrong way. >>> > The constraints are: >>> > - The server has 512 MB RAM, so compiling there doesn't work. >>> > - Docker will most likely not work either. I believe it requires extra >>> > config in OpenVZ and most hosters will not have done that. >>> > - Locally, I have a VM (Virtualbox) with 4GB RAM and the same >>> (similar) >>> > Ubuntu 14.04. environment. >>> > >>> > After compiling with `stack install` and uploading, I cannot execute >>> the >>> > binary because it complains about files missing that have the absolute >>> path >>> > from the VM. >>> > >>> > Is this actually a very difficult task? Or is it rather so mundane >>> that >>> > people do not talk about it that much? >>> > Can you offer some guidance on what I can do to achieve this? >>> > >>> > Among other things, I have tried what is described here: >>> > https://ro-che.info/articles/2015-10-26-static-linking-ghc (building >>> with >>> > >>> > stack build --ghc-options='-optl-static -optl-pthread' --force-dirty) >>> > This ends up not linking gitit itself at the very end >>> > >>> > ```/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o: >>> relocation >>> > R_X86_64_32 against `__TMC_END__' can not be used when making a shared >>> > object; recompile with -fPIC``` >>> > This might be fixable by installing the right system libraries, but is >>> this >>> > even a good way to go about this? >>> > >>> > Best regards, >>> > Matthias >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "haskell-stack" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to [email protected]. >>> > To post to this group, send email to [email protected]. >>> > To view this discussion on the web visit >>> > >>> https://groups.google.com/d/msgid/haskell-stack/8cdd70b2-136c-4fe3-8a87-e9184d7f8589%40googlegroups.com. >>> >>> >>> > For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "haskell-stack" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/haskell-stack/bbd55aec-1300-409b-ba81-118145e1bcfb%40googlegroups.com >> >> <https://groups.google.com/d/msgid/haskell-stack/bbd55aec-1300-409b-ba81-118145e1bcfb%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "haskell-stack" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/f00b0c26-3df6-45d7-ab0c-e262243b622b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
