Opened 17 years ago

Closed 5 years ago

#5006 closed submission (wontfix)

NEW: wxhaskell-0.9.4

Reported by: eric.kow@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: cooljeanius (Eric Gallager)
Port:

Description (last modified by mf2k (Frank Schima))

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.

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

Attachments (3)

wxhaskell.tgz (26.6 KB) - added by eric.kow@… 17 years ago.
the portfile and its patches
wxhaskell.2.tgz (26.7 KB) - added by eric.kow@… 17 years ago.
gcc 4.0 version of the portfile
patch-wxhaskell-makefile-osx (839 bytes) - added by eric.kow@… 17 years ago.
makefile patch to bypass the compile-as-static-lib phase

Download all attachments as: .zip

Change History (34)

Changed 17 years ago by eric.kow@…

Attachment: wxhaskell.tgz added

the portfile and its patches

comment:1 Changed 17 years ago by 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

comment:2 Changed 17 years ago by 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

comment:3 Changed 17 years ago by 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

comment:4 Changed 17 years ago by 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

comment:5 Changed 17 years ago by gwright@…

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

What's your platform?

-Greg

Changed 17 years ago by eric.kow@…

Attachment: wxhaskell.2.tgz added

gcc 4.0 version of the portfile

comment:6 Changed 17 years ago by 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

comment:7 Changed 17 years ago by gwright@…

Owner: changed from darwinports-bugs@… to 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

comment:8 Changed 17 years ago by gwright@…

Status: newassigned

comment:9 Changed 17 years ago by 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

comment:10 Changed 17 years ago by 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?

comment:11 Changed 17 years ago by 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

comment:12 Changed 17 years ago by 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

comment:13 Changed 17 years ago by mww@…

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

comment:14 Changed 17 years ago by eric.kow@…

Hello!

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

comment:15 Changed 17 years ago by 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

comment:16 Changed 17 years ago by 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

comment:17 Changed 17 years ago by 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,

comment:18 Changed 17 years ago by 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

Changed 17 years ago by eric.kow@…

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

comment:19 Changed 17 years ago by 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...

comment:20 Changed 16 years ago by markd@…

Type: defectenhancement

comment:21 Changed 16 years ago by kballard (Lily Ballard)

Milestone: New Ports

comment:22 Changed 16 years ago by jmpp@…

Milestone: New PortsPort Submissions

Milestone New Ports deleted

comment:23 Changed 15 years ago by nox@…

Priority: ExpectedNormal
Version: 1.0

comment:24 Changed 14 years ago by jmroot (Joshua Root)

Type: enhancementsubmission

comment:25 Changed 14 years ago by (none)

Milestone: Port Submissions

Milestone Port Submissions deleted

comment:26 Changed 10 years ago by cooljeanius (Eric Gallager)

The project has moved to Github: https://github.com/jodonoghue/wxHaskell

comment:27 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:28 Changed 10 years ago by cooljeanius (Eric Gallager)

It also has a cabal package: http://hackage.haskell.org/package/wx-0.90.0.1

Wasn't someone working on a cabal2port converter script or something at one point? If so, they could use it here...

comment:29 Changed 10 years ago by cooljeanius (Eric Gallager)

I opened a ticket upstream asking them to help us with this: https://github.com/jodonoghue/wxHaskell/issues/14

comment:30 Changed 8 years ago by mf2k (Frank Schima)

Description: modified (diff)
Owner: changed from gwright@… to macports-tickets@…
Status: assignednew

gwright has retired. See #43784.

comment:31 Changed 5 years ago by kencu (Ken)

Resolution: wontfix
Status: newclosed

@12 years, this is the oldest ticket I have ever seen. If this is still relevant to anyone, please open a new ticket.

Note: See TracTickets for help on using tickets.