On Thu, Jan 12, 2012 at 5:19 PM, Dave Tapley <duked...@gmail.com> wrote:
> On 12 January 2012 15:09, Jeremy O'Donoghue <jeremy.odonog...@gmail.com> > 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 :) > > > > > Best regards > > Jeremy > > > > On 12 January 2012 14:52, Frodo Kenny <frodoken...@gmail.com> 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). > > >> > >> > >> > >> 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... > >> > >> > >> 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. 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@lists.sourceforge.net > >> 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@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > >
wxhaskell-dev-osx-cocoa.dpatch
Description: Binary data
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
