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).
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).
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..
Unfortunately apple has not included header files for libicucore on OSX. Is there any way I can nevertheless use this library? I only need some simple functionality and ICU is too big to bundle with my app. It looks like ICU version 53.1.0 which is fairly recent:
jeroen$ otool -L /usr/lib/libicucore.dylib
libicucore.dylib:
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 53.1.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
What complicates things is that I have a hard time finding out what is included with the core target of ICU. I can use nm to manually check if a particular symbol is present in the library:
jeroen$ nm /usr/lib/libicucore.dylib | grep ToUpper
00000000000b74c9 T _u_strToUpper
000000000006ff70 T _ucasemap_utf8ToUpper
Now I can manually grab the headers for u_strToUpper from the 53.1.0 release of ICU, but that is a lot of work. Is there a better way to find or generate the headers for ICU core 53.1.0 on OSX?
You can download header files from Apple's or ICU's official websites and link against the system's libicucore library. But you can't upload a product to App Store or Mac App Store. It will be immediately rejected as one that uses private API. iTunes Connect has an automatic script that detects such references after you upload a new binary.
It looks like my best bet is grabbing the headers from the apple website. This repository also includes the makefile for libicucore.dylib which uses --with-data-packaging=archive to put the ICU data tables in a standalone file /usr/share/icu/icudt51l.dat.
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 want to link libstdc++ statically on Mac OS X 10.8.4 so that the binary can be used in other systems.
I found some discussion for linux. I'm wondering what would the instructions for Mac OS X.
http://www.trilithium.com/johan/2005/06/static-libstdc/
I have the following GCC.
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I don't know if the gcc 4.2.1 that you have supports this method, but here's what worked for me in a similar situation on OS X 10.9:
upgrade to the latest Xcode command line tools (I have 5.0.1.0.1.1382131676)
install Homebrew
brew tap versions
brew install gcc48
then configure/build your software with:
CC=gcc-4.8 CXX=g++-4.8 LDFLAGS="-static-libgcc -static-libstdc++"
The static flags were available for me in this gcc 4.8 build by Homebrew, and the resulting executables looked like:
$ otool -L seqdb-compress
seqdb-compress:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
with no libgcc or libstdc++ dynamic libs. I haven't yet tested these executables out on a different OS X system but will update this post if they don't work for any reason.