Replies: 5 comments 32 replies
-
|
[Chinese translation on original question]
|
Beta Was this translation helpful? Give feedback.
-
|
远程连到家里的机器尝试了，看起来 add_requireconfs 不起作用。修改: fuzhouch/hashbld@main...debug-libsndio-linkstatic |
Beta Was this translation helpful? Give feedback.
-
|
这种交叉编译的场景，貌似用 package.install_only 更合适，试试 set_policy("package.install_only", true) |
Beta Was this translation helpful? Give feedback.
-
|
感谢！但看起来也没有效果。在 target 之下增加了 set_policy("package.install_only", true) 之后，最终的编译选项并没有 -L 增加到 ~/.xmake/packages/a/alsa-lib/ 的路径，所以得到的 openal.hdll 依赖的仍然会有到 libasound.so 和 libatopology.so 的动态链接。作为辅助验证，libsndio.so 也有到 libasound.so 和 libatopology.so 的链接，也就是说，alsa-lib 仍然是动态链接的。 您前面说过「 xmake 包在非 Windows 平台默认先用系统库」，如果是默认先用系统库，那么有没有什么办法强制要求必须自己编译 alsa-lib？从文档上说似乎 set_requireconfs() 确实像是应该做这件事的正确 API ，但实际效果是没有做——因为加或不加这一行，xmake config 里都会报 我是不是漏掉了什么步骤？ fuzhouch@fcdvh01 ~/p/g/h/p/lib (main)> readelf -a -W libsndio.so |grep NEEDED |
Beta Was this translation helpful? Give feedback.
-
|
ps, 我在尝试着这么写，看看有没有效果。稍晚点回复。 |
Beta Was this translation helpful? Give feedback.
-
|
@waruqi 为啥这里没有效果 |
Beta Was this translation helpful? Give feedback.
-
既然你的依赖链是这个，那么你 hashlink/xmake.lua 里面，就没必要写全所有，只需要
这不是坑，是你用的不对，不管怎样，始终只需要一个 add_requires("openal-soft 1.23.1")
add_requires("openal-soft.libsndio", {system = false, override = true})
add_requires("openal-soft.libsndio.alsa-lib", {system = false, override = true})
target("hashlink")
add_packages("openal-soft")
要从根路径开始，也就是 如果还是没生效。你也可以递归匹配，改写所有。。 add_requires("openal-soft.**", {system = false, override = true})另外，你改
如果你非要用 libsdnio 静态库，只有提 pr 到 xmake-repo ，将 libsndio 支持静态库，去掉 readonly shared 的配置，当然前提是 所有 ci 都得通过，并且解决掉之前遇到的所有静态库编译失败问题或者其他问题。 只要这个包支持了静态库，你用户端，add_requires 啥也不用改，默认用的就是静态库了 |
Beta Was this translation helpful? Give feedback.
-
对，我知道现在这个做法有问题。这么写是两个目的：
所以我才发现我好像没有办法控制依赖库的编译选项。特别是动态库。如果这样，依赖库的依赖库使用编译选项是怎么确定的呢？似乎 add_deps() 感觉总是会去找系统的库，不管 xrepo cache 里有没有。而我肯定是想优先要 xrepo cache 的版本。我的观察是对的么？其实就是前面我问的，为什么我都在自己的 xmake.lua 里指定了 alsa-lib，但实际编译过程仍然找了系统的 pacman::alsa-lib？ @waruqi 关于另外两个问题，稍微解释一下：
|
Beta Was this translation helpful? Give feedback.
-
|
对了，顺便也解释一下我的场景，这样大家能理解我为什么有这么严格的要求：
所以，我非常需要有控制依赖库编译选项的能力，包括依赖库的依赖库来自哪里，以及他们的编译选项。 顺便说一句，我已经在 star-hengxing 的建议下自己写包了，应该可以解决 openal-soft 的编译问题。 |
Beta Was this translation helpful? Give feedback.
-
理论上 xmake install 会 install 所有依赖的 so ，如果没有，应该是 bug ，你应该提 issues 等待修复
如果 openal-soft 真的依赖了 libasound.so 和 libatopology.so，那么这个 link 还是要加的，即使你上层代码没直接调用这两个库接口，但是你调用了 openal-soft 的接口，而它的接口内部实现 可能需要加载使用这两个 so 的部分接口，你不安装它们，一样运行不起来，或者运行到一半出错。。 除非是，你调用的 openal-soft 的那部分接口内部，也完全没有用到 libasound.so 和 libatopology.so , 这种情况下，应该是 改 openal-soft ，加配置禁用 alsa-lib 依赖。。比如 add_configs("no-alsa-lib") 等待，编译出一个完全不依赖 alsa-lib 的 openal-soft 去使用 还有一种情况就是 openal-soft 你用了 so ，而 alsa-lib 用了 static ，那么最终只需要到 openal-soft.so 那一层。 |
Beta Was this translation helpful? Give feedback.
-
这个我刚说了，就是通过 add_requireconfs 控制，动态库不行，是因为你控制的那两个库，正好是 xmake-repo 包里面被禁用了 动态库，不代表其他库不行。。你得改进包本身。。
这个你自己随意，但是如果这个库目前是被禁用 shared 的，你加上 |
Beta Was this translation helpful? Give feedback.
-
|
我想您应该是理解反了。这里所有的库都没有被禁用动态库。openal-soft 和 alsa-lib 都是静态和动态库都可以编译。sndio 是被禁用了静态库（shared = true 且 readonly），我的代码里写的也是 shared = true，三个参数我都没有写错。参考下面这个链接： |
Beta Was this translation helpful? Give feedback.
-
这个理解是不对的。但这样吧，给我点时间做一个可以复现的最小例子，干说不直观。但我也把解释放在下面： 首先，我的 hashlink （上层代码）只调用 openal-soft 接口但不调用 libsndio 和 alsa-lib（这个看代码 就可以验证），那么 hashlink 编译自己不需要 -lsndio -lasound -latopology。共享库自己有自己的 ELF 头管理二级依赖库，不需要顶层的 exe 再 -l 一遍二级依赖。静态库的规则则不同，因为静态库只是打包，需要顶层 exe 的 ELF 头管理依赖。所以对于我自己的 exe 依赖于一级共享库，我的需求是：1 按依赖链条安装二级库，2. 不需要顶层 -l 二级库。而现在观察到的现象是是 1. xmake install 没有按照依赖传递关系安装二级库，且 2. 编译 hashlink 模块的时候把二级库的 -l 全都带上了。按照咱们讨论到现在的结果，这两个行为应该都不正确。 第二，这四个库都是单线依赖。验证这个不需要看 openal-soft 内部有没有调用 alsa-ib，看 xrepo 的配置就知道：openal-soft 和 libsndio ，openal-soft 只依赖 libsndio，libsndio 只依赖 alsa-lib。所以不需要修改 openal-soft 禁用 alsa-lib 依赖，它本来就不存在。 |
Beta Was this translation helpful? Give feedback.
-
我知道，但是这不还是 openal-soft 依赖了 libsndio 库，libsndio 还是依赖了 alsa-lib 等库，仅仅只是不显式加 -l 了，elf 里面的加载依赖还是存在。。 这些库 install 安装时候，还是需要一起被 copy 过去。。 我理解你的意思，是想 hashlink elf 里面不想直接加上这些 so，但是首先这些依赖 so 总归还是要跟随 openal-soft 一起同时被安装的。
即使不加 -l，这些依赖关系还是存在每个 so 的 elf 里面，当 hashlink 安装到客户机, 如果不拷贝 alsa-lib 那两个so，你 hashlink 调用了 openal-soft 的接口，openal-soft 里面调用了 libsndio 的接口，libsndio 里面又用到了 alsa-lib 的接口，没 asal-lib ，不也会执行失败？ |
Beta Was this translation helpful? Give feedback.
-
|
另外， 如果你只想一刀切，全部包都完全不走系统查找。那么你可以全局配置 set_policy("package.install_only", true)记住是全局域配置，不要放到 target 域下面，它会禁用所有包和依赖包的系统库优先使用策略，总是从 xmake-repo 仓库下载安装。 如果这两种都没生效，你应该提 issues 报障，并提供可复现例子。 |
Beta Was this translation helpful? Give feedback.
-
|
加了，看起来编译成功，有 install ok，但随后随后出发了一个奇怪的 xmake 内部错误。 我把项目最小化再报 issue 吧，也方便大家调试。 |
Beta Was this translation helpful? Give feedback.
-
|
这个应该是 install_only 那个 policy 的 bug 建议你把目前遇到的所有问题，单独拆分后，单独提到 issues 上去，我会挨个解决，不要多个问题在 discussions 混一起讨论 目前这个编译问题我可以复现，开个 issues ，后面也方便单独跟进 |
Beta Was this translation helpful? Give feedback.
-
|
package.install_only 这个问题 我改进了下，可以再试试，切到 dev 版本。。 |
Beta Was this translation helpful? Give feedback.
-
|
没错。我原来也以为就是单个问题，也没想到会发掘出这么多问题（哈哈哈）。这样吧，我下午得出门，晚上我整理一下开几个 issue，同时我开一个repo，把我遇到的几个问题分几个小项目，方面大家理解。最近我跟 Godot 团队也是这么合作的，能省他们不少时间。 |
Beta Was this translation helpful? Give feedback.
-
|
ps 有改进我直接更新 xmake 就好了，我的 xmake 都是手动编译的，紧跟 master 哈哈。 |
Beta Was this translation helpful? Give feedback.
-
如果上游不积极处理的情况下，一种方案是 自己通过 add_patches 强行让这个包支持静态库。。 但如果这个工作量大，可以换另外一种方案，那就是 port 到 xmake.lua 去编译 libsnd 。。我看这个包的源码接口就那么几个 .c 文件。。即使 不走 autoconf ，port 到 xmake.lua 编译，预计工作量也就一两个小时的时间。反而更省事 可以参考其他一些 port 到 xmake.lua 的包 简单的直接写 on_install 里： https://github.com/xmake-io/xmake-repo/blob/dev/packages/l/libspng/xmake.lua 稍微复杂点的，单独 xmake.lua 文件：https://github.com/xmake-io/xmake-repo/pull/2899/files |
Beta Was this translation helpful? Give feedback.
-
|
那可以参考我刚那个 makefile 的改动，你可以提个 pr 到上游去支持，这当然是最好的方式，不过就是周期会比较长。。 通常这边的推荐方案是：1. 先提 pr 到 xmake-repo 通过 patches 的方式强行支持上，至少当前可用，不影响进度 2. 然后 慢慢的去同步上游，如果上游接受了 patches，那么等到下次 release 就可以更新到 xmake-repo 里面了，加个新版本。 |
Beta Was this translation helpful? Give feedback.
-
|
其实已经不影响了。感谢感谢。我现在的做法和那个 Makefile 的改动很接近，但我选择增加一个 libsndio-static.a，这样确保编译出来的其他工具动态链接关系还是一样的，如果有人用 xmake 下载 sndio 的工具比如 midicat，行为上是准确的。上游那边我发信去问了，只是没有回音。我倒不担心别人也想要这个功能，因为这个需求确实是小众，否则很多人应该早就来问了。相反地我更愿意先把上游清理干净，不要让 xrepo 塞进太多上游最后决定不接受的补丁，免得后面改来改去的。 咱们在动态库那边讨论的是另一组问题，我来做一个例子吧，不用着急。 |
Beta Was this translation helpful? Give feedback.
-
|
另外，我刚刚看了您对 libsndio 的改动（不好意思今天在外面办事，很晚才到家，回复晚了）。虽然我没有各个系统都试过，但您这个解法是有一些问题的。 sndio 在各个系统默认依赖的底层库都不一样。Linux 是 alsa-lib，而据我所知 NetBSD OpenBSD 经常用的是 oss 或者 sun audio，所以 libsndio 会根据 -DUSE_OSS 或者 -DUSE_ALSA 整块地切换代码，而且一个 build 只支持一个后端（参见 sio.c，换句话说，其实 sndio 自己的 Makefile.in 默认 LDADD=-lrt -lasound 就是错的，它真正依赖的库没有写全。您的改动 估计是参考了它的 Makefile.in 所以 on_install 里直接对 linux bsd 和 mac 设定依赖 alsa-lib，但这个改动如果有 BSD 的用户来安装，多半不是他们想要的结果。 我没有这个问题，是因为我的 hashlink 直接依赖的是 openal-soft，它只在 linux 上才依赖 sndio，比如 mac 依赖的就是 CoreAudio Framework 了。所以我才说先不着急改，毕竟我不是音频的开发专家，怕引入一些我们都不能预料的问题。 |
Beta Was this translation helpful? Give feedback.
-
|
你可以在提个 pr 过来进一步改进那个包去更好地支持不同平台，或者等待上游的改进 |
Beta Was this translation helpful? Give feedback.
-
|
对，我还在等 sndio 邮件列表上的回复，有点麻烦，那帮人确实很慢。再等几天，实在不行就自己改。这两天要跟踪的包问题有点多，不好意思。 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Operating System and Tool info
Manjaro Linux Unstable branch
Xmake：v2.8.5+master.f205de61c （Build by myself）
Scenario
My project tries to build a game VM against static libraries, with a purpose to make build binary useable on any Linux distro. The audio part has a dependency chain like below:
I know libsndio has no static library support yet (see their issue). However, I'm thinking whether it's possible I still set OpenAL and alsa-lib as static. So I set dependencies below: (Full version):
The problem
When building my project, I noticed xmake always ignore xmake::alsa-lib but uses OS provided alsa-lib,
pacman::alsa-lib. Meanwhile the final link command line still link to-lasoundand-latopology. So the built binary depends on OS-provided libasound.so and libatopology.so. This is not what I want.I tried to specifically add_packages("xmake::alsa-lib") or run "xrepo install alsa-lib", the behavior does not change.
Besides, no matter I use
add_packages("openal", "libsndio", "alsa-lib")oradd_packages("openal"), the final link command always has alsa-lib linking:-lasound -l atopology. This is the direct cause that my built binary link to system providedpacman::alsa-lib. Seems no way to disable.Questions to clarify:
-lasound -latopologyin final link command?Btw, the current settings in my project compile all three libraries in shared libraries. Then the behavior is correct.
Beta Was this translation helpful? Give feedback.
All reactions