NEW: wxhaskell-0.9.4

[eric.kow@…]

wxhaskell-0.9.4

the portfile can be found here: ATTACHED

Description: provides a Haskell interface to the wxWidgets GUI toolkit Includes patches to 1. support Unicode so that it can be used with the wxWidgets that comes with Tiger or with the standard DarwinPorts variants. 2. force the use of g++-3.3 because for the moment, the ghc haskell compiler does not like 4.0

Homepage:  http://wxhaskell.sourceforge.net

Comments: I have only tested it on any OS X Tiger (my computer, a friend's computer and a chroot). There are some sample applications which don't run correctly, but this seems due to the wxWidgets 2.5.3 that comes with Tiger.

[eric.kow@…]

the portfile and its patches

[mww@…]

currently the wxWidget port compiles with gcc-4.0 - this seems to be a little problem as the linker fails: --- ... ld: out/wxc/master.o undefined symbol 14173 (ZThn480_N9wxListBox19DoSetItemClientDataEiPv) can't be a weak definition /usr/bin/libtool: internal link edit command failed make: *** [out/wxc/libwxc-mac2.6.1-0.9.4.dylib] Error 1

[eric.kow@…]

Oh dear.

Would it be useful to make this port only available for Tiger? Or maybe another useful thing to do is to make wxhaskell request a gcc 3.3 variant of wxWidgets?

There's two reasons for using gcc 3.3 for the wxhaskell port: ghc (as mentioned), and the other I forgot mention: the wxWidgets preinstalled with Tiger seems to compiled with gcc 3.3

[gwright@…]

The ghc 6.4.1 compiler (update your portfiles!) is perfectly happy with gcc 4.0.

And for reasons that have been discussed at length on the mailing list in the past, wxHaskell should not depend on the Apple installed wxWidgets. It should install its own port. (In short, the Apple installed wxWidgets may have incompatible changes for Apple's own purposes and is not guaranteed to work with wxHaskell and may be changed without warning in the future.)

I suggest trying wxHaskell with ghc 6.4.1 + wxWidget port then making any changes needed. I'll be happy to test it out.

Best Wishes, Greg

[eric.kow@…]

Argh!

So I've tried switching to gcc 4.0, ghc 6.4.1, compiling the wxWidgets port, and I get the same "weak definition" error.

So the linker troubles don't seem to be some kind of gcc mismatch thing. Does anybody know how else I could deal with this?

ld: out/wxc/master.o undefined symbol 11387 (ZTI10wxListBase) can't be a weak definition

[gwright@…]

I'll test it on my G4 1.5GHz 1GB powerbook running 10.4.2.

What's your platform?

-Greg

[eric.kow@…]

gcc 4.0 version of the portfile

[eric.kow@…]

Many thanks. It'd be interesting to see what turns up. The second attachment (gcc 4.0) contains the current Portfile -- slightly modified not to force g++-3.3 and to use the wxWidgets port.

I am on a 1.8GHz 1GB iMac G5 running 10.4.2

[gwright@…]

I'll assign the bug to myself, since I support most of the haskell stuff on DP.

Then it will show up on my list and be less likely to fall through the cracks.

-Greg

[gwright@…]

Just so you know I am still working on this. The latest libSDL build fails because it tries to link both static and dynamic versions of the same libraries. I'll have to fix this before I can finish building wxWidgets.

-Greg

[eric.kow@…]

Thanks for keeping in touch :-)

By the way, the wxhaskell site recommends a static build of wxWidgets. Do you think this is related to the problems we are having?

[gwright@…]

There's clearly some issue with static vs. dynamic linking but this failure to build libSDL looks simply like a bug.

I'll just keep bashing on the dependencies until they all build correctly. Then we can look at the hard part ;-)

-Greg

[eric.kow@…]

Hi,

While you were basing away on the SDL stuff, I've tried compiling wxWidgets with --disable-shared and found that this links much more nicely with wxhaskell. (with gcc 4.0)

What would be nice is to have a wxWidgets static variant that co-exists with the shared wxWidgets. What would be nicer is for these two ports to be somehow built together so we don't double the compiling effort. If we had something like this, then the wxhaskell port could rely on the wxWidgets+static variant. What do you think is the best way to proceed (post dep-bashing of course)?

-Eric

[mww@…]

don't know if this makes a difference, but I just updated wxWidgets to 2.6.2;

[eric.kow@…]

Hello!

Sorry, I'm just trying to be squeaky as far as wheels go :-) How are things going with the dependency bashing?

[gwright@…]

I rebuilt essentially all of the dependencies short of wxWidgets itself last weekend. I should be able to try another wxWidgets build tomorrow.

I'm currently working at the south pole (really!) and we only have satellite connection to the internet a few hours a day. This has slowed things down.

Thanks for the ping!

-Greg

[gwright@…]

An update:

I can get wxWidgets 2.6.2 to build, but there reamins a linker error in wxHaskell.

I have fixed one compiler bug (patched in DP's ghc; will be fixed in the ghc 6.4.2 distribution). There is another linker issue in ghc on OS X that I am trying to track down and fix. It may be relevant to the linker problem seen in wxHaskell.

-Greg

[eric.kow@…]

Hello!

(In reply to comment #17)

I can get wxWidgets 2.6.2 to build, but there reamins a linker error in wxHaskell.

Do your errors look this? ld: out/wxc/master.o undefined symbol 36218 (ZdaPv) can't be a weak definition

If so, Jean Boucquey has found a fix which consists of "[adding] a static C++ standard lib to the libraries used to build 'master.o'"

 http://sourceforge.net/mailarchive/message.php?msg_id=14698554

It doesn't seem like the "right" thing to do, but it... erm... works.

Cheers,

[gwright@…]

Hi Eric,

Just last week I tried building wxhaskell using the new wxWidgets release candidate. I had the linking bug you mentioned. I'll give the fix a try.

It actually makes a bit of sense---the linker is confuse by a weak (i.e., overridable) definition, and statically linking may provide a default definition of the symbol.

Greg

[eric.kow@…]

makefile patch to bypass the compile-as-static-lib phase

[eric.kow@…]

Hi!

So it seems that a handful of wxhaskell users have finally figured out how to get it to compile on our Macs. There are two different approaches: one is to twiddle the settings for how you compile as a static lib, but it needs XCode 2.3. The other approach is to bypass the static lib phase altogether and just compile directly to dylib.

See

 http://www.haskell.org/haskellwiki/WxHaskell/Installation_tips (1st approach)  http://www.loria.fr/~kow/download/patch-wxhaskell-makefile-osx (2nd approach, also attached)

I'm not sure which is the right way to go. I use the second one simply because I'm too lazy to upgrade my XCode, but the first one has the advantage of being closer to the author's original intention...

[jmpp@…]

Milestone New Ports deleted

[anonymous]

Milestone Port Submissions deleted