-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installation failing on Apple Silicon Macs #23143
Comments
Hi Charles what does get installed on the machines, brew, any other tools, Xcode versions ? |
The files can be copied instead of being linked if 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. 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 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 , 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 Also, please ask them to at least send you the full log of |
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. |
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:
This is not specific to I pointed out the file size difference of the If I manually replace the copies with symlinks, the warnings go away. Build recipe: https://github.com/conda-forge/wxpython-feedstock |
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 |
Line 3503 in 95d1413
|
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! |
For some reason several students in my course are having the installation fail for wxWidgets on Apple Silicon Macs. They are doing:
sudo make install
This should install the system into /usr/local/lib. For some users, instead of creating the shared library and links to the library, it is creating the actual library files three times. For example:
-rwxr-xr-x 1 student staff 15824056 Jan 13 16:36 libwx_osx_cocoau_core-3.2.0.1.0.dylib
-rwxr-xr-x 1 student staff 15824056 Jan 13 16:36 libwx_osx_cocoau_core-3.2.0.dylib
-rwxr-xr-x 1 student staff 15824056 Jan 13 16:36 libwx_osx_cocoau_core-3.2.dylib
During the install there are a bunch of lines in their output that say "generating fake signature". I don't see those lines on my output.
This causes an error due to linking the same library more than once for some reason. What is strange is that some of those systems are configured exactly the same as my system and it works just fine for mine.
I have temporarily fixed the problem by deleting the files and manually copying the lib directory using cp -a, but want to know what is broken on those systems that makes the install fail?
The text was updated successfully, but these errors were encountered: