Request for help: Recompile of ghc producing "...-ghc7.4.2.so"s, which break project builds.
Recently, I had to recompile ghc, in order to get the "-dyn" versions of the standard libraries installed. (The standard Ubuntu 12.10 64-bit Linux distribution doesn't include them in its "haskell-platform" package, and you can't upgrade "base" using the normal "cabal iinstall" approach, from what I understand.) When I did this, the "-dyn" versions of the standard libraries were, in fact, installed. However, they were given names with a "-ghc7.4.2.so" suffix. And this is causing the build of a previously working project to break, thusly: ghc -o libami.so -shared -dynamic -package parsec *-lHSrts* -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o /usr/bin/ld: /usr/lib/ghc-7.4.2/*libHSrts.a*(RtsAPI.o): relocation R_X86_64_32S against `ghczmprim_GHCziTypes_Czh_con_info' can not be used when making a shared object; recompile with -fPIC The problem is this: the linker is picking up the "*.a" version of the * HSrts* library, instead of the "*.so" version, which is what it really needs. And the reason it's doing this is the "*.so" version has been given a "-ghc7.4.2" suffix: dbanas@dbanas-lap:~/prj/AMI-Tool$ l /usr/lib/ghc-7.4.2/libHSrts* /usr/lib/ghc-7.4.2/libHSrts.a {snip} /usr/lib/ghc-7.4.2/libHSrts*-ghc7.4.2*.so* {snip} So, it seems to me that I need to either: 1. Tell the linker about the possibility of a "-ghc7.4.2" file name suffix, or 2. rebuild my "*.so"s without that suffix. *Can anyone tell me:* - *How to accomplish either #1 or #2, above?* - *Which one is the preferred solution to the problem?* - *Am I completely off in the weeds?* - *If so, what should I really be doing, in order to fix this issue?* Thanks! -db
I am able to fix my build problem, by creating a link to * libHSrts-ghc7.4.2.so, *named *libHSrts.so*: dbanas@dbanas-lap:~/prj/AMI-Tool$ ll /usr/lib/ghc-7.4.2/libHSrts* -rw-r--r-- 1 root root 980950 Apr 23 20:08 /usr/lib/ghc-7.4.2/libHSrts.a {snip} -rwxr-xr-x 1 root root 429218 Apr 23 20:08 /usr/lib/ghc-7.4.2/libHSrts-ghc7.4.2.so* {snip} lrwxrwxrwx 1 root root 20 Apr 27 08:20 /usr/lib/ghc-7.4.2/*libHSrts.so*-> libHSrts-ghc7.4.2.so* {snip} dbanas@dbanas-lap:~/prj/AMI-Tool$ make rm -f libami.so ghc -o libami.so -shared -dynamic -package parsec -lHSrts -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o dbanas@dbanas-lap:~/prj/AMI-Tool$ However, I'm a little confused as to why the "-package parsec" isn't triggering the same issue, since the parsec dynamic libraries were given the same "-ghc7.4.2" suffix: dbanas@dbanas-lap:~/prj/AMI-Tool$ ll ~/.cabal/lib/parsec-3.1.3/ghc-7.4.2/ total 5816 {snip} -rw-r--r-- 1 dbanas dbanas 1006668 Apr 24 16:37 HSparsec-3.1.3.o -rw-r--r-- 1 dbanas dbanas 1340698 Apr 24 16:37 libHSparsec-3.1.3.a -rwxr-xr-x 1 dbanas dbanas 1061317 Apr 24 16:37 libHSparsec-3.1.3*-ghc7.4.2* .so* {snip} *Any thoughts?* Thanks, -db On Saturday, April 27, 2013 6:37:43 AM UTC-7, David Banas wrote:
Recently, I had to recompile ghc, in order to get the "-dyn" versions of the standard libraries installed. (The standard Ubuntu 12.10 64-bit Linux distribution doesn't include them in its "haskell-platform" package, and you can't upgrade "base" using the normal "cabal iinstall" approach, from what I understand.)
When I did this, the "-dyn" versions of the standard libraries were, in fact, installed. However, they were given names with a "-ghc7.4.2.so" suffix. And this is causing the build of a previously working project to break, thusly:
ghc -o libami.so -shared -dynamic -package parsec *-lHSrts* -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o
/usr/bin/ld: /usr/lib/ghc-7.4.2/*libHSrts.a*(RtsAPI.o): relocation R_X86_64_32S against `ghczmprim_GHCziTypes_Czh_con_info' can not be used when making a shared object; recompile with -fPIC
The problem is this: the linker is picking up the "*.a" version of the * HSrts* library, instead of the "*.so" version, which is what it really needs. And the reason it's doing this is the "*.so" version has been given a "-ghc7.4.2" suffix:
dbanas@dbanas-lap:~/prj/AMI-Tool$ l /usr/lib/ghc-7.4.2/libHSrts* /usr/lib/ghc-7.4.2/libHSrts.a
{snip}
/usr/lib/ghc-7.4.2/libHSrts*-ghc7.4.2*.so*
{snip}
So, it seems to me that I need to either:
1. Tell the linker about the possibility of a "-ghc7.4.2" file name suffix, or 2. rebuild my "*.so"s without that suffix.
*Can anyone tell me:*
- *How to accomplish either #1 or #2, above?* - *Which one is the preferred solution to the problem?* - *Am I completely off in the weeds?* - *If so, what should I really be doing, in order to fix this issue?*
Thanks! -db
On Sat, Apr 27, 2013 at 11:47 AM, David Banas
dbanas@dbanas-lap:~/prj/AMI-Tool$ make rm -f libami.so ghc -o libami.so -shared -dynamic -package parsec -lHSrts -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o dbanas@dbanas-lap:~/prj/AMI-Tool$
However, I'm a little confused as to why the "-package parsec" isn't triggering the same issue, since the parsec dynamic libraries were given the same "-ghc7.4.2" suffix:
That would be because the parsec library contains the correct invocation already, but above you are telling the linker to look for libHSrts.{so,a} with the explicit -l option. You would need to change it to ```-lHSrts-ghc7.4.2```. Perhaps ghc needs an option to include the correct runtime support libraries in this case; certainly, having to specify all of those in the build command is ugly and fragile even without mangled shared object names. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (3)
-
Brandon Allbery -
Captain Freako -
David Banas