Hi Charles

what does get installed on the machines, brew, any other tools, Xcode versions ?
what macOS version version do these machines have ?
which wx download ?
could you paste a config.log and a build log from the working and non-working machines ?

The files can be copied instead of being linked if ln -s was somehow determined to not work by configure. Please check (or ask the students to check) for the "checking whether ln -s works..." line in config.log and confirm that it says something like "no, using cp -pR". If it does, this means that running ln -s conf$$.file conf$$ during configure failed. I have no idea why could it happen, but perhaps you/they're using a file system not supporting sym links?

In any case, this is not such a huge problem per se as, except for wasting disk space, copying the libraries should still work and there is absolutely no reason for the link to fail when using the actual files rather than symlinks. Again, we need more information here, at the very least the (full) linker command line and the error messages (at least the first few ones if there are many of them).

Finally, concerning "generating fake signature", I have no idea where does it come from, but it definitely does not come from anything in wx.

This one makes no sense to me. I can send a config.log file if you wish. It is finding ls -s and indicating that it is working. Their systems were identical to mine. Same Mac OS version. Some Xcode compiler versions. The problem only occurs on Apple Silicon Macs. No students with Intel Macs reported an issue at all. I sat with a student in my office for hours trying to get it to work. It would fail when the /usr/local/lib directory had all files and no links, which their system did on install and mine does not. The program crashes with a large number of errors occurring during runtime like this:

Class wxNSAppController is implemented in both /usr/local/lib/libwx_osx_cocoau_core-3.2.0.1.0.dylib (0x104cb9998) and /usr/local/lib/libwx_osx_cocoau_core-3.2.dylib (0x102495998). One of the two will be used. Which one is undefined.
objc[76181]: Class ModalDialogDelegate is implemented in both /usr/local/lib/libwx_osx_cocoau_core-3.2.0.1.0.dylib (0x104cb99c0) and /usr/local/lib/libwx_osx_cocoau_core-3.2.dylib (0x1024959c0). One of the two will be used. Which one is undefined.
objc[76181]: Class wxNSApplication is implemented in both /usr/local/lib/libwx_osx_cocoau_core-3.2.0.1.0.dylib (0x104cb9a10) and /usr/local/lib/libwx_osx_cocoau_core-3.2.dylib (0x102495a10). One of the two will be used. Which one is undefined.
objc[76181]: Class wxCPWCDelegate is implemented in both /usr/local/lib/libwx_osx_cocoau_core-3.2.0.1.0.dylib (0x104cb9a60) and /usr/local/lib/libwx_osx_cocoau_core-3.2.dylib (0x102495a60). One of the two will be used. Which one is undefined.

I recreated the condition on my Mac of all of the files being files and no symlinks and it builds and run just fine for me. The program crashes for them. When we copied the lib directory using cp -a, the problem goes away on their systems. I don't know why it would be trying to use more than one copy of the library on theirs, but only one on mine.

It's working for now and hopefully will not be an issue, but I sure would like to know what is going on here.

Could they have something already in their /usr/local/lib? E.g. would installing into a different (and unique) directory work?

This still wouldn't explain everything, but it's the only beginning of an explanation I can think of...

I actually deleted all of the wxWidgets files from the /usr/local/lib and that was all they had in there.

This continues to be an issue with students this semester. I'm having the ones it fails on instead build static libraries and that is working. But there is something that is broken in the installation that is causing this to happen only on certain machines. I have probably a hundred students with Macs, many of them Apple Silicon and this problem occurs on only a few.

@charles-owen ,
What is the pattern?
Can you see what is happening in the install log?

Are their Macs completely the same or some have different set of software/different OS version?

Thank you.

I wish I knew. I'm sure something must be different, but they are all recent machines, have the same versions of OS and tools as my machine, and appear identical. I'm sure it has to be something they have installed that we are not aware causes an issue.

