Menu
▾
▴
wxhaskell-devel — wxhaskell developers
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(53) |
Mar
(145) |
Apr
(22) |
May
(7) |
Jun
(14) |
Jul
(14) |
Aug
(9) |
Sep
(10) |
Oct
(48) |
Nov
(59) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(36) |
Feb
(5) |
Mar
(33) |
Apr
(28) |
May
(5) |
Jun
(6) |
Jul
(1) |
Aug
(7) |
Sep
(11) |
Oct
(3) |
Nov
(31) |
Dec
|
| 2010 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(9) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(1) |
May
(2) |
Jun
(12) |
Jul
(36) |
Aug
(7) |
Sep
(40) |
Oct
(6) |
Nov
(40) |
Dec
(8) |
| 2012 |
Jan
(54) |
Feb
(8) |
Mar
(1) |
Apr
(16) |
May
(2) |
Jun
(12) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(7) |
| 2013 |
Jan
(8) |
Feb
|
Mar
(13) |
Apr
(2) |
May
(13) |
Jun
(44) |
Jul
|
Aug
(13) |
Sep
(12) |
Oct
(11) |
Nov
(7) |
Dec
(6) |
| 2014 |
Jan
(3) |
Feb
(4) |
Mar
(9) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
(3) |
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew B. <and...@cs...> - 2012-04-24 08:33:04
|
Hi,
as some of you may know, I have been using wxHaskell for a project
of mine for quite a while - but I'm stuck in the dark ages:
ghc 6.10.4, wxMSW 2.8.10 wx 0.11.1.2-0
Being able to run from ghci (even just the once) is essential for me.
Occasionally I pop up on the users list and complain about the difficulty
in building something new and exciting (like ghc 7.0.3. and wx 0.9)
as happened yesterday.
Rather than occasionally beating up on you guys, I'd like to help
in some way - but I'm not a hardcore software developer - I prefer
(as I suspect do we all) to work with Haskell in GHCi developing
nice programs that just build and run (the only flags in sight
are -fglasgow-exts -package wx ). As a day job I am an academic so
don't actually have to write any code that works or can be delivered to anyone.
So - I don't have any deep experience in gcc/makefile building,
or the complexities of cabal, or multiple architectures.
What I do find frustrating is the lack of clear instructions for someone
of my lack of such hardcore development experience for the installation
of wxHaskell.
What I am suggesting is that I help to develop those instructions by
(1) cleaning up the dross leftover from previous attempts
(2) Following them carefully (keeping a diary)
and adding feedback on the instructions to the wiki (using the Discussion facility)
(3) Updating the wiki once some consensus on revised instructions have been reached
Does this seem reasonable to you guys?
I propose starting with the WxHaskell/Windows process first...
PS Eric, - I had this email composed and ready to go just before your reply
to me on wxhaskell-users !
--------------------------------------------------------------------
Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Foundations & Methods Research Group
Director of Teaching and Learning - Undergraduate,
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------
|
|
From: Jeremy O'D. <jer...@gm...> - 2012-04-23 12:10:08
|
Thanks David. On 23 April 2012 10:07, David Virebayre <dav...@gm...> wrote: > Sorry, I posted that before I actually checked the packages names.. It's > > Le 23 avril 2012 11:04, David Virebayre <dav...@gm...> a > écrit : > > sudo apt-get install wxwidgets2.8-deaders libwxgtk2.8-dev >> > > sudo apt-get install wx2.8-headers libwxgtk2.8-dev > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
|
From: David V. <dav...@gm...> - 2012-04-23 09:07:16
|
Sorry, I posted that before I actually checked the packages names.. It's Le 23 avril 2012 11:04, David Virebayre <dav...@gm...> a écrit : > sudo apt-get install wxwidgets2.8-deaders libwxgtk2.8-dev > sudo apt-get install wx2.8-headers libwxgtk2.8-dev |
|
From: David V. <dav...@gm...> - 2012-04-23 09:04:55
|
Hello list. Documenting how to install wxhaskell for users of (k)ubuntu 11.10. Since wxwidgets 2.9 isn't available in the base repositories, one may want to install the previous version of wxwidgets. but cabal install wx-0.13.2.1 failed, because it depends on wxcore (≥0.13.1) which results in it trying to install wxcore-0.90. So I did : sudo apt-get install wxwidgets2.8-deaders libwxgtk2.8-dev cabal install wxcore-0.13.2.1 cabal install wx-0.13.2.1 David. |
|
From: Heinrich A. <apf...@qu...> - 2012-04-18 13:03:26
|
Jeremy O'Donoghue wrote: > Hi developers, > > I wanted to canvas opinion about moving wxHaskell development from darcs on > code.haskell.org to (git, obviously) on GitHub. > > Potential advantages: > > - Easier for new committers to commit code > - GitHub provides some pretty decent tools (integrated issue tracker, > particularly) > - Easier handling of the wxWidgets 2.8/2.9 branches. I'm pretty > impressed at the way git does this (and was not impressed by merging Dave > Tapley's darcsden branch back into the code.haskell.org mainline using > darcs - this turned out to be a completely manual operation which was no > fun at all). > > Downsides: > > - I personally find darcs easier than git, and as Haskellers we should > promote darcs if possible > - Possibly a new tool for old hands to learn > > I would say that a move is probably only worthwhile if we think that it > would help to attract new developer to the project. > > I have put up an experimental project at > https://github.com/jodonoghue/wxHaskell which gives an idea how the two > branches would look. > > One option might be to use wxHaskell as a test case for darcs-bridge, in > which case we could allow commits to darcs or Github, but I'll leave it to > Eric to decide whether darcs bridge is ready for such a use case. I'm in favor of a move to GitHub. The barrier to entry is a lot lower. When creating issues, people will often include a "pull request" (i.e. patch) if they were able to solve it themselves. I use Git it for all my projects, but that's mainly because I use a GUI environment ("SmartGit") so that I don't have to learn the command line. In other words: I never really learned how Git works and I can still use it without (major) problems. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com |
|
From: Eric K. <eri...@gm...> - 2012-04-18 10:32:24
|
Hi! I guess I'd better weigh in as a darcs developer here (though speaking for myself only). Generally, I like to encourage Darcs users to give Git a chance and explore GitHub so they understand first hand what they might be missing out on if they do not already. I don't mean to chase people away, of course! Naturally, my encouraging people to use Git conflicts with my desire for Darcs to have a supporting base for the Darcs agenda of building a better version control system. The reason is simply that a feeling that it would irresponsible for me to let my desire override your best interests. If the Git model works better for you, or if Darcs cannot yet scale to your team size, or if GitHub enhances collaboration in a way that a version control system cannot on its own, or if you simply feel that the network effects of everybody else being on GitHub are too important to pass up; by all means, switch. I wouldn't want people to be using Darcs either out of Haskell brand loyalty (we are way beyond/before that), or out of unfamiliarity with Git. Basically, the kind of users I would want us to have are those that know what they are getting into, that know Darcs both for its simplicity and its flaws. Finally, about Darcs Bridge: > One option might be to use wxHaskell as a test case for darcs-bridge, in which case we could allow commits to darcs or Github, but I'll leave it to Eric to decide whether darcs bridge is ready for such a use case. It's worth considering for the future. I think right now you're best off focusing on one and then maybe re-enabling the bridge later on. Anyway, by all means, do give it a try! You can always come back later. Eric PS. Darcs users should know that git add -p somewhat approximates darcs interactive record; often it's all that people miss -- Eric Kow <http://erickow.com> |
|
From: Jeremy O'D. <jer...@gm...> - 2012-04-18 05:07:40
|
Hi developers, I wanted to canvas opinion about moving wxHaskell development from darcs on code.haskell.org to (git, obviously) on GitHub. Potential advantages: - Easier for new committers to commit code - GitHub provides some pretty decent tools (integrated issue tracker, particularly) - Easier handling of the wxWidgets 2.8/2.9 branches. I'm pretty impressed at the way git does this (and was not impressed by merging Dave Tapley's darcsden branch back into the code.haskell.org mainline using darcs - this turned out to be a completely manual operation which was no fun at all). Downsides: - I personally find darcs easier than git, and as Haskellers we should promote darcs if possible - Possibly a new tool for old hands to learn I would say that a move is probably only worthwhile if we think that it would help to attract new developer to the project. I have put up an experimental project at https://github.com/jodonoghue/wxHaskell which gives an idea how the two branches would look. One option might be to use wxHaskell as a test case for darcs-bridge, in which case we could allow commits to darcs or Github, but I'll leave it to Eric to decide whether darcs bridge is ready for such a use case. Regards Jeremy |
|
From: SourceForge.net <no...@so...> - 2012-04-17 13:15:46
|
Bugs item #3518787, was opened at 2012-04-17 06:15 Message generated for change (Tracker Item Submitted) made by peti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=536845&aid=3518787&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 Resolution: None Priority: 5 Private: No Submitted By: Peter Simons (peti) Assigned to: Nobody/Anonymous (nobody) Summary: wxc build doesn't install libwxc.so Initial Comment: When I build and install wxc on Nixos, then the Setup.hs procedure fails to installs the generated libwxc.so DLL into the target directory. A complete build log is attached below that shows the output from running "./Setup configure -v3 && ./Setup build && ./Setup copy -v3". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=536845&aid=3518787&group_id=73133 |
|
From: Eric K. <eri...@gm...> - 2012-04-16 08:35:47
|
Noticed this when trying to cabal-dev install my stuff. 1 patch for repository http://code.haskell.org/wxhaskell: Mon Apr 16 09:25:24 BST 2012 Eric Kow <eri...@gm...> * Try a little harder to find wxc install directory. Users of cabal-dev may find that the wxc include dir does not have wxc anywhere in its path, eg. /home/moi/my-package/cabal-dev//lib//include So instead we try looking for the wxc.h file itself. |
|
From: Henning T. <le...@he...> - 2012-04-05 11:53:19
|
On Wed, 4 Apr 2012, Jeremy O'Donoghue wrote: > I'm not quite comfortable moving to 1.0 - sounds a bit 'finished' to me. Somehow yes. But wxhaskell is already very good and usable for my taste. So 1.0 would be justified even for the current version. Even more we have packages like HTTP with version 4000. :-) > How about a compromise: I'll bump the new version to 0.20. Sure, this would be a compromise, but psychologically it puts pressure on us to not release too often to Hackage, since every release reduces the available number of major bumps. Nonetheless I would feel more comfortable if other wxhaskell users would vote in favor of branching to version 1.0 or against it. Best, Henning |
|
From: Jeremy O'D. <jer...@gm...> - 2012-04-04 08:13:54
|
On 4 April 2012 08:14, Henning Thielemann <le...@he...>wrote: > > on a second thought ... > > > On Tue, 3 Apr 2012, Jeremy O'Donoghue wrote: > > * The mainline will have the patches needed to update to support >> wxWidgets 2.9.x, based on the work >> >> by Dave Tapley and others, and sourced from the development >> repositories on Darcsden, Readers of >> the wxhaskell-devel list will be familiar with these. >> > ... > >> + The new codeline starts as version 0.15. Users will find that this >> is contained in the >> directories: >> > > If the new version is such a big change, how about calling it version 1.0? > > This would also give us a larger range of versions for the wxWidgets-2.8 > compatibility branch. You know, sometimes even small changes require a > major version bump, such as adding an instance to Selection, etc. > I'm not quite comfortable moving to 1.0 - sounds a bit 'finished' to me. How about a compromise: I'll bump the new version to 0.20. Jeremy |
|
From: Henning T. <le...@he...> - 2012-04-04 07:14:42
|
on a second thought ... On Tue, 3 Apr 2012, Jeremy O'Donoghue wrote: > * The mainline will have the patches needed to update to support wxWidgets 2.9.x, based on the work > by Dave Tapley and others, and sourced from the development repositories on Darcsden, Readers of > the wxhaskell-devel list will be familiar with these. ... > + The new codeline starts as version 0.15. Users will find that this is contained in the > directories: If the new version is such a big change, how about calling it version 1.0? This would also give us a larger range of versions for the wxWidgets-2.8 compatibility branch. You know, sometimes even small changes require a major version bump, such as adding an instance to Selection, etc. |
|
From: Henning T. <le...@he...> - 2012-04-03 21:44:37
|
On Tue, 3 Apr 2012, Jeremy O'Donoghue wrote: > Please shout loudly and soon if you have any problem with what I am planning to do, as I am planning > to make these changes within the next week. The wxWidgets 2.9 support has been waiting in limbo for > too long now (my fault, I accept). Your plans sound great. Please go ahead! Best, Henning |
|
From: Jeremy O'D. <jer...@gm...> - 2012-04-03 21:16:39
|
Hi wxHaskellers, I am about to apply a fairly significant set of changes to the wxHaskell master repository at code.haskell.org. This is in order that I can apply the changes needed to support wxWidgets versions from 2.9 onwards, and the major architectural changes this entails. The changes will be as follows: - The current mainline tip will be branched into a wxhaskell-0.13 codeline, which will receive only minor updates going forward. This codeline will be appropriate for users of wxWidgets 2.8.x. In practice, this means that users who pull the darcs repo will see the following new directories: - wxdirect-0.13: The branch of wxDirect supporting wxWidgets 2.8.x - wxcore-0.13: The branch of wxcore supporting wxWidgets 2.8.x - wx-0.13: The branch of wx supporting wxWidgets 2.8.x - The mainline tip will be tagged WXHASKELL-0-13-BRANCH to show the historical relationship between the two branches. - The mainline will have the patches needed to update to support wxWidgets 2.9.x, based on the work by Dave Tapley and others, and sourced from the development repositories on Darcsden, Readers of the wxhaskell-devel list will be familiar with these. - Because Dave's codebase was branched late last summer, it has not been possible to simply push his patches to the wxHaskell mainline, since darcs never manages to resolve the differences. For this reason, I have developed a smaller, equivalent set of patches on whcih I have tried to maintain as much history as possible. This is regrettable, but I don't see an easy way around the problem. - There are a number of changes, but the most significant is that there is a new module, wxc, which contains the wxWidgets C language wrapper. Wxcore is now a pure Haskell module. In addition, we have removed the vestiges of Eiffel support from wxc. - The new codeline starts as version 0.15. Users will find that this is contained in the directories: - wxdirect: wxDirect version supporting wxWidgets 2.9.x and later. Because Eiffel support is removed, this version cannot be used with wxhaskell 0.13. - wxc: The C language wrapper for wxWidgets. On our supported platforms (Windows, Linux, OS X), this always generates a shared library. As such it is theoretically possible for wxc to be used as the basis for a wxWidgets binding for another language. There are members of the D community playing with this idea. - wxcore: A pure Haskell wrapper over wxc. - wx: This is basically unchanged from wx in revision 0.13. When the new versions are committed, they will be accompanied by uploads to Haskage from both branches, along with build instructions for both versions. Shortly after the formal release of 0.15, I will be producing a cabal wrapper for wx-config on Windows. This will simplify the Windows build significantly, as it currently depends on my privately updated version of wx-config-win on Google code. Please shout loudly and soon if you have any problem with what I am planning to do, as I am planning to make these changes within the next week. The wxWidgets 2.9 support has been waiting in limbo for too long now (my fault, I accept). Best regards Jeremy |
|
From: Paul-Michael S. <P.S...@un...> - 2012-03-13 21:07:06
|
Hi Eric,
I've been trying to install the latest package of wxcore which I believe is 0.13.2.1.
I have taken several steps to try and get it to install here is my current situation.
I'm running Debian's wheezy.
I have wxWidgets-2.9.3. built from source.
Following advise of several tutorials I got several opengl packages, some of which I already had. (I've included a full list of my packages, not sure if will be useful though)
I then tried installing the packages from hackage through cabal.
This failed giving me missing functions or undefined functions in header files, I forget the exact message.
So after reading a blog post, I think it was your own talking about Debian and wxHaskell. I decided to use the repository on darcsden. I've forked and pulled the repository. After running "cabal install" in in the wx folder I get this error
...Building stuff
src/cpp/eljvalidator.cpp:50:34:
warning: ‘static void wxValidator::SetBellOnError(bool)’ is deprecated (declared at /usr/local/include/wx-2.9/wx/validate.h:77) [-Wdeprecated-declarations]
cc1plus: warning: command line option ‘-Wimplicit’ is valid for C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option ‘-Wimplicit’ is valid for C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option ‘-Wimplicit’ is valid for C/ObjC but not for C++ [enabled by default]
src/cpp/ewxw_main.cpp: In function ‘void ELJApp_InitializeC(wxClosure*, int, char**)’:
src/cpp/ewxw_main.cpp:99:32:
warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
src/cpp/ewxw_main.cpp:112:3:
error: ‘wxPendingEvents’ was not declared in this scope
src/cpp/ewxw_main.cpp: In function ‘void ELJApp_initialize(void*, AppInitFunc, int, void*)’:
src/cpp/ewxw_main.cpp:123:3:
error: ‘wxPendingEvents’ was not declared in this scope
cabal: Error: some packages failed to install:
wx-0.13.2.1 depends on wxcore-0.13.2.1 which failed to install.
wxcore-0.13.2.1 failed during the building phase. The exception was:
ExitFailure 1
I hope I've provided enough information to help you get a sense of the problem.
Thanks for your time,
Michael Sorhaindo. |
|
From: Eric K. <eri...@gm...> - 2012-02-12 19:17:07
|
Hi Jeremy, On 12 Feb 2012, at 19:03, Jeremy O'Donoghue wrote: > > Becuse Darcsden uses the darcs 2.0 repo format (not the hashed format), I cannot push patches from my local copy of Dave's Darcsden to my local c.h.o (which is using the hashed repo format). That's interesting. Are you sure it actually converts it? darcs show repo shows that http://darcsden.com/jodonoghue/wxhaskell-wx29-jod is a hashed repo. Do I have the right URI? > > Recreating the patches and their comments by hand would be inexpressibly tedious, so I wanted to know if there is any reason not to upgrade the c.h.o repo to the 2.0 format. If I understand things correctly, this has been the Darcs default since 2008, and it would let us > > Any suggestions, advice or warnings before I start along this path? See http://wiki.darcs.net/FAQ#upgrading-to-darcs-2 I tend to advise people to stick to darcs 1 (hashed) if they have a pre-existing repo. New repos, sure. But old repos, maybe best for now to just stick with what you know -- Eric Kow <http://erickow.com> |
|
From: Jeremy O'D. <jer...@gm...> - 2012-02-12 19:03:22
|
Hi Eric, I was going to start merging the current state of wxHaskell support for wxWidget 2.9 back into the mainline at c.h.o... then I discovered a problem. Becuse Darcsden uses the darcs 2.0 repo format (not the hashed format), I cannot push patches from my local copy of Dave's Darcsden to my local c.h.o (which is using the hashed repo format). Recreating the patches and their comments by hand would be inexpressibly tedious, so I wanted to know if there is any reason not to upgrade the c.h.o repo to the 2.0 format. If I understand things correctly, this has been the Darcs default since 2008, and it would let us Any suggestions, advice or warnings before I start along this path? Thanks Jeremy |
|
From: shelarcy <she...@gm...> - 2012-02-07 07:46:11
|
Pushed. And I uploaded newer version, now. On Sat, 04 Feb 2012 13:01:21 +0900, shelarcy <she...@gm...> wrote: > Hi, > > GHC 7.4.1 can't build wxHaskell. This problem is caused by Num class change > and TypeSynonymInstances extension's change. > > http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html#id3013571 > http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-2-1.html#id3003826 > http://sourceforge.net/mailarchive/forum.php?thread_name=CAH55dvPCswVggNV0gGQS2CQftUHHKxouqTnxyE4WQ_qc-b0Ofg%40mail.gmail.com&forum_name=wxhaskell-devel > > I made patch to fix this problem. > > Attached patch also include two more changes. I relaxed time and array package's > dependency to use GHC 7.4.1 bundled version instead of installing from HackageDB. > And I commented out wxcore/Setup.hs' unused ver variable to fix builing with my > environment. > > http://sourceforge.net/mailarchive/message.php?msg_id=28649050 > > Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
|
From: shelarcy <she...@gm...> - 2012-02-04 04:01:40
|
Hi, GHC 7.4.1 can't build wxHaskell. This problem is caused by Num class change and TypeSynonymInstances extension's change. http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html#id3013571 http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-2-1.html#id3003826 http://sourceforge.net/mailarchive/forum.php?thread_name=CAH55dvPCswVggNV0gGQS2CQftUHHKxouqTnxyE4WQ_qc-b0Ofg%40mail.gmail.com&forum_name=wxhaskell-devel I made patch to fix this problem. Attached patch also include two more changes. I relaxed time and array package's dependency to use GHC 7.4.1 bundled version instead of installing from HackageDB. And I commented out wxcore/Setup.hs' unused ver variable to fix builing with my environment. http://sourceforge.net/mailarchive/message.php?msg_id=28649050 Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
|
From: Paulo P. <po...@gm...> - 2012-02-01 20:19:01
|
Hello Jeremy. I was replying to the list but only your address got in at first. So, I was updating wxHaskell targeting the stable wxWidgets 2.8.12 branch. After knowing wx-config had to be updated, I opted to build wxHaskell targeting 2.9 instead. I managed to get some progress. Compiled wx-config-win and set environment variables in windows. They were already set for wxWidgets 2.8.12. Pointed 'WXWIN' to wxWidgets-svn directory and 'WXCFG' to gcc_dll/mswu. Right now I am stuck with compiling wxc with cabal install. Cabal configure warned about missing debug libraries. After building them I have this one left that I don't know how to build. E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cabal configure Resolving dependencies... Configuring wxc-0.1... Configuring wxc to build against wx 2.9 setup.exe: Missing dependency on a foreign library: * Missing C library: wxmsw29ud_all This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. On 1 February 2012 17:08, Jeremy O'Donoghue <jer...@gm...> wrote: > Hi Paulo > > [Replying to all] > First, apologies that it has taken so long for you to fail to get going. I > am going to try to cover both wxWidgets 2.8.12 and 2.9.x approaches in the > same mail. Please feel free to choose whichever you prefer. I assume that > you are working on Windows, based on the output you have pasted. > On 1 February 2012 16:03, Paulo Pocinho <po...@gm...> wrote: >> >> Trying to follow up with the latest stable version of wxHaskell 0.13.2 >> (based on wxWidgets 2.8.12). I run straight into trouble using the >> wx-config tool, preventing me to update the package - it does not >> work. > > > On Windows there is no wx-config supplied with wxWidgets. There is a > workaround, which is to use wx-config-win (found at > http://code.google.com/p/wx-config-win/). This is a C++ implementation of > wx-config for Windows targets. The version on Google Code is OK for use with > wxHaskell 0.13.2, but does not work for the latest code. > > You need to make sure that the WXWIN environment variable is pointing to > your wxWidgets install and that WXCFG points to the directory containing > your build.cfg. In my case (i.e. what I have tested) this is gcc_dll\mswu. > > If you have the above configuration with wx-config.exe from the Google code > site, cabal install wx should work. > >> >> Then I found out about the latest development. Pulled the sources from >> http://darcsden.com/kowey/wxhaskell - packed and installed that >> wx-config with cabal and still no luck. > > > This one won't work - it has only been tested for wxWidgets 2.9.x - and we > probably won't use it moving forward, as it needs quite a bit of work to > make it function completely correctly. > >> >> As last resort, I checked out from Dave Tapley. Patched it with >> Jeremy's diff and tried to build that version against wxWidgets 2.9 >> (compiled from svn sources). Now, I am lost in a circular dependency: > > > >> >> E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cabal >> configure >> Resolving dependencies... >> Configuring wxcore-0.14... >> setup.exe: At least the following dependencies are missing: >> wxc -any >> >> E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cd ..\wxc >> >> E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cabal configure >> Resolving dependencies... >> Configuring wxc-0.1... >> setup.exe: This version of wxcore requires wx 2.9 to be available > > > This is the root of your problem. > > A couple of possibilities: > > You may have WXWIN and WXCFG environment variables pointing to your > wxWidgets 2.8.x install (or not pointing anywhere at all) > You need the updated version of wx-config-win I put together to get all of > the correct configuration data for a wxWidgets 2.9 configuration.If you > don't have it, it was attached to the following message: > http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/807 . You > will need to compile(*) the CPP file. If you don't have a C++ compiler, I > can also send you an executable - assuming that none of the mail tools block > it, that is. > > > > (*) Nothing very difficult. I think gcc -o wx-config.exe wx-config-win.cpp > should do it. > >> >> >> E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cd ..\wx >> >> E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wx>cabal configure >> Resolving dependencies... >> Configuring wx-0.14... >> cabal: At least the following dependencies are missing: >> wxcore >=0.14 >> >> It's been a great adventure though. Thanks for everyone working on this! >> >> >> On 31 January 2012 16:32, Jeremy O'Donoghue <jer...@gm...> >> wrote: >> > Hi all, >> > >> > Attached are patches which enable me to build and Dave's repo on >> > Windows. I >> > have built and run most of the samples and test cases (including OpenGL, >> > STC >> > and PropertyGrid) >> > I also included Nicholas Tung's patch from a couple of days back to >> > support >> > GHC 7.2.2 by adding some FlexibleInstances pragmas. >> > >> > The remaining issue on Windows is that GHCi is not working as it should. >> > I >> > will look at this next. >> > On 25 January 2012 15:33, Dave Tapley <duk...@gm...> wrote: >> >> >> >> On 22 January 2012 00:37, Jeremy O'Donoghue >> >> <jer...@gm...> >> >> wrote: >> >>> >> >>> I now have wxC building on Windows. Details below and patches >> >>> attached. >> >> >> >> >> >> Excellent! >> >> I'll take a look. >> >> >> >>> >> >>> I am now failing to build wxcore. This is faling to find the wxc >> >>> header >> >>> files on Windows (it is looking for them in ./include/wxc). I notice >> >>> that >> >>> Dave has already marked the wxcInstallDir function as dubious, so I'll >> >>> start >> >>> looking there when it isn't past midnight (a bad time to start >> >>> anything, >> >>> IME). >> >> >> >> >> >> Mmm, I'm sorry about that. >> >> I actually went for this solution because I'm using cabal-dev to work >> >> on >> >> wxHaskell (so I can keep the hackage wxHaskell in my system cabal pkg >> >> conf): >> >> I needed a way to find the wxC headers (which obviously should be part >> >> of >> >> the wxC package) during the wxcore configure (because wxdirect (called >> >> by >> >> wxcore) needs them to generate some Haskell source (the FFI bindings)). >> > >> > >> > The solution turned out to be simpler than I expected: the working code >> > for >> > Linux was using System.Directory.Posix, when System.Directory will get >> > you >> > the same thing, but internally select between System.Directory.Posix and >> > System.Directory.Windows. No prizes for guessing which you need on >> > Windows >> > :-) >> > >> >> >> >> >> >> Whilst I did mark wxcInstallDir as dubious, I do quite like the idea of >> >> having cabal work out which version of wxC it is using to satisfy >> >> wxcore's >> >> dependency, and then linking against exactly that version's header >> >> files. >> >> The only alternatives I can think of are: >> >> >> >> 1. Enforce that wxC is installed as a system or user shared library and >> >> find/version it up as we would any other external library (this would >> >> be >> >> required if we stopped using cabal). >> >> >> >> 2. Provide some other (auto-guesswork-or-specify-on-command-line) >> >> mechanism to tell wxcore: "can you configure yourself with the wxC >> >> headers >> >> here, and link against this shared library". >> > >> > >> > Actually, after some reflection, I don't think wxcInstallDir is dubious >> > at >> > all. It is, I think, using a documented Cabal API, and it works on all >> > Cabal >> > platforms. >> > >> > One area where we do have an issue is that wxc.dll gets installed >> > somewhere >> > no sane human being would evenr look to find it. I think the solution >> > will >> > be to do a skeleton wxHaskell project Cabal file which pulls all of the >> > dlls >> > from their install directory and copies them to dist/build, or something >> > similar. >> > >> > Regards >> > Jeremy >> > >> > >> > ------------------------------------------------------------------------------ >> > Keep Your Developer Skills Current with LearnDevNow! >> > The most comprehensive online learning library for Microsoft developers >> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> > Metro Style Apps, more. Free future releases when you subscribe now! >> > http://p.sf.net/sfu/learndevnow-d2d >> > _______________________________________________ >> > wxhaskell-devel mailing list >> > wxh...@li... >> > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel >> > >> >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> wxhaskell-devel mailing list >> wxh...@li... >> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
|
From: Jeremy O'D. <jer...@gm...> - 2012-02-01 17:08:11
|
Hi Paulo [Replying to all] First, apologies that it has taken so long for you to fail to get going. I am going to try to cover both wxWidgets 2.8.12 and 2.9.x approaches in the same mail. Please feel free to choose whichever you prefer. I assume that you are working on Windows, based on the output you have pasted. On 1 February 2012 16:03, Paulo Pocinho <po...@gm...> wrote: > Trying to follow up with the latest stable version of wxHaskell 0.13.2 > (based on wxWidgets 2.8.12). I run straight into trouble using the > wx-config tool, preventing me to update the package - it does not > work. > On Windows there is no wx-config supplied with wxWidgets. There is a workaround, which is to use wx-config-win (found at http://code.google.com/p/wx-config-win/). This is a C++ implementation of wx-config for Windows targets. The version on Google Code is OK for use with wxHaskell 0.13.2, but does not work for the latest code. You need to make sure that the WXWIN environment variable is pointing to your wxWidgets install and that WXCFG points to the directory containing your build.cfg. In my case (i.e. what I have tested) this is gcc_dll\mswu. If you have the above configuration with wx-config.exe from the Google code site, cabal install wx should work. > Then I found out about the latest development. Pulled the sources from > http://darcsden.com/kowey/wxhaskell - packed and installed that > wx-config with cabal and still no luck. > This one won't work - it has only been tested for wxWidgets 2.9.x - and we probably won't use it moving forward, as it needs quite a bit of work to make it function completely correctly. > As last resort, I checked out from Dave Tapley. Patched it with > Jeremy's diff and tried to build that version against wxWidgets 2.9 > (compiled from svn sources). Now, I am lost in a circular dependency: > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cabal > configure > Resolving dependencies... > Configuring wxcore-0.14... > setup.exe: At least the following dependencies are missing: > wxc -any > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cd ..\wxc > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cabal configure > Resolving dependencies... > Configuring wxc-0.1... > setup.exe: This version of wxcore requires wx 2.9 to be available > This is the root of your problem. A couple of possibilities: 1. You may have WXWIN and WXCFG environment variables pointing to your wxWidgets 2.8.x install (or not pointing anywhere at all) 2. You need the updated version of wx-config-win I put together to get all of the correct configuration data for a wxWidgets 2.9 configuration.If you don't have it, it was attached to the following message: http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/807 . You will need to compile(*) the CPP file. If you don't have a C++ compiler, I can also send you an executable - assuming that none of the mail tools block it, that is. (*) Nothing very difficult. I think gcc -o wx-config.exe wx-config-win.cpp should do it. > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cd ..\wx > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wx>cabal configure > Resolving dependencies... > Configuring wx-0.14... > cabal: At least the following dependencies are missing: > wxcore >=0.14 > > It's been a great adventure though. Thanks for everyone working on this! > > > On 31 January 2012 16:32, Jeremy O'Donoghue <jer...@gm...> > wrote: > > Hi all, > > > > Attached are patches which enable me to build and Dave's repo on > Windows. I > > have built and run most of the samples and test cases (including OpenGL, > STC > > and PropertyGrid) > > I also included Nicholas Tung's patch from a couple of days back to > support > > GHC 7.2.2 by adding some FlexibleInstances pragmas. > > > > The remaining issue on Windows is that GHCi is not working as it should. > I > > will look at this next. > > On 25 January 2012 15:33, Dave Tapley <duk...@gm...> wrote: > >> > >> On 22 January 2012 00:37, Jeremy O'Donoghue <jer...@gm... > > > >> wrote: > >>> > >>> I now have wxC building on Windows. Details below and patches attached. > >> > >> > >> Excellent! > >> I'll take a look. > >> > >>> > >>> I am now failing to build wxcore. This is faling to find the wxc header > >>> files on Windows (it is looking for them in ./include/wxc). I notice > that > >>> Dave has already marked the wxcInstallDir function as dubious, so I'll > start > >>> looking there when it isn't past midnight (a bad time to start > anything, > >>> IME). > >> > >> > >> Mmm, I'm sorry about that. > >> I actually went for this solution because I'm using cabal-dev to work on > >> wxHaskell (so I can keep the hackage wxHaskell in my system cabal pkg > conf): > >> I needed a way to find the wxC headers (which obviously should be part > of > >> the wxC package) during the wxcore configure (because wxdirect (called > by > >> wxcore) needs them to generate some Haskell source (the FFI bindings)). > > > > > > The solution turned out to be simpler than I expected: the working code > for > > Linux was using System.Directory.Posix, when System.Directory will get > you > > the same thing, but internally select between System.Directory.Posix and > > System.Directory.Windows. No prizes for guessing which you need on > Windows > > :-) > > > >> > >> > >> Whilst I did mark wxcInstallDir as dubious, I do quite like the idea of > >> having cabal work out which version of wxC it is using to satisfy > wxcore's > >> dependency, and then linking against exactly that version's header > files. > >> The only alternatives I can think of are: > >> > >> 1. Enforce that wxC is installed as a system or user shared library and > >> find/version it up as we would any other external library (this would be > >> required if we stopped using cabal). > >> > >> 2. Provide some other (auto-guesswork-or-specify-on-command-line) > >> mechanism to tell wxcore: "can you configure yourself with the wxC > headers > >> here, and link against this shared library". > > > > > > Actually, after some reflection, I don't think wxcInstallDir is dubious > at > > all. It is, I think, using a documented Cabal API, and it works on all > Cabal > > platforms. > > > > One area where we do have an issue is that wxc.dll gets installed > somewhere > > no sane human being would evenr look to find it. I think the solution > will > > be to do a skeleton wxHaskell project Cabal file which pulls all of the > dlls > > from their install directory and copies them to dist/build, or something > > similar. > > > > Regards > > Jeremy > > > > > ------------------------------------------------------------------------------ > > Keep Your Developer Skills Current with LearnDevNow! > > The most comprehensive online learning library for Microsoft developers > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > > Metro Style Apps, more. Free future releases when you subscribe now! > > http://p.sf.net/sfu/learndevnow-d2d > > _______________________________________________ > > wxhaskell-devel mailing list > > wxh...@li... > > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > |
|
From: Paulo P. <po...@gm...> - 2012-02-01 17:03:54
|
Good news. My mistake using wx-core version in darcs. It was giving cabal a hard time to configure wxc. After compiling the latest source from [1] wx-config worked and it's looking good. Cheers [1] http://code.google.com/p/wx-config-win/ > Trying to follow up with the latest stable version of wxHaskell 0.13.2 > (based on wxWidgets 2.8.12). I run straight into trouble using the > wx-config tool, preventing me to update the package - it does not > work. > Then I found out about the latest development. Pulled the sources from > http://darcsden.com/kowey/wxhaskell - packed and installed that > wx-config with cabal and still no luck. > > As last resort, I checked out from Dave Tapley. Patched it with > Jeremy's diff and tried to build that version against wxWidgets 2.9 > (compiled from svn sources). Now, I am lost in a circular dependency: > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cabal configure > Resolving dependencies... > Configuring wxcore-0.14... > setup.exe: At least the following dependencies are missing: > wxc -any > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cd ..\wxc > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cabal configure > Resolving dependencies... > Configuring wxc-0.1... > setup.exe: This version of wxcore requires wx 2.9 to be available > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cd ..\wx > > E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wx>cabal configure > Resolving dependencies... > Configuring wx-0.14... > cabal: At least the following dependencies are missing: > wxcore >=0.14 > > It's been a great adventure though. Thanks for everyone working on this! |
|
From: Paulo P. <po...@gm...> - 2012-02-01 16:03:37
|
---------- Forwarded message ---------- From: Paulo Pocinho <po...@gm...> Date: 1 February 2012 16:02 Subject: Re: [wxhaskell-devel] The 'making wxC build on all platforms thread To: Jeremy O'Donoghue <jer...@gm...> Trying to follow up with the latest stable version of wxHaskell 0.13.2 (based on wxWidgets 2.8.12). I run straight into trouble using the wx-config tool, preventing me to update the package - it does not work. Then I found out about the latest development. Pulled the sources from http://darcsden.com/kowey/wxhaskell - packed and installed that wx-config with cabal and still no luck. As last resort, I checked out from Dave Tapley. Patched it with Jeremy's diff and tried to build that version against wxWidgets 2.9 (compiled from svn sources). Now, I am lost in a circular dependency: E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cabal configure Resolving dependencies... Configuring wxcore-0.14... setup.exe: At least the following dependencies are missing: wxc -any E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcore>cd ..\wxc E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cabal configure Resolving dependencies... Configuring wxc-0.1... setup.exe: This version of wxcore requires wx 2.9 to be available E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cd ..\wx E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wx>cabal configure Resolving dependencies... Configuring wx-0.14... cabal: At least the following dependencies are missing: wxcore >=0.14 It's been a great adventure though. Thanks for everyone working on this! On 31 January 2012 16:32, Jeremy O'Donoghue <jer...@gm...> wrote: > Hi all, > > Attached are patches which enable me to build and Dave's repo on Windows. I > have built and run most of the samples and test cases (including OpenGL, STC > and PropertyGrid) > I also included Nicholas Tung's patch from a couple of days back to support > GHC 7.2.2 by adding some FlexibleInstances pragmas. > > The remaining issue on Windows is that GHCi is not working as it should. I > will look at this next. > On 25 January 2012 15:33, Dave Tapley <duk...@gm...> wrote: >> >> On 22 January 2012 00:37, Jeremy O'Donoghue <jer...@gm...> >> wrote: >>> >>> I now have wxC building on Windows. Details below and patches attached. >> >> >> Excellent! >> I'll take a look. >> >>> >>> I am now failing to build wxcore. This is faling to find the wxc header >>> files on Windows (it is looking for them in ./include/wxc). I notice that >>> Dave has already marked the wxcInstallDir function as dubious, so I'll start >>> looking there when it isn't past midnight (a bad time to start anything, >>> IME). >> >> >> Mmm, I'm sorry about that. >> I actually went for this solution because I'm using cabal-dev to work on >> wxHaskell (so I can keep the hackage wxHaskell in my system cabal pkg conf): >> I needed a way to find the wxC headers (which obviously should be part of >> the wxC package) during the wxcore configure (because wxdirect (called by >> wxcore) needs them to generate some Haskell source (the FFI bindings)). > > > The solution turned out to be simpler than I expected: the working code for > Linux was using System.Directory.Posix, when System.Directory will get you > the same thing, but internally select between System.Directory.Posix and > System.Directory.Windows. No prizes for guessing which you need on Windows > :-) > >> >> >> Whilst I did mark wxcInstallDir as dubious, I do quite like the idea of >> having cabal work out which version of wxC it is using to satisfy wxcore's >> dependency, and then linking against exactly that version's header files. >> The only alternatives I can think of are: >> >> 1. Enforce that wxC is installed as a system or user shared library and >> find/version it up as we would any other external library (this would be >> required if we stopped using cabal). >> >> 2. Provide some other (auto-guesswork-or-specify-on-command-line) >> mechanism to tell wxcore: "can you configure yourself with the wxC headers >> here, and link against this shared library". > > > Actually, after some reflection, I don't think wxcInstallDir is dubious at > all. It is, I think, using a documented Cabal API, and it works on all Cabal > platforms. > > One area where we do have an issue is that wxc.dll gets installed somewhere > no sane human being would evenr look to find it. I think the solution will > be to do a skeleton wxHaskell project Cabal file which pulls all of the dlls > from their install directory and copies them to dist/build, or something > similar. > > Regards > Jeremy > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > |
|
From: Nicholas T. <nt...@nt...> - 2012-01-29 07:11:51
|
Dear all,
GHC 7.2.2 requires explicit FlexibleInstances language pragmas at the
top of each file. Attached is a trivial patch to make it work.
cheers,
Nciholas
|
|
From: Frodo K. <fro...@gm...> - 2012-01-25 20:31:54
|
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??? |
15 messages has been excluded from this view by a project administrator.
