OS X is based on a BSD derivative, Darwin, which does not typically use GNU libc. So my expectation is that the answer is "no". That the _gethostbyname_r
function, defined by glibc, is not available on OS X reinforces this hunch.
Let's see if some basic inspection of the library can help.
On a CentOS host:
$ strings /lib64/libc.so.6 | grep -i gnu
gnu_dev_makedev
gnu_get_libc_release
gnu_get_libc_version
gnu_dev_minor
gnu_dev_major
GNU C Library stable release version 2.12, by Roland McGrath et al.
Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-4).
GNU Libidn by Simon Josefsson
<http://www.gnu.org/software/libc/bugs.html>.
yet on a mac:
# otool -L /usr/bin/gm4
/usr/bin/gm4:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
# otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/system/libcache.dylib (compatibility version 1.0.0, current version 47.0.0)
/usr/lib/system/libcommonCrypto.dylib (compatibility version 1.0.0, current version 55010.0.0)
/usr/lib/system/libcompiler_rt.dylib (compatibility version 1.0.0, current version 6.0.0)
/usr/lib/system/libcopyfile.dylib (compatibility version 1.0.0, current version 85.1.0)
/usr/lib/system/libdispatch.dylib (compatibility version 1.0.0, current version 187.7.0)
/usr/lib/system/libdnsinfo.dylib (compatibility version 1.0.0, current version 395.7.0)
/usr/lib/system/libdyld.dylib (compatibility version 1.0.0, current version 195.5.0)
/usr/lib/system/libkeymgr.dylib (compatibility version 1.0.0, current version 23.0.0)
/usr/lib/system/liblaunch.dylib (compatibility version 1.0.0, current version 392.35.0)
/usr/lib/system/libmacho.dylib (compatibility version 1.0.0, current version 800.0.0)
/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 2026.0.0)
/usr/lib/system/libquarantine.dylib (compatibility version 1.0.0, current version 36.0.0)
/usr/lib/system/libremovefile.dylib (compatibility version 1.0.0, current version 21.0.0)
/usr/lib/system/libsystem_blocks.dylib (compatibility version 1.0.0, current version 53.0.0)
/usr/lib/system/libsystem_c.dylib (compatibility version 1.0.0, current version 763.12.0)
/usr/lib/system/libsystem_dnssd.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/system/libsystem_info.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/system/libsystem_kernel.dylib (compatibility version 1.0.0, current version 1699.24.8)
/usr/lib/system/libsystem_network.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/system/libsystem_notify.dylib (compatibility version 1.0.0, current version 80.1.0)
/usr/lib/system/libsystem_sandbox.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/system/libunc.dylib (compatibility version 1.0.0, current version 24.0.0)
/usr/lib/system/libunwind.dylib (compatibility version 1.0.0, current version 30.0.0)
/usr/lib/system/libxpc.dylib (compatibility version 1.0.0, current version 77.17.0)
# strings /usr/lib/libSystem.B.dylib | grep -i gnu
libsystem_c looks suspicious there, but let's check everything.
# for dl in /usr/lib/system/lib*.dylib; do echo $dl; strings $dl | grep -i gnu; done
...trimmed...
/usr/lib/system/libunwind.dylib
malformed DW_CFA_GNU_negative_offset_extended dwarf unwind, reg too big
...trimmed...
I started with gm4
since it's a GNU tool, and used otool
to trace down its library dependencies.
So I think the answer is a fairly safe "no" as far as the Apple-supplied system goes. As the question states, it's certainly possible to install glibc with third-party tools (although port search glibc
doesn't find anything - note that glib
is totally NOT the same as glibc
).