Might these students have something extra installed on their Macs which comes before the standard tools in the PATH? E.g. might otool or install_name_tool not be the one we're expecting. Please ask them to check their path and/or run which on these commands. The "fake signatures" line is something that must be generated by some non-standard tool they have, there is simply no other explanation.

Also, please ask them to at least send you the full log of make install. It's really impossible for us to do anything without having any information.

Conda package has the same issue. Because of the duplicate files, the "osx-arm64" package has 10.6MB and the "osx-64" package has only 6.5MB. I see the same "is implemented in both" warnings.
https://anaconda.org/conda-forge/wxwidgets/files

Sorry, where do you see this warning? Is there a log of the build available somewhere? I'm also not sure if the problem is in ARM or x64 package, it looks like you say that it's in the latter, while this issue is about ARM, which is a bit confusing.

I'm using an arm64 Apple M1 (macOS 14.4.1). I see warnings when running programs which link to conda-forge::wxwidgets.

Example:

conda create -n wx -c conda-forge wxwidgets limesuite
conda activate wx
LimeSuiteGUI

First 5 and last 5 lines of warnings:

objc[94569]: Class wxNSAppController is implemented in both /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.0.2.2.dylib (0x1078eda88) and /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.dylib (0x106399a88). One of the two will be used. Which one is undefined.
objc[94569]: Class ModalDialogDelegate is implemented in both /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.0.2.2.dylib (0x1078edab0) and /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.dylib (0x106399ab0). One of the two will be used. Which one is undefined.
objc[94569]: Class wxNSApplication is implemented in both /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.0.2.2.dylib (0x1078edb00) and /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.dylib (0x106399b00). One of the two will be used. Which one is undefined.
objc[94569]: Class wxCPWCDelegate is implemented in both /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.0.2.2.dylib (0x1078edb50) and /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.dylib (0x106399b50). One of the two will be used. Which one is undefined.
objc[94569]: Class wxFontPanelDelegate is implemented in both /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.0.2.2.dylib (0x1078edba0) and /Users/thomas/miniforge3/envs/wx/lib/libwx_osx_cocoau_core-3.2.dylib (0x106399ba0). One of the two will be used. Which one is undefined.
...
./src/common/object.cpp(239): assert "classTable->Get(m_className) == __null" failed in Register(): Class "wxWizardEvent" already in RTTI table - have you used wxIMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
./src/common/object.cpp(239): assert "classTable->Get(m_className) == __null" failed in Register(): Class "wxEditableListBox" already in RTTI table - have you used wxIMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
./src/common/object.cpp(239): assert "classTable->Get(m_className) == __null" failed in Register(): Class "wxQueryLayoutInfoEvent" already in RTTI table - have you used wxIMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
./src/common/object.cpp(239): assert "classTable->Get(m_className) == __null" failed in Register(): Class "wxCalculateLayoutEvent" already in RTTI table - have you used wxIMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
./src/common/object.cpp(239): assert "classTable->Get(m_className) == __null" failed in Register(): Class "wxSashLayoutWindow" already in RTTI table - have you used wxIMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?

This is not specific to LimeSuiteGUI, other wxwidgets based programs show the same warnings.

I pointed out the file size difference of the arm64 and x64 packages because the x64 package contains dylib symlinks (as expected) and the arm64 package contains copies of each dylib (not expected).

If I manually replace the copies with symlinks, the warnings go away.

Build recipe: https://github.com/conda-forge/wxpython-feedstock
Build log: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=911459&view=logs&j=1e869e56-b0a2-5745-eb6f-ceaab3c34dd0&t=1eb80998-6df2-53a6-6da3-1c6173e52460

In the build log it looks like it's creating symlinks. Not sure what's going on 🤔

I now ran a local build with the same recipe and interrupted right after make install and there are only copies installed, no symlinks.

install_name_tool replaces the symlinks with copies, here:

Thanks, this looks like the issue described here i.e. it's specific to some Xcode version(s), apparently.

We probably should try to work around this somehow, and if we could do it before the upcoming 3.2.5, it would be great. Any PRs with fixes would definitely be very welcome!