Opened 15 months ago

Last modified 7 months ago

#9237 new bug

GHC not recognizing INPUT(-llibrary) in linker scripts

Reported by: mmikolajczyk Owned by:
Priority: normal Milestone: 7.12.1
Component: Compiler Version: 7.8.2
Keywords: Cc: jeff@…, hgolden
Operating System: Unknown/Multiple Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: 2615, 10046 Differential Revisions:


I have tried to build accelerate-llvm package and encountered an invalid behaviour of linker. I am using Arch Linux and GHC 7.8.2.

I have installed llvm-general- and llvm-general-pure- from this branch:, and accelerate from HEAD to common sandbox. Then I tried to build accelerate-llvm using the sandbox and got this output during building:

Building accelerate-llvm-
Preprocessing library accelerate-llvm-
[ 1 of 30] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package primitive- ... linking ... done.
Loading package array- ... linking ... done.
Loading package deepseq- ... linking ... done.
Loading package old-locale- ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package vector- ... linking ... done.
Loading package mwc-random- ... linking ... done.
Loading package bytestring- ... linking ... done.
Loading package containers- ... linking ... done.
Loading package transformers- ... linking ... done.
Loading package mtl-2.2.1 ... linking ... done.
Loading package text- ... linking ... done.
Loading package parsec-3.1.5 ... linking ... done.
Loading package unix- ... linking ... done.
Loading package setenv- ... linking ... done.
Loading package pretty- ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package llvm-general-pure- ... linking ... done.
Loading package utf8-string-0.3.8 ... linking ... done.
Loading package llvm-general- ... <command line>: can't load .so/.DLL for: /usr/lib/ (-lncursesw: cannot open shared object file: No such file or directory)

After some searching I narrowed down the issue to /usr/lib/ file. In Arch, this file contains INPUT(-lncursesw). If I change it to INPUT( or INPUT(/usr/lib/ it works fine. Symlinking /usr/lib/ to /usr/lib/ also works.

This bug seems to be connected to #2615. GHC still doesn't follow INPUT commands containing -llibrary form. Ld documentation allows this: If you use `INPUT (-lfile)', ld will transform the name to libfile.a, as with the command line argument `-l'. (

Change History (8)

comment:1 Changed 14 months ago by rwbarton

I think GHC is trying to load /usr/lib/ at runtime with dlopen, in order to run Template Haskell code in Data.Range.Range. It's not trying to link it with ld. So, this is a limitation of the system dlopen, and we are in "workaround" territory.

(Incidentally, my dlopen on Debian (libc 2.18-4) doesn't seem to handle either INPUT(-llibrary) or INPUT(filename).)

#2615 was from when GHC used its own custom loader rather than dlopen. I'm not eager to bring any of that back, but I guess we could try to detect a linker script if dlopen fails.

One thing (well, two things) I don't understand is where the dependency on /usr/lib/ is coming from, and what kind of dependency it is exactly. Who is loading /usr/lib/ does dlopen load dependencies for us, or do we track them ourselves and load them first? Maybe we can arrange things when we build the llvm-general- library so that the dependency is on the real shared object /usr/lib/

comment:2 Changed 14 months ago by rwbarton

Oh, hmm, I actually looked at the code and we do already inspect the error string from dlopen and try to parse a linker script. The problem is that we don't support INPUT(-llibrary). I guess we can transform the name to in that case?

I still would like to avoid incurring dependencies on .sos that are really linker scripts, if possible...

comment:3 Changed 14 months ago by rwbarton

  • Milestone set to 7.8.4

comment:4 Changed 11 months ago by thoughtpolice

  • Milestone changed from 7.8.4 to 7.10.1

Moving (in bulk) to 7.10.4

comment:5 Changed 11 months ago by anjefu

  • Cc jeff@… added

comment:6 Changed 8 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:7 Changed 7 months ago by hgolden

  • Cc hgolden added

comment:8 Changed 7 months ago by hgolden

  • Summary changed from GHC not recognizing "-llibrary" form in implicit linker scripts to GHC not recognizing INPUT(-llibrary) in linker scripts
Note: See TracTickets for help on using tickets.