wxHaskell

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell From: Jeremy O'Donoghue <jeremy.odonoghue@gm...> - 2012-01-12 15:09 Attachments: Message as HTML      Thank you Kenneth, That's an extremely detailed and complete set of notes. It is very much appreciated. Best regards Jeremy On 12 January 2012 14:52, Frodo Kenny <frodokenny8@...> wrote: > Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci. > > Here are some notes and patches for OS X. I'm running Lion (10.7.2) and > getting wxwidgets running actually took the most time. > > > 1) wxwidgets > > > First of all, Haskell and wxwidgets must use the same architecture, i.e. > both 32-bit or both 64-bit. > > The standard build is 64-bit, but wxwidgets includes the QuickTime > framework which is only available in 32-bit. It builds and ghc only gives a > warning, but ghci will give an error > (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but > wrong architecture). > > To build 32-bit you can use "--enable-macosx_arch=i386". > > It looks like quicktime is only used for PICT support, which is disabled > in 64-bit builds anyway, so I made a patch that disables quicktime for both > 32 and 64 bit cocoa builds. > > By further disabling the ppc architecture, we can make a universal > 32/64-bit binary with: > > =remove -arch ppc in configure > > =remove -framework QuickTime in configure > > =remove PICT by __LP64__ -> __WXOSX_COCOA__ in bitmap.c, fontenum.c, > metafile.cpp > > > > ./configure --disable-debug --disable-dependency-tracking > --with-osx_cocoa --disable-webkit > --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk > --with-macosx-version-min=10.6 --enable-universal_binary > > > make install > > > Note that on lion with the latest Xcode, 10.6 is the lowest sdk version. > > > I use Homebrew so I attached a formula for it. To install homebrew: > > > > /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)" > > > Then put "wxosx.rb" in /usr/local/Library/Formula and run: > > > > brew install wxosx > > > > 2) wxhaskell > > > installing wxc gives: > > > cd wxc > > > cabal install > > - error wxEVT_WEBKIT_ was not declared… > > so I disabled webkit in wxwidgets above. > > > -ld: file not found: undefined > > =change "-Wl,undefined" to "-Wl,-undefined" in linkCxxOpts in Setup.hs > > > installing wxcore > > -* Missing C library: wxc > > name is wxc.so instead of libwxc.dylib > > =change for sharedLibName: OSX -> "lib" ++ addExtension basename ".dylib" > in Setup.hs > > > > ghc --make HelloWorld.hs > > Undefined symbols for architecture x86_64: > > "_expEVT_DIALUP_DISCONNECTED > > I don't know where this is coming from (dialupman is enabled in wxwidgets) > so I commented out the DIALUP lines in wxc_glue.h > > > > ./HelloWorld > > - dlopen(dist/build/libwxc.dylib) failed > > The final problem is that a dylib contains an absolute paths used for > linking, and the library is expected to be found at that locations. To set > this path we must pass the "-install_name" argument when linking > libwxc.dylib > > = OSX -> ["-dynamiclib", > > "-o " ++ out_dir </> sharedLibName ver basename, > > "-install_name " ++ basepath </> sharedLibName ver > basename, > > "-Wl,-undefined,dynamic_lookup"] > > in "linkCxxOpts", thus needing an extra "basepath" argument > > this is found by adding > > = inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr > local_bld_info NoCopyDest > > to "myBuildHook" and also using an extra argument for "linkSharedLib". > > > 3) using wxhaskell > > > "ghc --make" seems to work with the limited testing that I did > > > ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only > safe to invoke on the main thread. > > > ghci creates a new thread for each computation and under os x the gui > apparently must run on the main (first) thread. > > This is solved by: > > > ghci -fno-ghci-sandbox > > However, keyboard input is not directed to the gui but to the ghci > terminal… > > There used to be an EnableGUI module to fix this ( > http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not > seem to work anymore. > > The window can be closed and restarted from ghci though. However, the > window does not actually disappear until ghci is exited. > > Does anybody know how this was working/can be fixed? > > > Hope this is useful. > > > Regards, > > Kenneth > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > wxhaskell-devel mailing list > wxhaskell-devel@... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > >

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell From: Dave Tapley <dukedave@gm...> - 2012-01-12 16:19 On 12 January 2012 15:09, Jeremy O'Donoghue <jeremy.odonoghue@...> wrote: > Thank you Kenneth, > > That's an extremely detailed and complete set of notes. It is very much > appreciated. I'd also like to offer my thanks, this is extremely useful to us. > > Best regards > Jeremy > > On 12 January 2012 14:52, Frodo Kenny <frodokenny8@...> wrote: >> >> Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci. >> >> Here are some notes and patches for OS X. I'm running Lion (10.7.2) and >> getting wxwidgets running actually took the most time. >> >> >> 1) wxwidgets >> >> >> First of all, Haskell and wxwidgets must use the same architecture, i.e. >> both 32-bit or both 64-bit. This never occurred to me, well spotted. We should check this, so I've created a ticket: https://sourceforge.net/tracker/?func=detail&aid=3472972&group_id=73133&atid=536848 >> >> The standard build is 64-bit, but wxwidgets includes the QuickTime >> framework which is only available in 32-bit. It builds and ghc only gives a >> warning, but ghci will give an error >> (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong >> architecture). >> >> To build 32-bit you can use "--enable-macosx_arch=i386". >> >> It looks like quicktime is only used for PICT support, which is disabled >> in 64-bit builds anyway, so I made a patch that disables quicktime for both >> 32 and 64 bit cocoa builds. >> >> By further disabling the ppc architecture, we can make a universal >> 32/64-bit binary with: >> >> =remove -arch ppc in configure >> >> =remove -framework QuickTime in configure >> >> =remove PICT by __LP64__ -> __WXOSX_COCOA__ in bitmap.c, fontenum.c, >> metafile.cpp >> >> >> > ./configure --disable-debug --disable-dependency-tracking >> > --with-osx_cocoa --disable-webkit >> > --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk >> > --with-macosx-version-min=10.6 --enable-universal_binary >> >> > make install >> >> >> Note that on lion with the latest Xcode, 10.6 is the lowest sdk version. >> >> >> I use Homebrew so I attached a formula for it. To install homebrew: >> >> >> > /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)" >> >> >> Then put "wxosx.rb" in /usr/local/Library/Formula and run: >> >> >> > brew install wxosx I'm not an OS X person, so this doesn't really mean anything to me; is it something which should be on the wiki? >> >> >> >> 2) wxhaskell >> >> >> installing wxc gives: >> >> > cd wxc >> >> > cabal install >> >> - error wxEVT_WEBKIT_ was not declared… >> >> so I disabled webkit in wxwidgets above. >> >> >> -ld: file not found: undefined >> >> =change "-Wl,undefined" to "-Wl,-undefined" in linkCxxOpts in Setup.hs >> >> >> installing wxcore >> >> -* Missing C library: wxc >> >> name is wxc.so instead of libwxc.dylib >> >> =change for sharedLibName: OSX -> "lib" ++ addExtension basename ".dylib" >> in Setup.hs >> >> >> > ghc --make HelloWorld.hs >> >> Undefined symbols for architecture x86_64: >> >>   "_expEVT_DIALUP_DISCONNECTED >> >> I don't know where this is coming from (dialupman is enabled in wxwidgets) >> so I commented out the DIALUP lines in wxc_glue.h >> >> >> > ./HelloWorld >> >> - dlopen(dist/build/libwxc.dylib) failed >> >> The final problem is that a dylib contains an absolute paths used for >> linking, and the library is expected to be found at that locations. To set >> this path we must pass the "-install_name" argument when linking >> libwxc.dylib >> >> =      OSX -> ["-dynamiclib", >> >>                   "-o " ++ out_dir </> sharedLibName ver basename, >> >>                   "-install_name " ++ basepath </> sharedLibName ver >> basename, >> >>                   "-Wl,-undefined,dynamic_lookup"] >> >> in "linkCxxOpts", thus needing an extra "basepath" argument >> >> this is found by adding >> >> =        inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr >> local_bld_info NoCopyDest >> >> to "myBuildHook" and also using an extra argument for "linkSharedLib". Thank you very much for the patch, but I have one tiny request: I can't apply wxhaskell-osx.patch because the structure doesn't match the one on my system. Could you record it with darcs and send the patch bundle as an attachment (darcs send -o mypatch.dpatch) http://darcs.net/manual/Darcs_commands.html#SECTION00661000000000000000 http://darcs.net/manual/Darcs_commands.html#SECTION00664000000000000000 Also, if you record the patches your name will forever be attached to them and you will received the karma you deserve :) >> >> >> 3) using wxhaskell >> >> >> "ghc --make" seems to work with the limited testing that I did >> >> >> ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only >> safe to invoke on the main thread. >> >> >> ghci creates a new thread for each computation and under os x the gui >> apparently must run on the main (first) thread. >> >> This is solved by: >> >> > ghci -fno-ghci-sandbox Another good tip for the wiki perhaps? I wonder if there is a way to indicate at a package level that this is required? >> >> However, keyboard input is not directed to the gui but to the ghci >> terminal… >> >> There used to be an EnableGUI module to fix this >> (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not >> seem to work anymore. >> >> The window can be closed and restarted from ghci though. However, the >> window does not actually disappear until ghci is exited. I'm a little confused by this statement? Do you mean: You can close the window, and ghci returns to the prompt, but the actual window manager window remains? Dave, >> >> Does anybody know how this was working/can be fixed? >> >> >> Hope this is useful. >> >> >> Regards, >> >> Kenneth >> >> >> >> >> ------------------------------------------------------------------------------ >> RSA(R) Conference 2012 >> Mar 27 - Feb 2 >> Save $400 by Jan. 27 >> Register now! >> http://p.sf.net/sfu/rsa-sfdev2dev2 >> _______________________________________________ >> wxhaskell-devel mailing list >> wxhaskell-devel@... >> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel >> > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > wxhaskell-devel mailing list > wxhaskell-devel@... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel >

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell From: Frodo Kenny <frodokenny8@gm...> - 2012-01-13 16:28 Attachments: Message as HTML      wxhaskell-dev-osx-cocoa.dpatch

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell From: Dave Tapley <dukedave@gm...> - 2012-01-13 18:58 On 13 January 2012 16:28, Frodo Kenny <frodokenny8@...> wrote: > > On Thu, Jan 12, 2012 at 5:19 PM, Dave Tapley <dukedave@...> wrote: >> >> On 12 January 2012 15:09, Jeremy O'Donoghue <jeremy.odonoghue@...> >> wrote: >> > Thank you Kenneth, >> > >> > That's an extremely detailed and complete set of notes. It is very much >> > appreciated. >> >> I'd also like to offer my thanks, this is extremely useful to us. > > > You're welcome. Thanks for replying otherwise my post would not even be > visible. I guess some copy-past action html-ified it. And here I was > thinking attachments would be a problem :) I noticed that, very strange.. > >> >> >> > >> > Best regards >> > Jeremy >> > >> > On 12 January 2012 14:52, Frodo Kenny <frodokenny8@...> wrote: >> >> >> >> Nice work. I was still on GHC 6.10 to be able to use wxhaskell with >> >> ghci. >> >> >> >> Here are some notes and patches for OS X. I'm running Lion (10.7.2) and >> >> getting wxwidgets running actually took the most time. >> >> >> >> >> >> 1) wxwidgets >> >> >> >> >> >> First of all, Haskell and wxwidgets must use the same architecture, >> >> i.e. >> >> both 32-bit or both 64-bit. >> >> This never occurred to me, well spotted. >> We should check this, so I've created a ticket: >> >> https://sourceforge.net/tracker/?func=detail&aid=3472972&group_id=73133&atid=536848 > > > Good idea. > >> >> >> >> >> The standard build is 64-bit, but wxwidgets includes the QuickTime >> >> framework which is only available in 32-bit. It builds and ghc only >> >> gives a >> >> warning, but ghci will give an error >> >> (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but >> >> wrong >> >> architecture). >> >> >> >> To build 32-bit you can use "--enable-macosx_arch=i386". >> >> >> >> It looks like quicktime is only used for PICT support, which is >> >> disabled >> >> in 64-bit builds anyway, so I made a patch that disables quicktime for >> >> both >> >> 32 and 64 bit cocoa builds. >> >> >> >> By further disabling the ppc architecture, we can make a universal >> >> 32/64-bit binary with: >> >> >> >> =remove -arch ppc in configure >> >> >> >> =remove -framework QuickTime in configure >> >> >> >> =remove PICT by __LP64__ -> __WXOSX_COCOA__ in bitmap.c, fontenum.c, >> >> metafile.cpp >> >> >> >> >> >> > ./configure --disable-debug --disable-dependency-tracking >> >> > --with-osx_cocoa --disable-webkit >> >> > --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk >> >> > --with-macosx-version-min=10.6 --enable-universal_binary >> >> >> >> > make install >> >> >> >> >> >> Note that on lion with the latest Xcode, 10.6 is the lowest sdk >> >> version. >> >> >> >> >> >> I use Homebrew so I attached a formula for it. To install homebrew: >> >> >> >> >> >> > /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)" >> >> >> >> >> >> Then put "wxosx.rb" in /usr/local/Library/Formula and run: >> >> >> >> >> >> > brew install wxosx >> >> I'm not an OS X person, so this doesn't really mean anything to me; is >> it something which should be on the wiki? > > > I think that would be useful (homebrew is a package manager and the attached > "formula" applies the patches and installs wxwidgets 2.9.3 relatively easy). Ah, thanks for the explanation. > >> >> >> >> >> >> >> >> >> >> 2) wxhaskell >> >> >> >> >> >> installing wxc gives: >> >> >> >> > cd wxc >> >> >> >> > cabal install >> >> >> >> - error wxEVT_WEBKIT_ was not declared… >> >> >> >> so I disabled webkit in wxwidgets above. >> >> >> >> >> >> -ld: file not found: undefined >> >> >> >> =change "-Wl,undefined" to "-Wl,-undefined" in linkCxxOpts in Setup.hs >> >> >> >> >> >> installing wxcore >> >> >> >> -* Missing C library: wxc >> >> >> >> name is wxc.so instead of libwxc.dylib >> >> >> >> =change for sharedLibName: OSX -> "lib" ++ addExtension basename >> >> ".dylib" >> >> in Setup.hs >> >> >> >> >> >> > ghc --make HelloWorld.hs >> >> >> >> Undefined symbols for architecture x86_64: >> >> >> >>   "_expEVT_DIALUP_DISCONNECTED >> >> >> >> I don't know where this is coming from (dialupman is enabled in >> >> wxwidgets) >> >> so I commented out the DIALUP lines in wxc_glue.h >> >> >> >> >> >> > ./HelloWorld >> >> >> >> - dlopen(dist/build/libwxc.dylib) failed >> >> >> >> The final problem is that a dylib contains an absolute paths used for >> >> linking, and the library is expected to be found at that locations. To >> >> set >> >> this path we must pass the "-install_name" argument when linking >> >> libwxc.dylib >> >> >> >> =      OSX -> ["-dynamiclib", >> >> >> >>                   "-o " ++ out_dir </> sharedLibName ver basename, >> >> >> >>                   "-install_name " ++ basepath </> sharedLibName ver >> >> basename, >> >> >> >>                   "-Wl,-undefined,dynamic_lookup"] >> >> >> >> in "linkCxxOpts", thus needing an extra "basepath" argument >> >> >> >> this is found by adding >> >> >> >> =        inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr >> >> local_bld_info NoCopyDest >> >> >> >> to "myBuildHook" and also using an extra argument for "linkSharedLib". >> >> Thank you very much for the patch, but I have one tiny request: >> I can't apply wxhaskell-osx.patch because the structure doesn't match >> the one on my system. >> >> Could you record it with darcs and send the patch bundle as an >> attachment (darcs send -o mypatch.dpatch) >> http://darcs.net/manual/Darcs_commands.html#SECTION00661000000000000000 >> http://darcs.net/manual/Darcs_commands.html#SECTION00664000000000000000 >> >> Also, if you record the patches your name will forever be attached to >> them and you will received the karma you deserve :) >> > > Done. The diff was only for the wxc directory, so maybe that was it. But > karma is nice... Mm, I do love me some darcs send, the patch applied successfully and is now in -dev repo: http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120113131345-1ccc1 Thank you for your contribution :) > >> >> >> >> >> >> >> 3) using wxhaskell >> >> >> >> >> >> "ghc --make" seems to work with the limited testing that I did >> >> >> >> >> >> ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only >> >> safe to invoke on the main thread. >> >> >> >> >> >> ghci creates a new thread for each computation and under os x the gui >> >> apparently must run on the main (first) thread. >> >> >> >> This is solved by: >> >> >> >> > ghci -fno-ghci-sandbox >> >> Another good tip for the wiki perhaps? >> I wonder if there is a way to indicate at a package level that this is >> required? >> >> >> >> >> However, keyboard input is not directed to the gui but to the ghci >> >> terminal… >> >> >> >> There used to be an EnableGUI module to fix this >> >> (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does >> >> not >> >> seem to work anymore. >> >> >> >> The window can be closed and restarted from ghci though. However, the >> >> window does not actually disappear until ghci is exited. >> >> I'm a little confused by this statement? >> Do you mean: You can close the window, and ghci returns to the prompt, >> but the actual window manager window remains? > > > If I press the close button (there is no menubar), the window does not > actually disappear but it does not react to any (mouse) inputs anymore and > the ghci prompt returns. Without keyboard input going to the gui and without > a menu bar, the gui is not really useful yet I guess, so I hope this is > fixable. Oh, I understand now. I haven't heard of this before, but it sounds like exactly the kind of weirdness I'd expect. Anyone? > > Kenneth > >> >> >> Dave, >> >> >> >> >> Does anybody know how this was working/can be fixed? >> >> >> >> >> >> Hope this is useful. >> >> >> >> >> >> Regards, >> >> >> >> Kenneth >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> RSA(R) Conference 2012 >> >> Mar 27 - Feb 2 >> >> Save $400 by Jan. 27 >> >> Register now! >> >> http://p.sf.net/sfu/rsa-sfdev2dev2 >> >> _______________________________________________ >> >> wxhaskell-devel mailing list >> >> wxhaskell-devel@... >> >> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel >> >> >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > RSA(R) Conference 2012 >> > Mar 27 - Feb 2 >> > Save $400 by Jan. 27 >> > Register now! >> > http://p.sf.net/sfu/rsa-sfdev2dev2 >> > _______________________________________________ >> > wxhaskell-devel mailing list >> > wxhaskell-devel@... >> > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel >> > > >

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell From: Frodo Kenny <frodokenny8@gm...> - 2012-01-23 14:58 >>> >> >>> >> However, keyboard input is not directed to the gui but to the ghci >>> >> terminal… >>> >> >>> >> There used to be an EnableGUI module to fix this >>> >> (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does >>> >> not >>> >> seem to work anymore. >>> >> >>> >> The window can be closed and restarted from ghci though. However, the >>> >> window does not actually disappear until ghci is exited. >>> >>> I'm a little confused by this statement? >>> Do you mean: You can close the window, and ghci returns to the prompt, >>> but the actual window manager window remains? >> >> >> If I press the close button (there is no menubar), the window does not >> actually disappear but it does not react to any (mouse) inputs anymore and >> the ghci prompt returns. Without keyboard input going to the gui and without >> a menu bar, the gui is not really useful yet I guess, so I hope this is >> fixable. > > Oh, I understand now. > I haven't heard of this before, but it sounds like exactly the kind of > weirdness I'd expect. > Anyone? > Hmm, it appears the example I was using was broke. With the HelloWorld sample and using: main = enableGUI >> start hello the mouse and keyboard input do go to the window under GHCi. So this is great as I now can do everything I could do before in GHC 6.10. If I close the window it does remain visible in an unusable state until you exit ghci. However, control returns to GHCi and I can restart the application (i.e. run "main" again), re-using the same window. So that is an improvement over before (which crashed ghci when closing the window).

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell From: Frodo Kenny <frodokenny8@gm...> - 2012-01-25 20:31 I did some more tests and the 32-bit version is not compiling. The problem is that the 32-bit flags (-m32) are not passed to ld when linking. That in turn is caused by the following: > But on hitting that line the following error is spat out: > /usr/bin/ld: cannot open output file  dist/build/libwxc.so.0.13.1: No > such file or directory > > I checked all my permissions and couldn't see anything wrong, I could > touch the file. > Conveniently I noticed that, if the verbosity is set high enough, > runProgram will call printRawCommandAndArgs: > http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-Utils.html#printRawCommandAndArgs > > The output (i.e. the linker invocation) looks like this: > /usr/bin/gcc -fno-stack-protector -shared -Wl,-soname,libwxc.so.0 -o > dist/build/libwxc.so.0.13.1 dist/build/src/cpp/apppath.o > dist/build/src/cpp/dragimage.o dist/build/src/cpp/eljaccelerator.o > [snip-rest-of-.o-files] -L/usr/local/lib -lstdc++ -lwx_baseu-2.9 > [snip-rest-of-wx-libs] > > Now if I cd into the wxcore and paste the command *verbatim* then gcc > works and generates libwxc.so.0.13.1 as expected. > You can see in Jeremy's code the linkShareLib function contains: >> cwd <- getCurrentDirectory > > I used this to confirm that the we were in ./wxcore and we are, even > making the path for -o absolute didn't sovle the issue. > I ended up replacing runProgram line with this, less satisfactory line: >> system $ (unwords ([show . locationPath . programLocation $ gcc] ++ opts' ++ objs' ++ lib_dirs' ++ libs')) > > Which works, but still doesn't explain why runProgram doesn't. > Any suggestions? The workaround is missing the default arguments. It works again if I change it to: > args = opts' ++ objs' ++ lib_dirs' ++ libs' > system $ (unwords ([programPath gcc] ++ programDefaultArgs gcc ++ args ++ programOverrideArgs gcc )) Incidentally I also tried the runProgram version, which gave me a similar error: > ld: unknown option: -o dist/build/libwxc.dylib I traced the problem down to the rawSystem call, i.e. in ghci: > rawSystem "/usr/bin/gcc" ["-o test", "dist/build/cpp/apppath.o"] gives the same error. I guess gcc/ld does not handle raw strings well???

4 messages have been excluded from this view by a project administrator.