Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenHarmony
Third Party Openssl
提交
cad6650f
T
Third Party Openssl
项目概览
OpenHarmony
/
Third Party Openssl
大约 1 年 前同步成功
通知
9
Star
18
Fork
1
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
T
Third Party Openssl
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
cad6650f
编写于
7月 15, 2010
作者:
A
Andy Polyakov
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Makefile.shared: update link_o.dawrin rule.
PR: 2306
上级
26064d7f
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
18 addition
and
8 deletion
+18
-8
Makefile.shared
Makefile.shared
+18
-8
未找到文件。
Makefile.shared
浏览文件 @
cad6650f
...
...
@@ -70,7 +70,7 @@ LIBDEPS=
# The rest is private to this makefile.
SET_X
=
:
#
SET_X=set -x
SET_X
=
set
-x
top
:
echo
"Trying to use this makefile interactively? Don't."
...
...
@@ -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,27 @@ 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.
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;
\
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录