Hello, I am wondering how to link a package with some dynamic libraries in a way that works with ghci. If I run the command LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 ghci -package mypackage then it is successful; I am able to use package mypackage in ghci. But if I omit the LD_PRELOAD=... part then ghci complains about missing symbols. How do I configure my package so that the LD_PRELOAD=... part of the command is not necessary? Thanks, Frederik
Frederik Eaton wrote:
Hello,
I am wondering how to link a package with some dynamic libraries in a way that works with ghci. If I run the command
LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 ghci -package mypackage
then it is successful; I am able to use package mypackage in ghci. But if I omit the LD_PRELOAD=... part then ghci complains about missing symbols. How do I configure my package so that the LD_PRELOAD=... part of the command is not necessary?
I believe you should be able to use extra-libraries in the .cabal file to get these libraries loaded. Cheers, Simon
On Fri, Apr 27, 2007 at 11:01:49AM +0100, Simon Marlow wrote:
Frederik Eaton wrote:
Hello, I am wondering how to link a package with some dynamic libraries in a way that works with ghci. If I run the command LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 ghci -package mypackage then it is successful; I am able to use package mypackage in ghci. But if I omit the LD_PRELOAD=... part then ghci complains about missing symbols. How do I configure my package so that the LD_PRELOAD=... part of the command is not necessary?
I believe you should be able to use extra-libraries in the .cabal file to get these libraries loaded.
Cheers, Simon
Hello, I have been doing that, $ ghc-pkg describe vectro ... extra-libraries: gsl cblas atlas lapack stdc++ ... I think the problem is that there is a /usr/lib/libstdc++.so.5 and a /usr/lib/libstdc++.so.6 but no /usr/lib/libstdc++.so; when I created the latter, linking to the libstdc++.so.6 link, I was able to use ghci with my package. I wish I knew why /usr/lib/libstdc++.so is missing, but it is missing on 4 out of 4 of the computers I just now checked so I think it is normal for it to be missing, and the problem probably lies with ghci? (by the way, in contrast to stdc++, the links /usr/lib/lib{gsl,cblas,atlas,lapack}.so all exist) Thanks, Frederik -- http://ofb.net/~frederik/
On Wed, 2007-05-09 at 23:44 +0100, Frederik Eaton wrote:
I think the problem is that there is a /usr/lib/libstdc++.so.5 and a /usr/lib/libstdc++.so.6 but no /usr/lib/libstdc++.so; when I created the latter, linking to the libstdc++.so.6 link, I was able to use ghci with my package. I wish I knew why /usr/lib/libstdc++.so is missing, but it is missing on 4 out of 4 of the computers I just now checked so I think it is normal for it to be missing, and the problem probably lies with ghci?
Libraries are utterly incompatible: they use a different Application Binary Interface (ABI). The ABI changed around starting gcc 3.4 I think. Examining a binary on my amd64 Ubuntu/Linux box: skaller@rosella:/work/felix/svn/felix/felix/trunk$ ldd bin/flx_run libflx_pthread_dynamic.so => not found libflx_dynamic.so => not found libflx_gc_dynamic.so => not found libdl.so.2 => /lib/libdl.so.2 (0x00002b7ba1854000) libpthread.so.0 => /lib/libpthread.so.0 (0x00002b7ba1a59000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002b7ba1c74000) libm.so.6 => /lib/libm.so.6 (0x00002b7ba1f78000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b7ba21fb000) libc.so.6 => /lib/libc.so.6 (0x00002b7ba2409000) /lib64/ld-linux-x86-64.so.2 (0x00002b7ba1637000) you can see: * my application libs are not found (LD_LIBRARY_PATH not set) * compiler libraries use *.so.integer links * core libs use *.so.integer links * the dynamic loader is hard coded skaller@rosella:/work/felix/svn/felix/felix/trunk$ ls /usr/lib/libstd* /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6 /usr/lib/libstdc++.so.5.0.7 /usr/lib/libstdc++.so.6.0.8 skaller@rosella:/work/felix/svn/felix/felix/trunk$ ls -l /usr/lib/libdl* -rw-r--r-- 1 root root 13162 2007-04-04 21:06 /usr/lib/libdl.a lrwxrwxrwx 1 root root 15 2007-04-20 03:20 /usr/lib/libdl.so -> /lib/libdl.so.2 Note here the '/usr/lib/libdl.so' links to '/lib/libdl.so.2': it's a core lib, not a compiler lib. Finally see: skaller@rosella:/work/felix/svn/felix/felix/trunk$ ls -l /usr/lib/gcc/x86_64-linux-gnu/4.1.2/libstdc++* /lib/gcc/x86_64-linux-gnu/4.1.2/libstdc++.so -> ../../../libstdc++.so.6 so the link 'libstdc++.so' does exist .. but it is in a compiler specific location. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
participants (3)
-
Frederik Eaton -
Simon Marlow -
skaller