我有以下情况：
GHC bug＃9010 使得使用GHC 7.6安装库B成为不可能。当处理TH时，GHCi启动并尝试加载库X，该库失败，并显示消息，如
加载包charsetdetect-ae -1.0 ...链接... ghc：〜/ .cabal / lib / x86_64-linux-ghc-7.6.3 / charsetdetect-ae-1.0 / libHScharsetdetect-ae-1.0.a：未知符号`_ZTV15nsCharSetProber'（机器之间的未知符号的实际名称不同） 。
这个问题有什么解决方法吗（除了不要使用模板哈斯克尔，当然）？也许库X需要以不同的方式编译，或者有一些方法可以阻止它加载（因为它不应该在代码生成过程中调用）？
解决方案这实际上是7.8默认切换到动态GHCi的主要原因之一。而不是试图支持每个对象文件格式的每个功能，它建立动态库，并让系统动态加载器处理它们。
尝试使用g ++选项 -fno弱。从g ++手册页：
-fno-weak
不要使用弱符号支持，即使它是由链接器提供的。默认情况下，如果可用，G ++将使用弱符号。此选项仅用于测试，不应由最终用户使用;它会导致代码较差并且没有好处。这个选项可能在未来的G ++版本中被删除。
__ dso_handle 还有另一个问题。我发现你至少可以加载库，并且显然通过链接定义该符号的文件来工作。我不知道这个黑客是否会导致任何问题。
所以在X.cabal中添加
<$如果impl（ghc <7.8） cc-option：-fno-weak c-sources：cbits / dso_handle.cc $ c>
其中 cbits / dso_handle.c 包含
void * __ dso_handle;
I've got the following situation:
- Library X is a wrapper over some code in C.
- Library A depends on library X.
- Library B uses Template Haskell and depends on library A.
GHC bug #9010 makes it impossible to install library B using GHC 7.6. When TH is processed, GHCi fires up and tries to load library X, which fails with a message like
Loading package charsetdetect-ae-1.0 ... linking ... ghc: ~/.cabal/lib/x86_64-linux-ghc-7.6.3/charsetdetect-ae-1.0/ libHScharsetdetect-ae-1.0.a: unknown symbol `_ZTV15nsCharSetProber'(the actual name of the "unknown symbol" differs from machine to machine).
Are there any workarounds for this problem (apart from "don't use Template Haskell", of course)? Maybe library X has to be compiled differently, or there's some way to stop it from loading (as it shouldn't be called during code generation anyway)?
解决方案This is really one of the main reasons that 7.8 switched to dynamic GHCi by default. Rather than try to support every feature of every object file format, it builds dynamic libraries and lets the system dynamic loader handle them.
Try building with the g++ option -fno-weak. From the g++ man page:
-fno-weak
Do not use weak symbol support, even if it is provided by the linker. By default, G++ will use weak symbols if they are available. This option exists only for testing, and should not be used by end-users; it will result in inferior code and has no benefits. This option may be removed in a future release of G++.
There is another issue with __dso_handle. I found that you can at least get the library to load and apparently work by linking in a file which defines that symbol. I don't know whether this hack will cause anything to go wrong.
So in X.cabal add
if impl(ghc < 7.8) cc-option: -fno-weak c-sources: cbits/dso_handle.cwhere cbits/dso_handle.c contains
void *__dso_handle;
更多推荐
“模板Haskell + C”错误的解决方法？
发布评论