wxWidgets fails to build 64-bit

[andrius.laikina@…]

wxWidgets26 2.6.4 fails to build on snow leopard, log attached

[andrius.laikina@…]

libsdl_mixer removed as dependency, debug enabled

[snc@…]

Curious, I can't get libsdl to build yet you have a receipt for it. How did you manage that?

[andrius.laikina@…]

Just apply patches from this ticket: #20235

[macports.org@…]

Cc Me!

[jmr@…]

CarbonFail. There's no way you're going to get wx to build for x86_64 if you applied the libsdl patch from #20235, BTW.

[lambda@…]

Cc Me!

[software@…]

Cc Me!

[koverholt@…]

Cc Me!

[software@…]

Debug report of installing wxWidgets

[software@…]

Now that libsdl and libsdl_mixer compile fine on 64-bit Snow Leopard, I bumped into this bug as well. It seem to be a bug in wxWidgets itself. Here is the error:

../src/common/intl.cpp:2060: error: 'smScriptLang' was not declared in this scope
../src/common/intl.cpp:2060: error: 'GetScriptVariable' was not declared in this scope
../src/common/intl.cpp:2061: warning: 'GetScriptManagerVariable' is deprecated (declared at /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Script.h:993)

And there seems to be a fix at the wxWidgets website (I have not tested it yet):

 http://wiki.wxwidgets.org/Development:_wxMac

[software@…]

PS: This applies to wxWidgets 2.8.10, the latest version. Perhaps the title of this bug should be adjusted.

[jrminter@…]

I agree. Now that libsdl and libsdl_mixer are fixed, I ran into this one.

[tzonghao@…]

Cc Me!

[allencmcbride@…]

Cc Me!

[allencmcbride@…]

I agree that the title should be changed. I had seen this bug listed on SnowLeopardProblems, but since the version was specified explicitly, I assumed it wouldn't apply to the current version.

[software@…]

So there seem to be two possible solutions:

• compile for 32-bit
• wait for wxWidgets 2.9 (since that uses cocoa instead of carbon)

Since most (all?) other libraries are build in 64-bit, it seems that the second option is best, especially since:

• wxWidgets 2.9 is already released
• there is already a MacPorts for wxWidgets 2.9 (ie. wxwidgets-devel)

So will the solution be to simple move the wxwidgets-devel Portfile contents to the wxwdiget Portfile?

[jmr@…]

This is 64-bit specific rather than Snow Leopard specific, and 2.6 is basically a lost cause.

[software@…]

I did manage to compile wxWidgets today. There are three, possibly four, 'bugs' to solve before it compiles. I'll list them here and include my Portfile and patch script. However, I had a busy day and did not have time to test it yet. If someone has that time, please do!

Also, the settings probably only work for OS 10.5 and higher. If this portfile is to be used on other platforms as well, it will be necessary to make a variant for this specific Darwin version. I have not done that yet.

I encountered the following bugs:

Bug number 1:

../src/osx/carbon/utils.cpp: In function 'void wxGetMousePosition(int*, int*)':
../src/osx/carbon/utils.cpp:161: error: 'GetGlobalMouse' was not declared in this scope

Problem: The osx_carbon GUI toolkit is selected. This ought to be the osx_cocoa GUI toolkit.

or

../include/wx/cocoa/cursor.h:42: error: default argument for parameter of type 'wxBitmapType' has type 'int'

Problem: The cocoa GUI toolkit is selected. This ought to be the osx_cocoa GUI toolkit.

Some Carbon libraries are no longer available in 64-bit. You should use Cocoa instead.

solution: change

  ./configure --with-mac
  ./configure --with-osx_carbon
  ./configure --with-carbon

or

  ./configure --with-cocoa

to:

  ./configure --with-osx_cocoa

Bug number 2:

wxWidgets/src/osx/core/printmac.cpp: In member function ‘virtual bool wxOSXPrintData::TransferFrom(const wxPrintData&)’:
wxWidgets/src/osx/core/printmac.cpp:142: error: ‘PMPaperCreate’ was not declared in this scope"

