I have an osx executable that runs succesfully. When I run
nm mono | grep UNIX
on it, I get these results:
U _accept$UNIX2003
U _bind$UNIX2003
U _closedir$UNIX2003
U _connect$UNIX2003
U _fwrite$UNIX2003
U _getpeername$UNIX2003
U _getsockname$UNIX2003
U _listen$UNIX2003
U _mmap$UNIX2003
U _mprotect$UNIX2003
U _munmap$UNIX2003
U _nanosleep$UNIX2003
U _opendir$UNIX2003
U _pthread_cond_timedwait$UNIX2003
U _pthread_cond_wait$UNIX2003
U _pthread_join$UNIX2003
U _recv$UNIX2003
U _recvfrom$UNIX2003
U _recvmsg$UNIX2003
U _semctl$UNIX2003
U _send$UNIX2003
U _sendmsg$UNIX2003
U _sendto$UNIX2003
U _setenv$UNIX2003
U _strftime$U开发者_StackOverflow中文版NIX2003
U _unsetenv$UNIX2003
Since the app runs succesfully, apparently the OS is able to succesfully resolve these symbols when it loads the application. I am trying to figure out which system library defines these symbols.
One likely suspect is /usr/lib/libSystem.B.dylib, however, when running
nm /usr/lib/libSystem.B.dylib | grep UNIX
there turn out to be no symbols in there with the $UNIX2003 suffix.
I'd like to figure out where these symbols are defined, in relation to a build problem on a seperate program that does not succesfully run, but fails at runtime because it cannot find _opendir$UNIX2003.
See the definite discussion in this apple document, Symbol Variants Release Notes.
All these are defined in /usr/lib/libSystem.B.dylib
. Note that it is a universal dylib
, i.e. contains both 32 bit and 64 bit versions. On your box, you'll see something like
/usr/lib$ nm -arch i386 libSystem.dylib | grep fputs
000c22c0 T _fputs
000328bc T _fputs$UNIX2003
/usr/lib$ nm -arch x86_64 libSystem.dylib | grep fputs
00000000000551cf T _fputs
The point is, there's no non-SUS compliant versions of these functions in the 64 bit variant. So there's no $UNIX2003
variant. I guess your linking problem is due to the supported architecture of your library.
精彩评论