无法创建适用于 OS X 10.5 的发行版 dylib(在 10.6 环境中构建)
我正在尝试使用我的应用程序分发 cairo (1.10.2)。我可以使用 Homebrew 创建必要的 dylib,但它们依赖于 OS X 10.5 中不存在的其他动态库的版本(libfontconfig、libfreetype 以及主要位于 /usr/X11/lib
中的其他动态库) )。
我假设要解决这个问题,我希望它使用 /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib
中的 dylib,而不是 /usr/X11/ 中的库库
。我已经尝试了所有我能找到的针对 10.5 SDK 的目标 cairo 的方法。
- 将
MACOSX_DEPLOYMENT_TARGET
环境变量设置为10.5
(在调用brew
或使用 Homebrew 的ENV
之前) - 设置
SDKROOT
code> 环境变量为“/Developer/SDKs/MacOSX10.5.sdk”(在调用brew
或使用 Homebrew 之前ENV
) - 将
-mmacosx-version-min=10.5
添加到CFLAGS
、CXXFLAGS
和LDFLAGS
在 cairo 的 Homebrew 公式中。 - 将
-sysroot
/-isysroot /Developer/SDKs/MacOSX10.5.sdk
添加到CFLAGS
、CXXFLAGS
、和 cairo 的 Homebrew 公式中的LDFLAGS
。 - 将
-I$(SDKROOT)/usr/X11/include
和-I$(SDKROOT)/usr/X11R6/include
添加到CFLAGS
和 cairo 的 Homebrew 公式中的CXXFLAGS
。 - 将
-L$(SDKROOT)/usr/X11/lib
和-L$(SDKROOT)/usr/X11R6/lib
添加到LDFLAGS
在开罗的 Homebrew 公式中。
在构建 cairo 时,它在 gcc 命令上有 -I/usr/X11/lib
(我的选项附加在最后),所以我想它首先会遇到这个问题。我不知道如何摆脱它,所以它使用我的选择。我认为 isysroot
可以做到这一点,因此包含路径和库路径在 SDK 中重新建立,但 -isysroot
似乎没有任何效果。
I'm trying to distribute cairo (1.10.2) with my application. I can create the necessarily dylibs using Homebrew but they are dependent on versions of other dynamic libraries that aren't present in OS X 10.5 (libfontconfig, libfreetype, and others located primarily in /usr/X11/lib
).
I assume to solve this I want it to be using the dylibs in /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib
rather than the libraries in /usr/X11/lib
. I've tried anything I could find for targeting cairo against the 10.5 SDK.
- Setting
MACOSX_DEPLOYMENT_TARGET
environment variable to10.5
(before callingbrew
or using Homebrew'sENV
) - Setting
SDKROOT
environment variable to "/Developer/SDKs/MacOSX10.5.sdk" (before callingbrew
or using Homebrew'sENV
) - Adding
-mmacosx-version-min=10.5
to theCFLAGS
,CXXFLAGS
, andLDFLAGS
in the Homebrew formula for cairo. - Adding
-sysroot
/-isysroot /Developer/SDKs/MacOSX10.5.sdk
to theCFLAGS
,CXXFLAGS
, andLDFLAGS
in the Homebrew formula for cairo. - Adding
-I$(SDKROOT)/usr/X11/include
and-I$(SDKROOT)/usr/X11R6/include
to theCFLAGS
andCXXFLAGS
in the Homebrew formula for cairo. - Adding
-L$(SDKROOT)/usr/X11/lib
and-L$(SDKROOT)/usr/X11R6/lib
to theLDFLAGS
in the Homebrew formula for cairo.
While building cairo it has -I/usr/X11/lib
on the gcc commands (with my options tacked on the end) so I imagine it's hitting that first. I'm not sure how to get rid of that so it uses my options. I thought isysroot
would make it so the include and library paths were rerooted in the SDK but -isysroot
doesn't seem to have any effect.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您应该能够使用
install_name_tool
更改 cairo 查找其库的位置。 (我不知道 cairo 是什么。我假设它是一个 dylib。如果不是,我对这个解决方案的信心会大大下降。)这是一个虚构的示例,您应该能够适应。
首先,使用
otool -L
查看 cairo 正在使用哪些库。在此示例中,我使用 libopencv_imgproc.2.3.1.dylib,但您将使用 cairo 库的文件名:然后使用
install_name_tool -change
更改您需要更改的路径。第一个参数是当前的库路径,第二个是所需的库路径,第三个是库文件。我告诉它在/Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/
而不是中查找
:libz.1.dylib
/usr/lib对需要更改路径的每个库重复此操作。
otool -L
向我们展示了所做的更改:在我的示例中(也许在您的应用程序中),我的库希望在我的应用程序包之外的其他位置找到自己,因此我也需要更改它
安装名称工具-id
。我将该库复制到应用程序包的 Frameworks 文件夹中,因此我告诉它在那里查看:您可以将
install_name_tool
调用放入运行脚本构建阶段。如果您要将库复制到应用程序包的 Frameworks 文件夹中,则应在库名称前面添加$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/
以确保脚本可以找到该库。You should be able to use
install_name_tool
to change where cairo looks for its libraries. (I have no idea what cairo is. I'm assuming it's a dylib. If not, my confidence in this solution goes down considerably.)Here's a made-up example that you should be able to adapt.
First, use
otool -L
to see which libraries cairo is using. In this example I'm working with libopencv_imgproc.2.3.1.dylib, but you'll use your cairo library's file name instead:Then use
install_name_tool -change
to change whichever paths you need to change. The first parameter is the current library path, the second is the desired library path, and the third is the library file. I'm telling it to look forlibz.1.dylib
in/Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/
instead of/usr/lib
:Repeat this for every library whose path you need to change.
otool -L
shows us that the change was made:In my example (and perhaps in your application) my library expects to find itself somewhere other than my application bundle, so I need to change that as well with
install_name_tool -id
. I'm copying the library to my application bundle's Frameworks folder so I'm telling it to look there:You can put the
install_name_tool
invocations in a Run Script build phase. If you are copying the library into your application bundle's Frameworks folder, you should prepend the library name with$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/
to ensure that the script can find the library.