generic-library/openssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Makefile.shared: update link_o.darwin rule [from HEAD].

Browse Source 
PR: 2306
This commit is contained in:
Andy Polyakov 2010-07-16 08:11:43 +00:00
parent 4e2b990734
commit c4488936b2
1 changed files with 19 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Makefile.shared
View File

@ -135,7 +135,7 @@ LINK_SO_A_VIA_O= \
ALL=$$ALLSYMSFLAGS; ALLSYMSFLAGS=; NOALLSYMSFLAGS=; \
( $(SET_X); \
ld $(LDFLAGS) -r -o lib$(LIBNAME).o $$ALL lib$(LIBNAME).a $(LIBEXTRAS) ); \
$(LINK_SO) && rm -f $(LIBNAME).o
$(LINK_SO) && rm -f lib$(LIBNAME).o
LINK_SO_A_UNPACKED= \
UNPACKDIR=link_tmp.$$$$; rm -rf $$UNPACKDIR; mkdir $$UNPACKDIR; \
@ -207,17 +207,29 @@ link_app.bsd:
fi; $(LINK_APP)
# For Darwin AKA Mac OS/X (dyld)
# link_o.darwin produces .so, because we let it use dso_dlfcn module,
# which has .so extension hard-coded. One can argue that one should
# develop special dso module for MacOS X. At least manual encourages
# to use native NSModule(3) API and refers to dlfcn as termporary hack.
# Originally link_o.darwin produced .so, because it was hard-coded
# in dso_dlfcn module. At later point dso_dlfcn switched to .dylib
# extension in order to allow for run-time linking with vendor-
# supplied shared libraries such as libz, so that link_o.darwin had
# to be harmonized with it. This caused minor controversy, because
# it was believed that dlopen can't be used to dynamically load
# .dylib-s, only so called bundle modules (ones linked with -bundle
# flag). The belief seems to be originating from pre-10.4 release,
# where dlfcn functionality was emulated by dlcompat add-on. In
# 10.4 dlopen was rewritten as native part of dyld and is documented
# to be capable of loading both dynamic libraries and bundles. In
# order to provide compatibility with pre-10.4 dlopen, modules are
# linked with -bundle flag, which makes .dylib extension misleading.
# It works, because dlopen is [and always was] extension-agnostic.
# Alternative to this heuristic approach is to develop specific
# MacOS X dso module relying on whichever "native" dyld interface.
link_o.darwin:
@ $(CALC_VERSIONS); \
SHLIB=lib$(LIBNAME); \
SHLIB_SUFFIX=.so; \
SHLIB_SUFFIX=.dylib; \
ALLSYMSFLAGS='-all_load'; \
NOALLSYMSFLAGS=''; \
SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS)"; \
SHAREDFLAGS="$(CFLAGS) `echo $(SHARED_LDFLAGS) | sed s/dynamiclib/bundle/"; \
if [ -n "$(LIBVERSION)" ]; then \
SHAREDFLAGS="$$SHAREDFLAGS -current_version $(LIBVERSION)"; \
fi; \