This is a PMPaperCreate() is a deprecated function since Mac OS 10.5. PMPrinterGetPaperList() should be used instead. There are two solutions: either install XCode 3.2 with Tiger (10.4) support enabled, or compile wxWdigets without 10.4 support: ./configure --with-macosx-version-min=10.5

See  http://trac.wxwidgets.org/ticket/11183

Bug number 3:

wxWidgets/src/osx/cocoa/textctrl.mm: In function 'void -[wxNSTextFieldEditor keyDown:](wxNSTextFieldEditor*, _message_ref_t*, NSEvent*)':
wxWidgets/src/osx/cocoa/textctrl.mm:144: error: no matching function for call to 'wxWidgetImpl::FindFromWXWidget(objc_object*)'

This is a bug in src/osx/cocoa/textctrl.mm, which was later fixed in subversion, and will be fixed in 2.9.1. See src/osx/cocoa/textctrl.mm

solution: see attached patch  http://groups.google.com/group/wx-dev/browse_thread/thread/8af9dd06f1a1a867 and  http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=61383

Bug number 4:

ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file

This is due to the settings in the configure script. The QuickTime library is included is (($USE_MAC and $USE_DARWIN) or $USE_COCOA) are set. If ./configure is called with --with-osx_cocoa, it seems that USE_MAC and USE_DARWIN are set, while USE_COCOA is not set. This is utterly confusing, and since it is "only" a warning, I did not look further in this matter.

[software@…]

Working portfile for wxWidgets 2.9.0

[software@…]

Patch for bug about no matching wxWidgetImpl::FindFromWXWidget function. Required for wxWidgets 2.9.0 Portfile

[koverholt@…]

Updated portfile and added the patch and wxWidgets compiles and installs for me on 10.6.1. Thanks!

[ram@…]

Cc Me!

[jakub.moskal@…]

Replying to koverholt@…:

Updated portfile and added the patch and wxWidgets compiles and installs for me on 10.6.1. Thanks!

Same here, wxWidgets 2.9.0 installed on 10.6.1, but can't install py26-wxpython now.

[vince@…]

You cannot install py26-wxpython, because only the svn version is compatible with wxwidgets-2.9.

If you are not faint hearted, and you need it as badly as I did, I post you the contents of my private py26-wxwidgets-devel port which compiles and runs 64-bit (one Portfile and three patches). Enjoy.

[vince@…]

Portfile for "py26-wxpython-devel"

[vince@…]

Patch #1 for "py26-wxpython-devel"

[vince@…]

Final patch for py26-wxwidgets-devel

[vince@…]

PS : you should select the +wx29 +cocoa variants

[jakub.moskal@…]

Replying to vince@…:

You cannot install py26-wxpython, because only the svn version is compatible with wxwidgets-2.9. If you are not faint hearted, and you need it as badly as I did, I post you the contents of my private py26-wxwidgets-devel port which compiles and runs 64-bit (one Portfile and three patches). Enjoy.

I downloaded the Portfile and the patches for py26-wxpython-devel that you posted, I had to rename the dependent lib from wxWidgets-devel to wxWidgets (I installed the wxWidgets-2.9 under that name), but when the patches are applied I am getting this error:

--->  Computing dependencies for py26-wxpython-devel
--->  Fetching py26-wxpython-devel
--->  Verifying checksum(s) for py26-wxpython-devel
--->  Extracting py26-wxpython-devel
--->  Applying patches to py26-wxpython-devel
Error: Target org.macports.patch returned: shell command " cd "/opt/local/var/macports/build/_Users_Jakub_ports_python_py26-wxpython-devel/work/trunk" && /usr/bin/patch -p0 < '/Users/Jakub/ports/python/py26-wxpython-devel/files/patch-propgrid_wrap.diff'" returned error 1
Command output: patching file src/osx_cocoa/propgrid_wrap.cpp
Hunk #1 FAILED at 3541.
1 out of 1 hunk FAILED -- saving rejects to file src/osx_cocoa/propgrid_wrap.cpp.rej

