Opened 4 weeks ago

Last modified 4 weeks ago

#61933 assigned defect

wxmaxima crashes on macOS Big Sur v11k - conflicting wxWidget libs

Reported by: chlangley Owned by: MSoegtropIMC
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: wxmaxima

Description (last modified by ryandesign (Ryan Schmidt))

installing wxmaxima (20.04) into a fresh macport (macOS Big Sur v11) the app crashes immediately with the following complaint in the log:

Dec 28 23:46:53 rootless8 wxmaxima[91466]: objc[91466]: Class wxOSXStatusItemTarget is implemented in both /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_adv-3.0.0.4.0.dylib (0x105e5a6d8) and /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_adv-3.0.dylib (0x1048056d8). One of the two will be used. Which one is undefined.

Change History (5)

comment:1 Changed 4 weeks ago by ryandesign (Ryan Schmidt)

Description: modified (diff)
Owner: set to MSoegtropIMC
Status: newassigned

That message may or may not be relevant to the crash. Please attach the full crash log.

comment:2 Changed 4 weeks ago by ggruener

The is implemented in both... warning is repeated very many times.

These warnings are then followed by very many

../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" failed in Register(): Class "wxCommandEvent" already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?

And then

 ../src/common/stdpbase.cpp(62): assert "traits" failed in Get(): create wxApp before calling this
Segmentation fault

Inspecting /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/ shows that three equal files exist per each lib instead of two symbolic links pointing to the versioned lib. For example:

-rwxr-xr-x  1 root  wheel   743K Nov 23 09:52 libwx_osx_cocoau_xrc-3.0.0.4.0.dylib*
-rwxr-xr-x  1 root  wheel   743K Nov 23 09:52 libwx_osx_cocoau_xrc-3.0.0.dylib*
-rwxr-xr-x  1 root  wheel   743K Nov 23 09:52 libwx_osx_cocoau_xrc-3.0.dylib*

Making symbolic links to the versioned lib fixes the problem. For example:

-rwxr-xr-x   1 root  wheel   743K Nov 23 09:52 libwx_osx_cocoau_xrc-3.0.0.4.0.dylib*
lrwxr-xr-x   1 root  wheel    36B Dec 29 15:25 libwx_osx_cocoau_xrc-3.0.0.dylib@ -> libwx_osx_cocoau_xrc-3.0.0.4.0.dylib
lrwxr-xr-x   1 root  wheel    32B Dec 29 15:25 libwx_osx_cocoau_xrc-3.0.dylib@ -> libwx_osx_cocoau_xrc-3.0.0.dylib

I fixed the symlinks for all libs in the directory. After this fix, wxmaxima starts correctly without warning.

So I guess the source of the problem lies in the installation of port wxWidgets-3.0. Perhaps it can be corrected to create symlinks instead of copies of the libs.

comment:3 Changed 4 weeks ago by MSoegtropIMC

Thanks for the report and the propsed fix! I just would say that this isn't an issue of wxMaxima, but an issue of wxWidgets and should be reported there. I don't think it would be appropriate for wxMaxima to change symlinks/files of other packages.

Please don't close the ticket until it is fixed in wxWidgets, so that people can see your porposed fix!

comment:4 Changed 4 weeks ago by MSoegtropIMC

P.S.: If I don't hear from you that you want to report it to wxWidgets, I will do so tomorrow.

comment:5 Changed 4 weeks ago by kencu (Ken)

We believe this is due to a bug in Apple's install_name_tool.

See this current email chain: <https://lists.macports.org/pipermail/macports-users/2020-December/049255.html>

There is nothing wrong with wxWidgets, although it uses install_name_tool and so reveals the bug.

The proper fix is to fix install_name_tool, although folks might need to work around this issue until that is done.

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)
Note: See TracTickets for help on using tickets.