I am trying to upgrade to PHP 5.6 from PHP 5.5. Then I receive the following error on curl install:
Executing post-install script /tmp/5.6-10.10-frontenddev-post-install
dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /opt/local/bin/grep
Reason: Incompatible library version: grep requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
Restarting Apache
I have:
No environment variables set for dylib
otool -L /opt/local/lib/libiconv.2.dylib returns: /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
port installed returns libiconv #1.14_0 (active), the latest version.
It looks like:
otool -DL /usr/lib/libiconv.2.dylib
returns:
/usr/lib/libiconv.2.dylib:
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
So the system version is being accessed by PHP install. How can I make it point to the local lib version?
Trying sudo port -n upgrade --force libiconv for now..
Related
I am trying to find the standard C library on Mac OS X. I've tried paths like: "/usr/lib/libc.a" or "/usr/lib/libm.a" , but there aren’t such files on the system. Where can I find it?
Then I used a terminal at a Linux machine and run such a command:
ar t /usr/lib/libc.a
It returns a list of .o files and those .o files are like these:
svc.o
xdr.o
...
What are the meanings of these files? Where can I find them?
The standard library is part of libSystem.dylib on OS X.
It looks like it is
/usr/lib/libSystem.B.dylib
on my machine (Mac OS X v10.6.7 (Snow Leopard)).
You can find out using otool — this is on a Mac running macOS v10.14.2 (Mojave), and the (very simple) program was built using Clang from Xcode:
$ otool -L al
al:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
$ clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Other programs have more libraries. For example, this Tower of Hanoi program was built with a home-built GCC 8.2.0 and the ncurses library:
$ otool -L hanoi
hanoi:
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
/opt/gcc/v8.2.0/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
And another program uses still more:
$ otool -L $(which sqlcmd)
/Users/jonathanleffler/bin/sqlcmd:
/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
isqls09b.dylib (compatibility version 0.0.0, current version 0.0.0)
iasfs09b.dylib (compatibility version 0.0.0, current version 0.0.0)
igens09a.dylib (compatibility version 0.0.0, current version 0.0.0)
iosls09a.dylib (compatibility version 0.0.0, current version 0.0.0)
sobj4/igl4a304.dylib (compatibility version 0.0.0, current version 0.0.0)
sobj4/iglxa304.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
/opt/gcc/v8.2.0/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
And system programs may use other libraries and frameworks:
$ otool -L $(which passwd)
/usr/bin/passwd:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1561.0.0)
/System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libpam.2.dylib (compatibility version 3.0.0, current version 3.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
$ otool -L /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.63.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.51.2)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 888.51.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)
There are many other jobs that can be done with otool — look at the man page.
To answer your second question: static libraries are kept in archive files, hence the .a. As such they are just containers for a bunch of files, just like ZIP, TAR, RAR, etc. minus any compression. Those files listed by the ar (stands for archive) utility are the original files packed into the archive. You could unpack it and get the original files.
Static libraries are in stark contrast to dynamic libraries. A static library's contents are extracted by the linker and included into your program upon linking, as if they were just results of other compilation stages of your program's build process.
Dynamic libraries, on the other hand, are not just archives of object files, but they're linked executables by itself and the dynamic linker maps them into the linking processes address space and adjusts the symbol tables to match the mapped address.
To answer the other half of your question, OS X does not generally use static libraries (.a). As such, there is no libc.a (or libSystem.a) on OS X.
Actually, it did exist at /usr/lib/system/libsystem_c.dylib.
You could verify that with: nm -gU /usr/lib/system/libsystem_c.dylib
The file has been moved/removed since macOS v11 (Big Sur).
My Mac OS system is: OS X Yosemite version 10.10.5.
And its openssl version is 0.9.8zg.
Now I want to install an nghttp2 tool, and it requires openssl>=1.0.1.
So I try brew update and brew install openssl.
After that I use command: openssl version,it shows:OpenSSL 1.0.2l 25 May 2017.
But when I go to nghttp2 directory and run the ./configurecommand,it still shows:
configure: Requested 'openssl >= 1.0.1' but version of OpenSSL is 0.9.8zg.
I am confused, why the latest version not used but still use the old one?
There is a dynamic-linking-conflict between different libjpeg dynamic libraries on OSX. First there is a standard native libJPEG.dylib (in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/). But if you are using MacPorts, you can also have a port-related libjpeg.dylib in (in /opt/local/lib). The latter may for example have been installed as a dependency for some other port.
This creates a problem when you link against your system libJPEG (which is preferred).
Then if /opt/local/lib is in DYLD_LIBRARY_PATH, that path will be prioritised when searching for a dynamic lib, resulting in a runtime error when loading symbols:
dyld: Symbol not found: __cg_jpeg_resync_to_restart
Referenced from:
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /opt/local/lib/libJPEG.dylib
in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
Trace/BPT trap: 5
So I have two questions (likely related):
What is a good way of solving the actual problem (removing /opt/local/lib from DYLD_LIBRARY_PATH obviously solves it but creates problems for other dependencies)?
What other paths are searched for dynamic libs (I.e. Where is the "/System/Library" path specified) and why does DYLD_LIBRARY_PATH rank higher priority-wise?
I experienced similar problem while using OpenCV in MacOS El Capitan. Solved the problem using the solution in the link
Solution is to delete some dlylibs in the /usr/local/lib directory and create symbolic links to related files /System/Library/Frameworks/ImageIO.framework/Resources/
cd /usr/local/lib
rm libgif.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libGIF.dylib libGIF.dylib
rm libjpeg.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libJPEG.dylib libJPEG.dylib
rm libtiff.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libTIFF.dylib libTIFF.dylib
rm libpng.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libPng.dylib libPng.dylib
You should not set library paths using DYLD_LIBRARY_PATH. As you've discovered, that tends to explode. Executables and libraries should have their library requirements built into them at link time. Use otool -L to find out what the file is looking for:
$ otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO:
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
...
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
For an example of one of my homebrew-built programs:
$ otool -L /usr/local/bin/gifcolor
/usr/local/bin/gifcolor:
/usr/local/Cellar/giflib/4.1.6/lib/libgif.4.dylib (compatibility version 6.0.0, current version 6.6.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
Note that it references /usr/local. If you've built it in such a way that it references the wrong library, I recommend rebuilding and pointing it to the correctly library.
If that's impossible, it is possible to edit what path is used using install_name_tool, but there are cases where this doesn't work, such as if the new path is longer than the old path and you didn't link it with -header_pad_max_install_names. Rebuilding with the correct path is preferred.
Note that there are a few "special" paths available that allow libraries to be found relative to their loader. See #executable_path/ and its kin in the dyld(1) man page.
If using Qt Creator, you have to uncheck the Add build library search path to DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH option from the Run section in the Projects tab:
I had a similar error when trying to run Apache Celix on macOS Sierra
If you use Homebrew to install libjpeg, libtiff, libpng which may confuse the linker to use macOS imageIO library. Simple fix is unlink those libs:
brew unlink libpng
brew unlink libtiff
brew unlink libjpeg
Re-link those libs whenever we need to:
brew link libpng
brew link libtiff
brew link libjpeg
I had a similar error, and i solved putting the following variable in my bash_profile:
export DYLD_LIBRARY_PATH=/usr/lib/:$DYLD_LIBRARY_PATH
I followed the instructions mdemirst suggested and it fixed my issue. I am using OS X Sierra.
I created a gist just in case someone else runs into the same issue.
Gist to fix Spidermonkey errors
svn stopped working in my Mac after upgrade to Yosemite. I know there is a very similar question with no answer,
Segmentation fault: 11 in SVN checkout, however I've spent pretty much the whole day with this and I'm adding more information on the issue. I'm hoping somebody maybe somebody can help... I'm really stuck. I cannot upgrade svn and I'm planning to go back to Mavericks.
The error I get:
svn update
Segmentation fault: 11
I was already working with svn from a binary I compiled myself (although not so familiar with C). There was some months ago an update of Xcode that removed the old legacy svn 1.6.
This time with Yosemite, when I've tried to compile it again, I've seen that the os update has modified apache and APR and the sources do not compile anymore (or at least that's my guess from the error I get):
/bin/sh /mnt/netzima/icaria/apps/subversion-1.6.6/libtool --tag=CC --silent --mode=compile gcc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -O2 -g -O2 -I/usr/include/apache2 -I./subversion/include -I./subversion -I/usr/local/apr/include/apr-1 -I/usr/local/apr-util/include/apr-1 -I/opt/local/include/neon -o subversion/mod_authz_svn/mod_authz_svn.lo -c subversion/mod_authz_svn/mod_authz_svn.c
subversion/mod_authz_svn/mod_authz_svn.c:448:9: error: member reference base type 'char' is not a structure or union
ap_log_rerror(file, line, level, 0, r,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've downloaded and make install the following:
libtool version 2.4.2
autoconf version 2.69
automake version 1.14
apr version 1.3.12
apr-util version 1.3.12
apache version 2.2.29
I was hoping that those versions would be compatible with svn 1.6.6, since, as I've mentioned before, my guess was that it is not compatible anymore to the newest versions.
In other to use those packages that I've downloaded, I had to add options to the configure command. For apr-util, I had to configure like this:
./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr
As for apache:
./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util --prefix=/usr/local/apache2 --enable-dav --enable-so
And finally svn:
./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util --with-apxs=/usr/local/apache2/bin/apxs --enable-maintainer-mode
This way at least svn compiles (I guess that proves it is getting the right versions). But it does not work, I get the same segmentation fault. I've added the /usr/local/... directories to my path just to be sure, although I'd guess svn puts all the library it needs in an accesible directory (I think it is /usr/local/bin, which was already in my path).
I have no idea how to go from here. I've tried to compile with debug to see if I can get a pointer to the segmentation fault, a core dump or something like that, with no success...
Any help would be much appreciated!
And thanks anyway.
EDIT:
Following #indiv advice, this is the output of otool:
/usr/local/bin/svn:
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57031.1.35)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1151.16.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 62.0.0)
/usr/local/lib/libsvn_client-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_wc-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_ra-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_diff-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_ra_local-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_repos-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_fs-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_fs_fs-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_fs_util-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_ra_svn-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libsasl2.2.dylib (compatibility version 3.0.0, current version 3.15.0)
/usr/local/lib/libsvn_ra_neon-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_delta-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libsvn_subr-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
/usr/local/apr-util/lib/libaprutil-1.0.dylib (compatibility version 4.0.0, current version 4.12.0)
/usr/local/apr/lib/libapr-1.0.dylib (compatibility version 4.0.0, current version 4.12.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
/opt/local/lib/libneon.27.dylib (compatibility version 30.0.0, current version 30.6.0)
/opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0)
/opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 6.0.0)
/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.0.0)
You can also download and install the binary from WANDisco:
https://www.wandisco.com/subversion/download/download-certified-wandisco-subversion-binaries?f=subversion/Subversion-Client-1.8.10_10.10.x.pkg
Worked for me.
Finally, it worked! Thanks #indiv for your help! I was about to give up and revert to Mavericks.
I had to compile neon, version 0.29.0.
./configure --prefix=/usr/local/neon --with-ssl
Then I recompiled svn:
./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util --with-apxs=/usr/local/apache2/bin/apxs --enable-debug --enable-maintainer-mode --without-sasl --with-neon=/usr/local/neon --with-ssl
And it works!
I am trying to find the standard C library on Mac OS X. I've tried paths like: "/usr/lib/libc.a" or "/usr/lib/libm.a" , but there aren’t such files on the system. Where can I find it?
Then I used a terminal at a Linux machine and run such a command:
ar t /usr/lib/libc.a
It returns a list of .o files and those .o files are like these:
svc.o
xdr.o
...
What are the meanings of these files? Where can I find them?
The standard library is part of libSystem.dylib on OS X.
It looks like it is
/usr/lib/libSystem.B.dylib
on my machine (Mac OS X v10.6.7 (Snow Leopard)).
You can find out using otool — this is on a Mac running macOS v10.14.2 (Mojave), and the (very simple) program was built using Clang from Xcode:
$ otool -L al
al:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
$ clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Other programs have more libraries. For example, this Tower of Hanoi program was built with a home-built GCC 8.2.0 and the ncurses library:
$ otool -L hanoi
hanoi:
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
/opt/gcc/v8.2.0/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
And another program uses still more:
$ otool -L $(which sqlcmd)
/Users/jonathanleffler/bin/sqlcmd:
/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
isqls09b.dylib (compatibility version 0.0.0, current version 0.0.0)
iasfs09b.dylib (compatibility version 0.0.0, current version 0.0.0)
igens09a.dylib (compatibility version 0.0.0, current version 0.0.0)
iosls09a.dylib (compatibility version 0.0.0, current version 0.0.0)
sobj4/igl4a304.dylib (compatibility version 0.0.0, current version 0.0.0)
sobj4/iglxa304.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
/opt/gcc/v8.2.0/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
And system programs may use other libraries and frameworks:
$ otool -L $(which passwd)
/usr/bin/passwd:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1561.0.0)
/System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libpam.2.dylib (compatibility version 3.0.0, current version 3.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
$ otool -L /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.63.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.51.2)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 888.51.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)
There are many other jobs that can be done with otool — look at the man page.
To answer your second question: static libraries are kept in archive files, hence the .a. As such they are just containers for a bunch of files, just like ZIP, TAR, RAR, etc. minus any compression. Those files listed by the ar (stands for archive) utility are the original files packed into the archive. You could unpack it and get the original files.
Static libraries are in stark contrast to dynamic libraries. A static library's contents are extracted by the linker and included into your program upon linking, as if they were just results of other compilation stages of your program's build process.
Dynamic libraries, on the other hand, are not just archives of object files, but they're linked executables by itself and the dynamic linker maps them into the linking processes address space and adjusts the symbol tables to match the mapped address.
To answer the other half of your question, OS X does not generally use static libraries (.a). As such, there is no libc.a (or libSystem.a) on OS X.
Actually, it did exist at /usr/lib/system/libsystem_c.dylib.
You could verify that with: nm -gU /usr/lib/system/libsystem_c.dylib
The file has been moved/removed since macOS v11 (Big Sur).