Here's the contents of propgrid_wrap.cpp.rej:

***************
*** 3541,3547 ****
      }
      else if ( input == Py_None )
      {
-         *v = new wxPGPropArgCls(NULL);
      }
      else
      {
--- 3541,3547 ----
      }
      else if ( input == Py_None )
      {
+         *v = new wxPGPropArgCls((const wxPGProperty*) NULL);
      }
      else
      {

[jakub.moskal@…]

Cc Me!

[vince@…]

Maybe they have corrected the bug. That's the problem with svn ports: they evolve. Try removing the patch from patchfiles in the Portfile and try again.

[software@…]

May I suggest to only discuss wxWidgets in this bug report. Perhaps report #21530 is best to discuss wxPython/py26-wxWidgets

[muchatel@…]

Cc Me!

[earcar@…]

Cc Me!

[jochen@…]

Cc Me!

[macports@…]

Cc Me!

[r1pp3r@…]

Cc Me!

[orez.org@…]

Cc Me!

[macports@…]

Cc Me!

[gentoomeo@…]

Cc Me!

[lstoll@…]

Cc Me!

[andreas.wilm@…]

Cc Me!

[matt.leotta@…]

Cc Me!

[rvr@…]

CC Me!

[mrb@…]

Cc Me!

[liam.candy@…]

Cc Me!

[haraoka@…]

libsdl_mixer was upgraded on 10.5.8(ppc). The build result of wxWidgets(2.6.4&2.8.9&2.9.0) failed as follows.

$ sudo port -dv archive wxWidgets +universal
g++-4.0: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
make: *** [.pch/wxprec_monodll/wx/wxprec.h.gch] Error 1

    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 9)
    invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for wxWidgets): org.macports.archive org.macports.build org.macports.destroot
Error: Status 1 encountered during processing.

[tzonghao@…]

Cc Me!

[stejanecek@…]

Cc Me!

[mlk@…]

Cc Me!

[julienb@…]

Cc Me!

[r1pp3r@…]

Cc Me!

[r1pp3r@…]

Cc Me!

[francis@…]

Cc Me!

[software@…]

I did test the patches I submitted two months ago on the following platforms:

• Mac OS 10.6 on Intel (64-bit)
• Mac OS 10.5 on Intel (32-bit)
• Mac OS 10.5 on PPC G4 (32-bit)

haraoka is correct that it does not compile on PPC with the +universal variant. However, that bug is due compiling with multiple targets as output, and not to this bug.

I am wondering why the patched Portfile has not yet been put in the repository.

[software@…]

Replying to haraoka@…:

The build result of wxWidgets(2.6.4&2.8.9&2.9.0) failed as follows. $ sudo port -dv archive wxWidgets +universal

For the record, I opened a new ticket for this report as it only occurs with the +universal flag and existed with earlier portfiles as well: #22815

[software@…]

I just posted to the mailing list:

Apparently this problem was fixed long ago by introducing a new port, called wxWidget-dev.

Frankly, it is beyond me what the use is of a wxWidgets-dev, since packages like wxPython depends on wxWidgets and not on wxWidgets-dev, people can still not use the MacPorts solution and will get stuck anyway.

(sorry to sound a bit bitter here; It did of course compile the thing manually, but decided to spend a few hours testing it on different platforms, checking if all was OK and contributing back to the community. It really is quite frustrating to see that such good effort turns out to be fruitless because someone else solved it but did not bother to tell the world about it. That makes me wonder if I better had spend time on something else that on contributing to MacPorts.)

[jmr@…]

use X11 instead of wxMac when building 64-bit

[jvliwanag@…]

Cc Me!

[hmng@…]

Cc Me!

[stefan@…]

Cc Me!

[celil.rufat@…]

Cc Me!

[celil.rufat@…]

Cc Me!

[celil.rufat@…]

Cc Me!

[johncumbers@…]

Cc Me!

[singingwolfboy@…]

Cc Me!

[macports@…]

Cc Me!

[macports@…]

Cc Me!

[gchaynes@…]

Cc Me!

[takashi@…]

Cc Me!