#42073 closed defect (fixed)
p5-wx does not build with wxWidgets > 2.9.4
| Reported by: | mf2k (Frank Schima) | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | mojca (Mojca Miklavec), cooljeanius (Eric Gallager) | |
| Port: | p5-wx |
Description (last modified by mojca (Mojca Miklavec))
I know I'm the maintainer, but I am completely stuck. It would be great to get the p5-wx port built. I'm Cc'ing mojca because of her excellent work getting the wx ports updated and fixed.
:info:build /usr/bin/clang++ -UWX_PRECOMP -c -I. -I../.. -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/include/osx_cocoa-unicode-3.0 -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0 -pipe -Os -fno-common -DPERL_DARWIN -I/opt/local/include -fno-strict-aliasing -fstack-protector -I/opt/local/include -arch x86_64 -O3 -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" "-I/opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE" -DWXPL_EXT -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__ XRC.c :info:build clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated :info:build In file included from XRC.c:24: :info:build ./cpp/xr_constants.cpp:37:12: error: use of undeclared identifier 'wxXML_ELEMENT_NODE' :info:build r( wxXML_ELEMENT_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:38:12: error: use of undeclared identifier 'wxXML_ATTRIBUTE_NODE' :info:build r( wxXML_ATTRIBUTE_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:39:12: error: use of undeclared identifier 'wxXML_TEXT_NODE' :info:build r( wxXML_TEXT_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:40:12: error: use of undeclared identifier 'wxXML_CDATA_SECTION_NODE' :info:build r( wxXML_CDATA_SECTION_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:41:12: error: use of undeclared identifier 'wxXML_ENTITY_REF_NODE' :info:build r( wxXML_ENTITY_REF_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:42:12: error: use of undeclared identifier 'wxXML_ENTITY_NODE' :info:build r( wxXML_ENTITY_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:43:12: error: use of undeclared identifier 'wxXML_PI_NODE' :info:build r( wxXML_PI_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:44:12: error: use of undeclared identifier 'wxXML_COMMENT_NODE' :info:build r( wxXML_COMMENT_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:45:12: error: use of undeclared identifier 'wxXML_DOCUMENT_NODE' :info:build r( wxXML_DOCUMENT_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:46:12: error: use of undeclared identifier 'wxXML_DOCUMENT_TYPE_NODE' :info:build r( wxXML_DOCUMENT_TYPE_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:47:12: error: use of undeclared identifier 'wxXML_DOCUMENT_FRAG_NODE' :info:build r( wxXML_DOCUMENT_FRAG_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:48:12: error: use of undeclared identifier 'wxXML_NOTATION_NODE' :info:build r( wxXML_NOTATION_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build ./cpp/xr_constants.cpp:49:12: error: use of undeclared identifier 'wxXML_HTML_DOCUMENT_NODE' :info:build r( wxXML_HTML_DOCUMENT_NODE ); :info:build ^ :info:build ./cpp/xr_constants.cpp:24:16: note: expanded from macro 'r' :info:build return n; :info:build ^ :info:build XRC.c:973:20: error: member access into incomplete type 'wxXmlDocument' :info:build RETVAL = THIS->IsOk(); :info:build ^ :info:build /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/xrc/xmlres.h:44:27: note: forward declaration of 'wxXmlDocument' :info:build class WXDLLIMPEXP_FWD_XML wxXmlDocument; :info:build ^ :info:build XRC.c:999:20: error: member access into incomplete type 'wxXmlDocument' :info:build RETVAL = THIS->GetRoot(); :info:build ^ :info:build /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/xrc/xmlres.h:44:27: note: forward declaration of 'wxXmlDocument' :info:build class WXDLLIMPEXP_FWD_XML wxXmlDocument; :info:build ^ :info:build XRC.c:1025:20: error: member access into incomplete type 'wxXmlDocument' :info:build RETVAL = THIS->GetVersion(); :info:build ^ :info:build /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/xrc/xmlres.h:44:27: note: forward declaration of 'wxXmlDocument' :info:build class WXDLLIMPEXP_FWD_XML wxXmlDocument; :info:build ^ :info:build XRC.c:1051:20: error: member access into incomplete type 'wxXmlDocument' :info:build RETVAL = THIS->GetFileEncoding(); :info:build ^ :info:build /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/xrc/xmlres.h:44:27: note: forward declaration of 'wxXmlDocument' :info:build class WXDLLIMPEXP_FWD_XML wxXmlDocument; :info:build ^ :info:build XRC.c:1078:11: error: member access into incomplete type 'wxXmlDocument' :info:build THIS->SetRoot( node ); :info:build ^ :info:build /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/xrc/xmlres.h:44:27: note: forward declaration of 'wxXmlDocument' :info:build class WXDLLIMPEXP_FWD_XML wxXmlDocument; :info:build ^ :info:build XRC.c:1105:11: error: member access into incomplete type 'wxXmlDocument' :info:build THIS->SetVersion( version ); :info:build ^ :info:build /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/xrc/xmlres.h:44:27: note: forward declaration of 'wxXmlDocument' :info:build class WXDLLIMPEXP_FWD_XML wxXmlDocument; :info:build ^ :info:build fatal error: too many errors emitted, stopping now [-ferror-limit=] :info:build 20 errors generated.
Attachments (6)
Change History (33)
Changed 10 years ago by mf2k (Frank Schima)
comment:1 Changed 10 years ago by mojca (Mojca Miklavec)
| Description: | modified (diff) |
|---|---|
| Version: | 2.2.1 |
comment:2 Changed 10 years ago by mojca (Mojca Miklavec)
comment:3 Changed 10 years ago by mf2k (Frank Schima)
Thanks for the comments. Sorry for the gender error! It's dependency p5-alien-wxwidgets depends on wxwidgets-3.0 so I left out the direct dependency. I believe the p5-wx source code has not been modified to work with wxwidgets 3.0 yet. Maybe we could switch to depending on wxWidgets 2.8? but I thought that version had the 32-bit limitation? So I didn't want to do that.
comment:4 follow-up: 5 Changed 10 years ago by mojca (Mojca Miklavec)
There are a few things that I don't understand:
- What exactly is the difference and connection between
p5-alien-wxwidgetsandp5-wx? - Which one works with wxWidgets 2.9 and which one doesn't? (Which combinations did you test when you created the port?)
- How is it possible that the server contains a binary package for
p5.16-wxif the package fails to build now? Did the build happen to work with wxWidgets 2.9.5 and now only fails with 3.0.0? - Where do all the compiled files end up? The only binary file I notice seems to be the following (but I may be missing some files) and it doesn't link to wxWidgets:
> otool -L /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl: /opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib (compatibility version 5.16.0, current version 5.16.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
Just for explanation: when B depends on A and C depends on B, direct dependency between C and A is "polite to have" in cases when upgrading A requires a revbump of C or something similar to that. The main question is: does this package need a revbump when wxWidgets is upgraded or not? Seeing that it uses wxWidgets sources I would guess so, but I'm unable to figure out the details and how this works. Most dependencies of py-wxpython-x.y don't need a revbump when wxWidgets gets upgraded because they are pure python scripts. Some dependencies however compile C(++) code and the resulting binary or library is linked against wxWidgets libraries (not that this is properly indicated, but well ...)
Usually a package would link against /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_baseu-2.9.dylib and then the link would be broken when wxWidgets gets upgraded. I don't know if this is also the case here. I'm unable to figure out why C code gets compiled and where it ends up.
As far as compatibility with wxWidgets 3.0 is concerned: how is it possible that nobody noticed the incompatibility since April? It is true that I probably didn't test the GUI when compiling the ports in August 2013 (I had enough problems convincing p5-alien-wxwidgets to compile at all), but I would expect the port to fail already when you first created it if there is some major incompatibility.
In case of a minor incompatibility you would probably be better off if you try to fix the remaining glitches and/or request from the upstream to fix those.
If you are thinking about switching to version 2.8 (which is something that I would really like to discourage you from doing), you'll have to deal with the following facts:
- You either need to offer an option to switch between 2.8 and 3.0 (in case that any ports do work with 3.0) or provide just support for 2.8.
- If you offer support for both, you'll end up with a bit of a mess: you will need two separate ports which will most probably conflict with each other (in Python one can only use, say Python 2.6 + wxWidgets 2.8 and Python 2.7 + wxWidgets 3.0; one cannot use Python 2.7 with both at the same time).
- Version 2.8 works for 64-bit, but only via the ugly
gtk(x11). - (I would like to declare wxWidgets 2.8 obsolete one day and remove it. I'm not sure if this is feasible, but if p5-wx won't stand in the way, that will be a bonus.)
comment:5 Changed 10 years ago by mf2k (Frank Schima)
I'll try to answer the best I can. I am very ignorant of both perl and wx.
Replying to mojca@…:
There are a few things that I don't understand:
- What exactly is the difference and connection between
p5-alien-wxwidgetsandp5-wx?
I believe p5-alien-wxwidgets alters wxWidgets in some way so as to make it compatible with perl-wx. Beyond that, I don't know how or why.
- Which one works with wxWidgets 2.9 and which one doesn't? (Which combinations did you test when you created the port?)
Honestly, I don't remember. These ports may never have worked. I need p5-wx, however, because it is a dependency for Demeter, which I'm trying to port to MacPorts.
- How is it possible that the server contains a binary package for
p5.16-wxif the package fails to build now? Did the build happen to work with wxWidgets 2.9.5 and now only fails with 3.0.0?
It did use to build in the past and so you are right, it probably built with 2.9.5 and it keeps the binary because the version has not been updated.
- Where do all the compiled files end up? The only binary file I notice seems to be the following (but I may be missing some files) and it doesn't link to wxWidgets:
> otool -L /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl: /opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib (compatibility version 5.16.0, current version 5.16.1) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
I don't remember and I cannot build it anymore now.
Just for explanation: when B depends on A and C depends on B, direct dependency between C and A is "polite to have" in cases when upgrading A requires a revbump of C or something similar to that. The main question is: does this package need a revbump when wxWidgets is upgraded or not? Seeing that it uses wxWidgets sources I would guess so, but I'm unable to figure out the details and how this works. Most dependencies of
py-wxpython-x.ydon't need a revbump whenwxWidgetsgets upgraded because they are pure python scripts. Some dependencies however compile C(++) code and the resulting binary or library is linked againstwxWidgetslibraries (not that this is properly indicated, but well ...)
I don't really know anything about p5-wx. But I think that is safe to assume. So we should probably depend on wxWidgets-3.0 directly.
As far as compatibility with wxWidgets 3.0 is concerned: how is it possible that nobody noticed the incompatibility since April? It is true that I probably didn't test the GUI when compiling the ports in August 2013 (I had enough problems convincing
p5-alien-wxwidgetsto compile at all), but I would expect the port to fail already when you first created it if there is some major incompatibility.
I don't know. I have asked on the mailing list for perl-wx twice and gotten no response.
In case of a minor incompatibility you would probably be better off if you try to fix the remaining glitches and/or request from the upstream to fix those.
If you are thinking about switching to version 2.8 (which is something that I would really like to discourage you from doing), you'll have to deal with the following facts:
- You either need to offer an option to switch between 2.8 and 3.0 (in case that any ports do work with 3.0) or provide just support for 2.8.
- If you offer support for both, you'll end up with a bit of a mess: you will need two separate ports which will most probably conflict with each other (in Python one can only use, say Python 2.6 + wxWidgets 2.8 and Python 2.7 + wxWidgets 3.0; one cannot use Python 2.7 with both at the same time).
- Version 2.8 works for 64-bit, but only via the ugly
gtk(x11).- (I would like to declare wxWidgets 2.8 obsolete one day and remove it. I'm not sure if this is feasible, but if p5-wx won't stand in the way, that will be a bonus.)
I don't want to - or have any plans to - use wxWidgets 2.8. I want to move forward with 3.0. I filed this ticket because I am stuck and don't know how to proceed.
comment:6 Changed 10 years ago by mojca (Mojca Miklavec)
If binary package built successfully against 2.9.5 and the buildbot doesn't have one for your OS, you could try to install 2.9.5, build p5-wx, upgrade wxWidgets and then continue ;)
Apart from that I would suggest you to add that trivial include and then try to figure out what to do with PaintBackground.
comment:7 Changed 10 years ago by mojca (Mojca Miklavec)
OK, got it:
> otool -L /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/auto/Wx/Ribbon/Ribbon.bundle /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-2level/auto/Wx/Ribbon/Ribbon.bundle: /opt/local/lib/libwx_osx_cocoau_ribbon-2.9.4.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libwx_osx_cocoau_adv-2.9.4.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libwx_osx_cocoau_core-2.9.4.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libwx_baseu-2.9.4.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
comment:8 Changed 10 years ago by mojca (Mojca Miklavec)
Weird. The buildbot log says that the building failed: https://build.macports.org/builders/buildports-lion-x86_64/builds/10646, but the package is present. But apparently building succeeded with 2.9.4 and now fails with 3.0.0, so there cannot be that many differences other than a few "bugfixes".
Changed 10 years ago by mojca (Mojca Miklavec)
| Attachment: | patch-ext-grid-cpp-editor.h.diff added |
|---|
Changed 10 years ago by mojca (Mojca Miklavec)
| Attachment: | patch-ext-grid-XS-GridCellEditor.xs.diff added |
|---|
Changed 10 years ago by mojca (Mojca Miklavec)
| Attachment: | patch-ext-stc-cpp-st_constants.cpp.diff added |
|---|
Changed 10 years ago by mojca (Mojca Miklavec)
| Attachment: | patch-ext-xrc-cpp-xr_constants.cpp.diff added |
|---|
Changed 10 years ago by mojca (Mojca Miklavec)
| Attachment: | p5-wx.Portfile.diff added |
|---|
comment:9 Changed 10 years ago by mojca (Mojca Miklavec)
I attached some possible provisional patches to keep compiling the port, but this won't get you anywhere near the end. In particular the webview code is problematic. It has been changed between 2.9.4 and 2.9.5, see http://trac.wxwidgets.org/changeset/73369 for example, and the code in p5-wx is not compatible with 2.9.5 or later. This might not be that difficult to change, but it would be great if it would be done by the author. Guessing what to change is an excellent recipe to end up with completely unstable and useless binary anyway.
comment:10 Changed 10 years ago by mojca (Mojca Miklavec)
| Summary: | p5-wx does not build → p5-wx does not build with wxWidgets > 2.9.4 |
|---|
comment:11 Changed 10 years ago by mojca (Mojca Miklavec)
I mean ... in the worst case we can also try to raise up wxWidgets 2.9.4 from the dead which is still light years better than trying to use version 2.8.12. We already have a separate copy for wxPython. We could also have one for wxPerl as a temporary measure to try to make your beloved ports work.
The biggest problem is that I have an impression that there is nobody to ask to update the sources, even though I'm not sure how exactly the things are running.
I actually have an impression that alien-wxwidgets doesn't do anything else but provide a tiny tiny wrapper around wxWidgets, most commonly used to fetch wxWidgets automatically and to provide configuration flags to any other dependencies. That could probably also be part of p5-wx. On the other hand p5-wx provides proper bindings between C/C++ and Perl, in the same way as wxPython does (but wxPython also packages the complete wxWidgets).
comment:12 Changed 10 years ago by mojca (Mojca Miklavec)
Please let me know if you need a separate (sub)port called wxPerl providing wxWidgets 2.9.4 in the same way as wxPython, as a temporary workaround until developers of wxPerl catch up.
comment:13 Changed 10 years ago by mf2k (Frank Schima)
If you think that will allow p5-wx to work, then by all means, please do that.
comment:14 Changed 10 years ago by mf2k (Frank Schima)
Such a port should probably also replace and integrate the p5-alien-wxwidgets port which modifies wxwidgets in some way so as to work with p5-wx.
comment:15 Changed 10 years ago by mojca (Mojca Miklavec)
Are you able to figure out what exactly is needed? That is: what kind of modifications are done by p5-alien-wxwidgets? I'm not sure that I'm willing to "reimplement" the work done by p5-alien-wxwidgets, but if you are willing to help with that part ...
comment:16 Changed 10 years ago by mf2k (Frank Schima)
I don't know what is needed. However according to the description "Alien::wxWidgets allows wxPerl to easily find information about your wxWidgets installation. It can store this information for multiple wxWidgets versions or configurations (debug, Unicode, etc.). It can also build and install a private copy of wxWidgets as part of the build process.". So given that last sentence, maybe we should just modify the p5-alien-wxwidgets port to build the wxWidgets version it wants directly?
comment:17 Changed 10 years ago by mojca (Mojca Miklavec)
I would prefer to install wxWidgets separately from p5-alien-wxwidgets. If the files were installed with p5-alien-wxwidgets, that would mean recompiling wxWidgets for every version of Perl (both having several copies of wxWidgets for Perl 5.12, 5.14, 5.16 as well as recompiling after 5.16.1 switches to 5.16.2).
From what I see p5-alien-wxwidgets installs just two modules, one configuration file and two man pages, but it installs files to /opt/local/lib/perl5/vendor_perl/5.16.1, so I cannot install these files together with wxWidgets either.
The best bet would be to convince the author(s) of wxPerl to make the necessary changes to avoid the need for alien-wxwidgets, but they don't seems to be too responsive.
comment:18 Changed 10 years ago by mojca (Mojca Miklavec)
comment:19 Changed 10 years ago by mojca (Mojca Miklavec)
Even though I get a weird error on the buildbot and I have no clue what goes wrong:
Writing 'cpp/ovl_const.h'. Writing 'cpp/ovl_const.cpp'. touch wxt_overload make[1]: Entering directory `/opt/local/var/macports/build/_opt_mports_dports_perl_p5-wx/p5.8-wx/work/Wx-0.9922/ext' make[2]: Entering directory `/opt/local/var/macports/build/_opt_mports_dports_perl_p5-wx/p5.8-wx/work/Wx-0.9922/ext/test' cp lib/Wx/PerlTest.pm ../../blib/lib/Wx/PerlTest.pm /opt/local/bin/perl5.8 /opt/local/lib/perl5/5.8.9/ExtUtils/xsubpp -noprototypes -nolinenumbers -typemap /opt/local/lib/perl5/5.8.9/ExtUtils/typemap -typemap ../../typemap -typemap typemap PerlTest.xs > PerlTest.xsc && mv PerlTest.xsc PerlTest.c Error: Function definition too short 'INCLUDE_COMMAND: $^X -I../.. -MExtUtils::XSpp::Cmd -e xspp -- -t typemap.xsp -t ../../typemap.xsp XS/PerlTest.xsp' in PerlTest.xs, line 30 make[2]: *** [PerlTest.c] Error 1
comment:20 Changed 10 years ago by mojca (Mojca Miklavec)
Correction: the package actually builds fine, but only for Perl 5.14 and 5.16. For all other versions it complains about
Warning: prerequisite ExtUtils::ParseXS 3.15 not found. We have 2.21.
So either we need a more recent ParseXS in Perl or we should remove the package for older Perl versions.
comment:22 Changed 10 years ago by mojca (Mojca Miklavec)
ParseXS as a separate package has apparently been dropped in r103157.
See also the following thread http://www.nntp.perl.org/group/perl.wxperl.users/2010/03/msg7192.html saying:
Looks like you don't have required versions of
ExtUtils::XSppandExtUtils::ParseXSinstalled.
I removed support for earlier Perl versions in r115990, but if anyone needs support for those and can get a newer version of ParseXS working, feel free to add the support back.
The nasty part is that the default package (defaulting to Perl 5.12) fails as well.
comment:23 Changed 10 years ago by mojca (Mojca Miklavec)
I created a separate ticket about outdated ParseXS, #42153, so that this ticket can concentrate into getting p5-wx to work with wxWidgets 3.0.
comment:24 Changed 10 years ago by mojca (Mojca Miklavec)
Just a random though. We are currently providing:
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8 (wxWidgets/Carbon 2.8.12) /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0 (wxWidgets/Cocoa 3.0.0) /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/2.8 (wxWidgets/GTK 2.8.12) /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.0 (wxWidgets/GTK 3.0.0) - not needed, just for fun /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0 (wxWidgets/Cocoa 3.0.0) - currently the same as the main wxWidgets /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPerl/3.0 (wxWidgets/Cocoa 2.9.4)
and I would also need something like
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/Phoenix/3.0 (wxWidgets/Cocoa 3.0.1/trunk)
for Phoenix (the future wxPython).
I started wondering if it wouldn't perhaps be better to use:
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.8.12 (wxWidgets/Carbon 2.8.12) /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/2.9.4 (wxWidgets/Cocoa 2.9.4) - for wxPerl /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0.0 (wxWidgets/Cocoa 3.0.0) - also for wxPython /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0.1-dev (wxWidgets/Cocoa 3.0.1-trunk) - for Phoenix /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/2.8[.12] (wxWidgets/GTK 2.8.12) /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxGTK/3.0[.0] (wxWidgets/GTK 3.0.0) - not needed, just for fun
but I don't know how individual ports should be called if I wanted to install code to those locations.
comment:25 Changed 10 years ago by mf2k (Frank Schima)
I don't have an opinion because I don't know enough about Wx. Go with your gut since you are clearly the Wx expert here. I wanted to say thank you for fixing p5-wx. I installed p5.16-wx and it is working for me!
comment:26 Changed 10 years ago by mojca (Mojca Miklavec)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I'm closing the ticket. I committed a new version of p5-wx and p5-alien-wxwidgets in r118413.
There are still two or three issue (#43148, #43150, #43157) preventing users to build it on some OSes an for some versions of Perl, but I consider this specific issue fixed. Once the tickets mentioned here get fixed, I will most probably delete the wxPerl-3.0 port as well.
I also wonder if the new version of wxPerl fixed #42296. (It's fixed for me at least.)
I get completely different errors when compiling for 5.12:
Just curious: seeing
-I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/include/osx_cocoa-unicode-3.0in the flags of your build: shouldn't the port also depend onwxWidgets-3.0? Not that this would solve any problem you are experiencing.With 5.16 I get the same error. The error complains about
wxXML_ELEMENT_NODEnot being defined. What I did was:so I added
to
ext/xrc/cpp/xr_constants.cpp. But then it throws another error aboutI can confirm that
wx/generic/grid.hexpects three arguments:virtual void PaintBackground(wxDC& dc, const wxRect& rectCell, const wxGridCellAttr& attr);but it's up to the developer to find out why the third argument is missing and how to fix that. The same file in wxWidgets 2.8 indeed expects just two arguments: