Main error
Process failed:
dyld[29269]: Library not loaded: /usr/local/opt/libpng/lib/libpng16.16.dylib
Referenced from: /Users/hanbing/opt/anaconda3/envs/brainreg/lib/python3.9/site-packages/brainreg/bin/nifty_reg/osX/reg_aladin
Reason: tried: '/usr/local/opt/libpng/lib/libpng16.16.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/lib/libpng16.16.dylib' (no such file), '/usr/lib/libpng16.16.dylib' (no such file), '/opt/homebrew/Cellar/libpng/1.6.37/lib/libpng16.16.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/lib/libpng16.16.dylib' (no such file), '/usr/lib/libpng16.16.dylib' (no such file)
Tried brew install libpng $ brew update $ brew upgrade libpng . None of them work.
Laptop information:
OS: macOS, M1 CPU
Version: 12.0.1
Hardware specs: 1 TB flash storage and external
2TB USB DISK
Python version: 3.9
Thanks!
I guess you migrate from an Intel Mac to M1 Mac. After upgrade Mac version also can meet some libs error.
This is because brew install some libs maybe using compile source code as binary file, this file only works to specific platform.
Maybe you can reinstall it, brew reinstall libpng.
Related
I have a Mac which architecture is:
$ arch
arm64
(it supports x86_64 and aarch64).
And I have installed openssl library with brew tool. Now I try to build my application for x86_64 platform (it's Haskell application and the build script is large and complex, so I cannot show it here) and I get an error:
...
<command line>: dlopen(/MyWork/.stack/snapshots/x86_64-osx/b1d675598b9b6c5f516e03f82c45d01becd6003e6128005b2b4acb8628b0f350/9.2.5/lib/x86_64-osx-ghc-9.2.5/libHSHsOpenSSL-0.11.7.2-1JX1qBi8YfpGDjk1ra3OXq-ghc9.2.5.dylib, 0x0005): symbol not found in flat namespace '_DSA_free'
...
However, it works fine for aarch64 platform. After little research I see that my OpenSSL libraries are:
$ file /opt/homebrew/opt/openssl#3/3.0.7/lib/libssl.3.dylib
/opt/homebrew/opt/openssl#3/3.0.7/lib/libssl.3.dylib: Mach-O 64-bit dynamically linked shared library arm64
which seems that it is a library for arm64 and not x86_64, so maybe this is the reason of the error "symbol not found in flat namespace '_DSA_free'".
How to fix it? I guess I need to install the second openssl - for x86_64, I tried arch -x86_64 brew install openssl but I get:
Warning: openssl#3 3.0.7 is already installed and up-to-date.
To reinstall 3.0.7, run:
brew reinstall openssl#3
which makes sense - it is installed already (but for arm64).
How to fix/workaround this problem, so to be able to build the application for both platform while it depends on external libraries like openssl? Maybe there is a way to install openssl for both platform?
EDIT:
Currently I found 2 solutions:
to install libraries from sources setting prefix=/unique/folder/for/arch and to prefix ./configure ..., make, make install by arch -ARCH (where ARCH is x86_64 or arm64).
Another way is to have 2nd Homebrew, it's described here
On my OS X 10.7.4 Mac I do:
export DYLD_LIBRARY_PATH=/usr/local/lib:$DYLD_LIBRARY_PATH
But afterwards I get this sort of errors:
dyld: Library not loaded: /usr/lib/libncurses.5.4.dylib
Referenced from: /bin/ls
Reason: Incompatible library version: ls requires version 5.4.0 or later, but libncurses.5.4.dylib provides version 5.0.0
Trace/BPT trap: 5
To alleviate this problem, I've built the libncurses.5.4.dylib from scratch and installed it into the /usr/local/ncurses-5.9 and did:
sudo mv /usr/lib/libncurses.5.4.dylib /usr/lib/libncurses.5.4.dylib_BACKUP
sudo ln -s =/usr/local/ncurses-5.9/lib/libncursesw.5.4.dylib /usr/lib/libncurses.5.4.dylib
This newly built libncurses works fine but as soon as I do
export DYLD_LIBRARY_PATH=/usr/local/lib:$DYLD_LIBRARY_PATH
it returns the same dyld: Library not loaded: /usr/lib/libncurses.5.4.dylib
As a comparison: When I do the same export DYLD_LIBRARY_PATH=/usr/local/lib:$DYLD_LIBRARY_PATH on my OS X 10.5.6 Mac, it gives no error whatsoever. So I think it should work my OS X 10.7.4 Mac, too.
What should I do to make it work? Thank you.
Ops! When I checked the /usr/local/lib directory, I've found that there were libncurses.dylib files there and because the exported DYLD_LIBRARY_PATH was loading them and they were obviously not binary compatible with the system, I was getting the error.
After I deleted those obselete libncurses.dylib files under /usr/local/lib the error is gone. Problem solved.
I've just update my MAC OS Mountain Lion's compiler to gcc 4.8.1, the configure & install process is:
./configure --prefix=/usr
make
sudo make install
the GCC 4.8.1 was installed completely, but then I found I cannot open my Chrome, as well as several other programs. I've check the error report, the most important information is:
Dyld Error Message:
Library not loaded: /usr/lib/libstdc++.6.dylib
Referenced from: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
Reason: no suitable image found. Did find:
/usr/lib/libstdc++.6.dylib: mach-o, but wrong architecture
/usr/lib/libstdc++.6.dylib: mach-o, but wrong architecture
So what should I do to solve this? Recompile GCC with proper architecture? But how to do this?
You have overwritten several system libraries with incompatible versions. You will need to reinstall Mac OS X.
Don't install software with --prefix=/usr. That prefix is reserved for software distributed with the operating system. Use /usr/local for software you install yourself. You may want to try Homebrew instead once you've reinstalled.
Since libstdc is deprecated and removed in iOS12, you need to update your dependencies to use libc++ or manually add libstdc. For manually adding refer this - answer
I was attempting to install XML::LibXSLT via CPAN, this seemed to work fine, until I attempted to load Google Chrome, or Microsoft Office. I am getting an error launching these programs with the following errors:
Dyld Error Message:
Library not loaded: /usr/lib/libxslt.1.dylib
Referenced from: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks
/DictionaryServices.framework/Versions/A/DictionaryServices
Reason: no suitable image found. Did find:
/usr/lib/libxslt.1.dylib: mach-o, but wrong architecture
/usr/lib/libxslt.1.dylib: mach-o, but wrong architecture
Obviously the problem is the new dylibs that XSLT installed, but these all seem to be X86_64 so I shouldn't be seeing any issues with this, I am running Mac OS X 10.6.8.
When running file /opt/local/lib/libxslt.dylib
I get:
/opt/local/lib/libxslt.dylib: Mach-O 64-bit dynamically linked shared library x86_64
as is the same with the libxslt.1.dylib.
Is there a way to solve this issue, and reinstate the original files that must have been replaced?
Edit: If were to get a copy of these Libraries from another Mac 10.6.8 64 bit and replace my apparantly confused ones with these, would this at least solve the issue of them being all mixed up.
Also running
[/usr/lib]$ ls | grep libxslt gives me :
libxslt 2.dylib
libxslt-plugins
libxslt.1.dylib
libxslt.a
libxslt.dylib
libxslt.la
libxslt.pc
Did you install into or otherwise replace the original Apple-supplied libraries in /usr/lib? You should never do that. Otherwise, you'll likely break other parts of OS X that depend on those libraries. You should restore the original libraries from a backup or reinstall OS X. If you want newer versions, you should install them elsewhere, like in /usr/local/lib. Or better yet you should be using a third-party package manager, like Homebrew or MacPorts; in fact, you appear to be using MacPorts, judging from the /opt/local/lib path. Use that and don't alter system files in /usr (other than /usr/local) or /System/Library.
This may be relevant: How to compile universal binaries on Mac OS X.
I ran into this same issue where I had re-compiled libxslt and libxml to support python bindings, then started getting the /usr/lib/libxslt.1.dylib: mach-o, but wrong architecture error and an immediate crash when starting some apps (Specifically Synergy, which is a 32-bit/i386 app)
I solved this by recompiling libxml2 and libxslt using these configure options:
./configure CFLAGS="-arch i386 -arch x86_64" \
CXXFLAGS="-arch i386 -arch x86_64" \
LDFLAGS="-arch i386 -arch x86_64" \
--disable-dependency-tracking
Now libxml2 and libxslt libraries are properly showing as universal binaries:
$ file /usr/local/lib/libxslt.1.dylib /usr/local/lib/libxslt.1.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libxslt.1.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/local/lib/libxslt.1.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
$ file /usr/local/lib/libxml2.2.dylib
/usr/local/lib/libxml2.2.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libxml2.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/local/lib/libxml2.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
I have asked a question on SuperUser about updating Ruby version in Google SketchUp. It seems that there is something different between Ruby shipped with the standard OS X distribution, and Ruby installed by RVM or MacPorts. I get the following error message when I try to use RVM's or MacPorts' Ruby 1.9.1
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Dyld Error Message:
Library not loaded: #executable_path/../Frameworks/Ruby.framework/Versions/A/Ruby
Referenced from: /Applications/Google SketchUp 7/SketchUp.app/Contents/MacOS/SketchUp
Reason: no suitable image found. Did find:
/Applications/Google SketchUp 7/SketchUp.app/Contents/MacOS/../Frameworks/Ruby.framework/Versions/A/Ruby: mach-o, but wrong architecture
/Applications/Google SketchUp 7/SketchUp.app/Contents/MacOS/../Frameworks/Ruby.framework/Versions/A/Ruby: mach-o, but wrong architecture
/usr/lib/Ruby: not a file
Model: MacBookPro7,1, BootROM MBP71.0039.B05, 2 processors, Intel Core 2 Duo, 2.4 GHz, 4 GB, SMC 1.62f5
But it works with Ruby 1.8.7 from /System/Library/Frameworks/Ruby.framework/
UPDATE1
As it was explained by Alex I need to compile Ruby with i386 architecture. One can do it for MacPorts and RVM, but none of the methods worked for me due to various errors.
How to forece i386 build on snow leopard macports ?
Internal config files
Darwin OS
So I decided to compile Ruby 1.9.2-rc2 from sources
$ ARCHFLAGS="-arch i386" CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure --with-arch=i386
$ make && sudo make install
and copy corresponding files to SketchUp
$ cd /Applications/Google\ SketchUp\ 7/SketchUp.app/Contents/Frameworks/Ruby.framework/Versions/A/
$ rm -r Headers Ruby
$ cp /usr/local/bin/ruby Ruby
$ mkdir Headers
$ cp /usr/local/include/ruby-1.9.1/i386-darwin10.4.0/ruby/config.h Headers/
$ cp /usr/local/include/ruby-1.9.1/ruby.h Headers/
$ cp -r /usr/local/include/ruby-1.9.1/ruby/* Headers/
$ ls Headers
backward/ defines.h dl.h intern.h missing.h re.h ruby.h util.h vm.h
config.h digest.h encoding.h io.h oniguruma.h regex.h st.h version.h
This time I have got the following message
Dyld Error Message:
Library not loaded: #executable_path/../Frameworks/Ruby.framework/Versions/A/Ruby
Referenced from: /Applications/Google SketchUp 7/SketchUp.app/Contents/MacOS/SketchUp
Reason: no suitable image found. Did find:
/Applications/Google SketchUp 7/SketchUp.app/Contents/MacOS/../Frameworks/Ruby.framework/Versions/A/Ruby: can't map
/Applications/Google SketchUp 7/SketchUp.app/Contents/MacOS/../Frameworks/Ruby.framework/Versions/A/Ruby: can't map
/usr/local/lib/Ruby: not a file
/usr/lib/Ruby: not a file
Looks like you have versions of the Ruby library in the sketchup directories for two architectures (probably 32-bit intel, and PPC, I'd guess) and are trying to use a Ruby binary built of a third and different architecture (probably 64-bit intel, I'd guess). You can check with the arch command at a Terminal.App shell prompt.
If this should indeed prove to be the problem, you could maybe try to build a 1.9 ruby from sources, targeting 32-bit intel CPUs...? (I don't know of any prepackaged ruby 1.9 for mac built for 32-bit intel CPUs -- of course, there might well be some I don't know about!-).
Was this solved? To answer the general question in your title, which is why I clicked on this:
System Ruby (1.8.7, I think) comes preloaded and is not overwritten by MacPorts or RVM. MacPorts writes by default to a different directory and Terminal begins to resolve to that new installation, leaving system Ruby sitting unused. RVM creates its own virtual installations of Ruby and can switch between those and system Ruby using $ rvm use.