Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

2012-01-12 Thread Dave Tapley
On 12 January 2012 15:09, Jeremy O'Donoghue  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  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#SECTION00661000
http://darcs.net/manual/Darcs_commands.html#SECTION00664000

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?

>>
>> How

[wxhaskell-devel] [ wxhaskell-Feature Requests-3472972 ] Fail gracefully when there is an architecture mis-match

2012-01-12 Thread SourceForge . net
Feature Requests item #3472972, was opened at 2012-01-12 08:09
Message generated for change (Tracker Item Submitted) made by davetapley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536848&aid=3472972&group_id=73133

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: davetapley (davetapley)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fail gracefully when there is an architecture mis-match

Initial Comment:
As identified on the mailing list, it is required that "Haskell and wxwidgets 
must use the same architecture, i.e. both 32-bit or both 64-bit" [1].

It would be nice if wxc could check the architectures, fail gracefully and emit 
a message if they are not consistent.

[1] https://sourceforge.net/mailarchive/message.php?msg_id=28665899

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=536848&aid=3472972&group_id=73133

--
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


Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

2012-01-12 Thread Jeremy O'Donoghue
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  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@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

Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

2012-01-12 Thread Frodo Kenny
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
require 'formula'

class Wxosx < Formula
  url 'http://downloads.sourceforge.net/project/wxwindows/2.9.3/wxWidgets-2.9.3.tar.bz2'
  homepage 'http://www.wxwidgets.org'
  md5 '6b6003713289ea4d3cd9b49c5db5b721'

  # depends_on 'cmake' => :build

  def install
system "./configure", "--disable-debug", "--disable-dependency-tracking",
  "--prefix=#{prefix}", "--with-osx_cocoa", "--disable-webkit",  
  "--with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk", "--with-macosx-version-min=10.6", "--enable-universal_binary"
  # , "--enable-macosx_arch=i386"
# system "cmake . #{std_cmake_parameters}"
system "make install"
  end

  def patches
# fixes deprecated QuickTime framework
DATA
  end

  # def test
  #   # This test will fail and we won't accept that! It's enough to just
  #   # replace "false" with the main program this formula installs, but
  #   # it'd be nice if you were more thorough. Test the test with
  #   # `brew test wxWidgets`. Remove this comment before submitting
  #   # your pull request!
  #   system "false"
  # end
end

__END__
diff --git a/configure b/configure