Fwd: PSA: building HEAD with Nix/NixOS
Looks great, thank you! One question however, in one of the lines you have this command: 'nix-build '' -A haskell-ng.compiler.ghcHEAD --run-env -I /home/user' Is nix-build supposed to be nix-shell? Usage afterwards seems to indicate that it is, but I'm not 100% sure. On Tue, Mar 3, 2015 at 3:32 AM, Nikita Karetnikov wrote: > I've just added instructions showing how easy it is to build GHC HEAD > and its dependencies with Nix/NixOS: > > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#NixNixOS > > I hope someone finds them useful. > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: FFI library error building GHC
Filed a bug under GHC Trac, #9620 On Sat, Sep 20, 2014 at 7:24 AM, Herbert Valerio Riedel wrote: > Hello! > > Is there a ticket for that already on GHC Trac? If not, please create > one, and try to document everything we already know about this issue > > On 2014-09-20 at 14:25:56 +0200, member MP2E wrote: > > Symlinking lib64 to lib didn't seem to work, I think the directory is > > getting cleared before build. But if I copy the contents of lib64 to lib > > after the build fails and then type make again, ghc compiles! > > > > Thanks for the workaround, hopefully a real fix will be found soon > enough :) > > > > On Sat, Sep 20, 2014 at 4:18 AM, Moritz Angermann > > > wrote: > > > >> While this is not a proper fix. Assuming there is no no lib folder, and > >> the proper lib is in lib64, does: symlinking lib64 to lib and continuing > >> with make solve the issue? > >> > >> On Sep 20, 2014, at 12:32 PM, member MP2E wrote: > >> > >> > Yep, I reported this same build error for NixOS on x86_64, > unfortunately > >> I haven't found any way to solve it. Reverting the commit that upgrades > to > >> libffi-3.1 still showed this issue. I'd love to see this fixed, as I am > >> unable to do any development on GHC until it's fixed :( > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: FFI library error building GHC
Symlinking lib64 to lib didn't seem to work, I think the directory is getting cleared before build. But if I copy the contents of lib64 to lib after the build fails and then type make again, ghc compiles! Thanks for the workaround, hopefully a real fix will be found soon enough :) On Sat, Sep 20, 2014 at 4:18 AM, Moritz Angermann wrote: > While this is not a proper fix. Assuming there is no no lib folder, and > the proper lib is in lib64, does: symlinking lib64 to lib and continuing > with make solve the issue? > > On Sep 20, 2014, at 12:32 PM, member MP2E wrote: > > > Yep, I reported this same build error for NixOS on x86_64, unfortunately > I haven't found any way to solve it. Reverting the commit that upgrades to > libffi-3.1 still showed this issue. I'd love to see this fixed, as I am > unable to do any development on GHC until it's fixed :( > > > > On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann > wrote: > > Could you check if you had any other libffi.a or (any other .a) file for > that matter in the > > libffi folder? I have the suspicion that the new libffi builds the > archives for some platforms into different target folders, as someone on > irc mentioned that for nix, there was a lib64 folder or so, and hence the > libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > > > On Sep 20, 2014, at 8:13 AM, David Feuer wrote: > > > > > I keep getting this error. Can anyone help? I tried removing the file > as suggested, but it made no difference. > > > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o > utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc > -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf > -i -iutils/genapply/. -iutils/genapply/dist/build > -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build > -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts > -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir > utils/genapply/dist/build-static -O -H64m -package pretty -package-db > libraries/bootstrapping.conf -i -iutils/genapply/. > -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen > -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen > -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > > libffi/stamp.ffi.static-shared.install exists, but > libffi/build/inst/lib/libffi.a does not. > > > Suggest removing libffi/stamp.ffi.static-shared.install. > > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > > make[1]: *** Waiting for unfinished jobs > > > make: *** [all] Error 2 > > > > > > ___ > > > ghc-devs mailing list > > > ghc-devs@haskell.org > > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > — > > Moritz Angermann > > +49 170 54 33 0 74 > > mor...@lichtzwerge.de > > > > lichtzwerge GmbH > > Freisinger Landstr. 25 > > 85748 Garching b. München > > > > Amtsgericht München HRB 207882 > > Geschäftsführung: Moritz Angermann, Ralf Sangl > > USt-Id: DE291948767 > > > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > > E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den > > Absender und vernichten Sie diese Mail. > > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > > ist nicht gestattet. > > This e-mail may contain confidential and/or privileged information. > > If you are not the intended recipient (or have received this e-mail in > > error) please notify the sender immediately and destroy this e-mail. > > Any unauthorized copying, disclosure or distribution of the material in > > this e-mail is strictly forbidden. > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Fwd: FFI library error building GHC
Yep, I reported this same build error for NixOS on x86_64, unfortunately I haven't found any way to solve it. Reverting the commit that upgrades to libffi-3.1 still showed this issue. I'd love to see this fixed, as I am unable to do any development on GHC until it's fixed :( On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann wrote: > Could you check if you had any other libffi.a or (any other .a) file for > that matter in the > libffi folder? I have the suspicion that the new libffi builds the > archives for some platforms into different target folders, as someone on > irc mentioned that for nix, there was a lib64 folder or so, and hence the > libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > On Sep 20, 2014, at 8:13 AM, David Feuer wrote: > > > I keep getting this error. Can anyone help? I tried removing the file as > suggested, but it made no difference. > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o > utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc > -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf > -i -iutils/genapply/. -iutils/genapply/dist/build > -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build > -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts > -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir > utils/genapply/dist/build-static -O -H64m -package pretty -package-db > libraries/bootstrapping.conf -i -iutils/genapply/. > -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen > -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen > -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > libffi/stamp.ffi.static-shared.install exists, but > libffi/build/inst/lib/libffi.a does not. > > Suggest removing libffi/stamp.ffi.static-shared.install. > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > make[1]: *** Waiting for unfinished jobs > > make: *** [all] Error 2 > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > — > Moritz Angermann > +49 170 54 33 0 74 > mor...@lichtzwerge.de > > lichtzwerge GmbH > Freisinger Landstr. 25 > 85748 Garching b. München > > Amtsgericht München HRB 207882 > Geschäftsführung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
i686 has been out for so long that worrying about i386 support is silly. MinGW-w64 uses i686 by default. Even i586 is *incredibly* conservative. On Jul 16, 2014 11:34 PM, "Johan Tibell" wrote: > A perhaps silly question, *should* ghc-prim be built with i386 or i686? > > On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson > wrote: > > I just found exactly the same thing! Well, I used i686 instead. > > > > Sounds like it's worthwhile to see if this is limited to ghc-prim or if > > there's more stuff that's built with i386. > > > > > > 2014-07-17 8:21 GMT+02:00 Páli Gábor János : > > > >> 2014-07-17 0:51 GMT+02:00 Páli Gábor János : > >> > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : > >> >> I hope they can just be done away with at the source, that is to make > >> >> gcc > >> >> generate the assembly primitives. GHC should already be built with > >> >> i686, but > >> >> does that reach ghc-prim? > >> > > >> > This depends on GCC -- if no -march=XXX is explicitly set, I guess it > >> > will take its default, which may vary platform by platform. > >> > >> All right, I have finally got a Windows (x64) machine and installed > >> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as > >> Niklas wrote earlier), where the default -march is i386. You should > >> see this line when trying to compile Johan's test program with the -v > >> flag set: > >> > >> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' > >> > >> With the -march=i586 flag explicitly set in the command line, no > >> __sync_fetch_and_add_n() calls are generated. > >> > >> [1] > >> > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 > > > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Fwd: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
I signed up for the mailing list to express my high level of interest in this project, I have been working with GHC 7.8 built as a cross compiler for Android and currently the only way to use libraries like lens, singletons, and anything else that uses Template Haskell is to add a patch to enable it in GHC during Stage1, and then to make drastic modifications to any cabal project source files that use TH and some hlint suggestions. Typically the current workflow for a cross-compiler is as follows: 1. Cross GHC 7.8 using the Stage1 TH patch and a few other patches available from Neurocyte. These need to be updated slightly as they are for GHC 7.6, I can post updated patches if anyone else is curious. I would be very interested in cleaning up and integrating the needed changes into GHC, if cross Template Haskell is to be implemented. 2. Create wrappers for hsc2hs and cabal for the cross compiler (I also have updated these) 3. Use a program called EvilSplicer on a log generated with 'cabal build --ghc-options=-ddump-splices 2>&1 | tee log' with the host compiler. This splices the host TH into the source files for use with the cross toolchain. You may notice this is cheating, and may not even work if the TH being generated is dependent on the target platform. 4. Remove most hlint hints used with the ANN pragma. For some reason these cause GHC to load shared objects which cause it to immediately crash(probably because of the whole host system/target system mismatch). I was told this is related to the TemplateHaskell issue Even getting lens to build is quite a chore, and I think with these changes, we could look forward to better iOS and Android support! I can't imagine the situation is much better for iOS devs at the moment. Again, I'd like to help get Android support polished, provided this change is ported and merged however I can :) On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald wrote: > This would probably be a great boon for those trying to use haskell for > Android and IOS right? how might the emulation setup work for those? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> wow, this is great work! >> >> If theres a clear path to getting the generic tooling into 7.10, i'm all >> for it :) (and willing to help on concrete mechanical subtasks) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >> wrote: >> >>> hi all, >>> >>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>> for a long time now, but so far always relied on native (host) code for it. >>> This is the main reason that GHCJS always builds native and JavaScript code >>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>> to some host-runnable form, but that can also be JavaScript if you have >>> node.js) >>> >>> Now besides the compiler having to do twice the work, this has some >>> other disadvantages: >>> >>> - Our JavaScript code has the same dependencies (packages) as native >>> code, which means packages like unix or Win32 show up somewhere, depending >>> on the host environment. This also limits our options in choosing >>> JS-specific packages. >>> - The Template Haskell code runs on the host environment, which might be >>> slightly different from the target, for example in integer size or >>> operating system specific constants. >>> >>> Moreover, building native code made the GHCJS installation procedure >>> more tricky, making end users think about libgmp or libiconv locations, >>> since it basically required the same preparation as building GHC from >>> source. This change will make installing much easier and more reliable (we >>> still have to update the build scripts). >>> >>> How it works is pretty simple: >>> >>> - When any code needs to be run on the target (hscCompileCoreExpr, >>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>> the thrunner.js [3] script, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - for every splice, GHCJS compiles it to JavaScript and links it using >>> its incremental linking functionality. The code for the splice, including >>> dependencies that have not yet been sent to the runner (for earlier >>> splices), is then sent in a RunTH [4] message, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> All Template Haskell functionality is supported, including recent >>> additions for reifying modules and annotations. I still need to clean up >>> and push the patches for the directory and process packages, but after >>> that, the TH code can read/write files, run processes and interact with >>> them and make netw
