Opened 2 years ago

Closed 7 months ago

Last modified 7 months ago

#9010 closed bug (fixed)

TemplateHaskell leads to an "unknown symbol" error

Reported by: Feuerbach Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc: vandijk.roel@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Code:

{-# LANGUAGE TemplateHaskell #-}
module M where

import System.Console.Editline
import Data.Lens.Template

data S = S { _a :: EditLine }

makeLens ''S

When compiled with ghc link.hs, everything is fine;

[1 of 1] Compiling M                ( link.hs, link.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package tagged-0.7.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package transformers-compat-0.1.1.1 ... linking ... done.
Loading package contravariant-0.4.4 ... linking ... done.
Loading package distributive-0.4.3.1 ... linking ... done.
Loading package mtl-2.1.3.1 ... linking ... done.
Loading package text-1.1.0.1 ... linking ... done.
Loading package hashable-1.2.1.0 ... linking ... done.
Loading package nats-0.1.2 ... linking ... done.
Loading package unordered-containers-0.2.3.3 ... linking ... done.
Loading package semigroups-0.12.2 ... linking ... done.
Loading package comonad-4.0.1 ... linking ... done.
Loading package semigroupoids-4.0.1 ... linking ... done.
Loading package data-lens-2.10.4 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package data-lens-template-2.1.8 ... linking ... done.

However, when compiling with ghc -package-id editline-0.2.1.1-ef91ae78e7ea1b9142c2fb0b84e85c11 link.hs, I get

[1 of 1] Compiling M                ( link.hs, link.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package editline-0.2.1.1 ... linking ... ghc: /home/feuerbach/work/.cabal-sandbox/lib/i386-linux-ghc-7.6.3/editline-0.2.1.1/HSeditline-0.2.1.1.o: unknown symbol `el_reset'
ghc: unable to load package `editline-0.2.1.1'

This is a problem because that's how cabal invokes ghc.

This looks similar to #4899, except there's nothing "non-standard" here (no profiling or dynamic linking).

Change History (19)

comment:1 Changed 2 years ago by rwbarton

  • Resolution set to fixed
  • Status changed from new to closed

I was able to reproduce this in 7.6 but not 7.8, so I assume it has been fixed by the switch to using dynamic libraries for TH. Please reopen if you find otherwise.

comment:2 Changed 22 months ago by Fuuzetsu

Is there any workaround at all for 7.6.3? We're currently hitting this from new Yi dependency (bug filed with library author at https://github.com/Aelve/charsetdetect-ae/issues/1) and I would hate to find out it's ‘don't use this library or drop support for 7.6.3’, especially considering there aren't exactly many alternative libraries for this.

comment:3 Changed 22 months ago by rwbarton

comment:4 Changed 7 months ago by basvandijk

  • Cc vandijk.roel@… added
  • Priority changed from normal to high
  • Resolution fixed deleted
  • Status changed from closed to new
  • Version changed from 7.6.3 to 7.10.2

At LumiGuide we're hitting this issue on GHC-7.10.2.

We're developing a binding to opencv-3.0.0 which is a C++ library. The Haskell package is called thea and thea.cabal specifies the following cc-options: -O2 -std=c++11. We also need to build the package using the following cabal flags: --with-gcc=g++ --with-ld=g++. Maybe irrelevant but thea uses inline-c for the FFI.

We have another Haskell package called vision-playground that depends on thea. This all works great. However I need to use some TemplateHaskell in TM.Types (one of the modules of vision-playground) and get the following error when doing a cabal build:

[1 of 3] Compiling TM.Types         ( src/TM/Types.hs, dist/build/vision-playground/vision-playground-tmp/TM/Types.o )
ghc: /nix/store/1wyif1adq0pb9h08jqr0v5lrykfhdhah-opencv-3.0.0/lib/libopencv_hal.a: unknown symbol `_ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5'
ghc: unable to load package `thea-0.0.0'

I tried the hacks suggested by @rwbarton but they did not work for me.

I hope there's a work-around since this is a high priority issue for us at LumiGuide.

comment:5 Changed 7 months ago by bgamari

I'm afraid I'm not terribly familiar with the root cause of this problem but I would be happy to help provided we had something concrete to work with. Could you provide a bit of code so that we can reproduce the issue?

Have you checked whether the symbol in question (or symbols like it) is defined in libopencv_hal.a?

comment:6 Changed 7 months ago by basvandijk

Hi Ben, I created a minimal isolated test case that has the same problem:

git clone https://github.com/basvandijk/th-unknown-symbol-test

If you're using Nix a simple nix-build will show the problem.

If you aren't using Nix you have to install hs-opencv-binding yourself (probably in a cabal sandbox) and build play manually.

comment:7 Changed 7 months ago by basvandijk

Regarding the symbol in question, note that according to http://demangler.com/ the mangled symbol _ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5 demangles to:

   guard variable for cv::v_invsqrt(cv::v_float32x4 const&)::_0_5

It is defined here: https://github.com/Itseez/opencv/blob/3.0.0/modules/hal/include/opencv2/hal/intrin_sse.hpp#L683

And it indeed occurs in libopencv_hal.a:

 nm /nix/store/1wyif1adq0pb9h08jqr0v5lrykfhdhah-opencv-3.0.0/lib/libopencv_hal.a 2>/dev/null | grep _ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5                                                                                                           
0000000000000000 u _ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5

comment:8 Changed 7 months ago by rwbarton

I could not reproduce this on Debian Linux. Does "... and build play manually" mean something other than...?

cabal sandbox init
cabal install hs-opencv-binding/
cabal install play/

Also I seriously doubt that lens is required, can you try simplifying makeLenses ''MyRecord to just a return []?

comment:9 Changed 7 months ago by rwbarton

I should probably add that I am building against the Debian package libopencv-dev=2.4.9.1+dfsg-1.2 and the hs-opencv-binding is dynamically linked against a bunch of OpenCV libraries

rwbarton@morphism:/tmp/th-unknown-symbol-test/hs-opencv-binding/dist/dist-sandbox-3f06d746/build$ ldd libHShs-opencv-binding-0.0.0-3XpfF7vOgxLEUT7DVeoPSc-ghc7.10.1.so | grep libopencv
	libopencv_calib3d.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.2.4 (0x00007f6bd2ec1000)
	libopencv_contrib.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_contrib.so.2.4 (0x00007f6bd2bda000)
	libopencv_core.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4 (0x00007f6bd27a8000)
	libopencv_features2d.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_features2d.so.2.4 (0x00007f6bd2508000)
	libopencv_flann.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_flann.so.2.4 (0x00007f6bd229c000)
	libopencv_gpu.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_gpu.so.2.4 (0x00007f6bd203d000)
	libopencv_highgui.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4 (0x00007f6bd1df0000)
	libopencv_imgproc.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.2.4 (0x00007f6bd195d000)
	libopencv_legacy.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_legacy.so.2.4 (0x00007f6bd1648000)
	libopencv_ml.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_ml.so.2.4 (0x00007f6bd13cb000)
	libopencv_objdetect.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_objdetect.so.2.4 (0x00007f6bd1151000)
	libopencv_ocl.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_ocl.so.2.4 (0x00007f6bd0d82000)
	libopencv_photo.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_photo.so.2.4 (0x00007f6bd0b64000)
	libopencv_stitching.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_stitching.so.2.4 (0x00007f6bd08dc000)
	libopencv_superres.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_superres.so.2.4 (0x00007f6bd06a1000)
	libopencv_ts.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_ts.so.2.4 (0x00007f6bd03f1000)
	libopencv_video.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_video.so.2.4 (0x00007f6bd019a000)
	libopencv_videostab.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_videostab.so.2.4 (0x00007f6bcff5b000)

It looks like you are using static linking, for some reason?

comment:10 Changed 7 months ago by basvandijk

Hi rwbarton, yes a cabal sandbox init; cabal install hs-opencv-binding/; cabal install play/ should be all that's required to build manually.

I removed the dependency on lens like you suggested and the problem remains as expected.

Note that I'm linking against opencv-3.0.0.

It's very likely this has something to do with static vs dynamic linking.

comment:11 Changed 7 months ago by rwbarton

  • Status changed from new to infoneeded

Also are you using a static GHC somehow? (ghc --info outputs ("GHC Dynamic","NO")?)

Otherwise I don't understand how you can be getting an error from ghc's runtime linker.

comment:12 Changed 7 months ago by basvandijk

rwbarton, thanks for investigating!

It seems I'm using a dynamic GHC:

$ ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc")
 ,("C compiler flags"," -fno-stack-protector")
 ,("C compiler link flags","")
 ,("Haskell CPP command","/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc")
 ,("Haskell CPP flags","-E -undef -traditional ")
 ,("ld command","/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/ld")
 ,("ld flags","")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","YES")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("ar command","/nix/store/v7h3j43vx0dz5ahhkxg5z50by2iqc6k1-binutils-2.23.1/bin/ar")
 ,("ar flags","q")
 ,("ar supports at file","YES")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/nix/store/lhgkssg79bxdba541h75mgdvjh35b8ic-perl-5.20.2/bin/perl")
 ,("cross compiling","NO")
 ,("target os","OSLinux")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","True")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","False")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.10.2")
 ,("Project Git commit id","0da488c4438d88c9252e0b860426b8e74b5fc9e8")
 ,("Booter version","7.8.4")
 ,("Stage","2")
 ,("Build platform","x86_64-unknown-linux")
 ,("Host platform","x86_64-unknown-linux")
 ,("Target platform","x86_64-unknown-linux")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("Leading underscore","NO")
 ,("Debug on","False")
 ,("LibDir","/nix/store/aivgsc0vbnq2vi8fzw9xjkrlgayfqppv-ghc-7.10.2/lib/ghc-7.10.2")
 ,("Global Package DB","/nix/store/aivgsc0vbnq2vi8fzw9xjkrlgayfqppv-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d")
 ]

comment:13 Changed 7 months ago by rwbarton

Well I'm a bit stuck being unable to reproduce the behavior you seem to be getting.

Here's what I think is going on:

  1. Somehow, I don't know how, you're getting GHC's runtime linker involved. I guess this must be due to some difference in configuration of opencv, but I don't understand how.
  1. From man nm:
    "u" The symbol is a unique global symbol.  This is a GNU extension to the standard set of ELF symbol bindings.  For such a symbol the dynamic
        linker will make sure that in the entire process there is just one symbol with this name and type in use.
    
    GHC's runtime dynamic linker presumably doesn't understand this symbol type since it is a non-standard extension. And that's probably what causes it to report the symbol as not found.

Fixing 2 would require changes to GHC, so it probably makes sense to fix 1. But I don't know why you are in this situation. Perhaps build output with cabal -v and ghc -v would help.

comment:14 Changed 7 months ago by rwbarton

For example, when I build play with cabal install --ghc-option=-v, I get a bunch of output including the lines

...
Loading package primitive-0.6.1.0 ... linking ... done.
Loading package vector-0.11.0.0 ... linking ... done.
Loading package lens-4.13 ... linking ... done.
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/tmp/th-unknown-symbol-test/.cabal-sandbox/lib/x86_64-linux-ghc-7.10.1/hsope_3XpfF7vOgxLEUT7DVeoPSc --print-file-name libopencv_calib3d.so
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/tmp/th-unknown-symbol-test/.cabal-sandbox/lib/x86_64-linux-ghc-7.10.1/hsope_3XpfF7vOgxLEUT7DVeoPSc --print-file-name libopencv_contrib.so
...
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/tmp/th-unknown-symbol-test/.cabal-sandbox/lib/x86_64-linux-ghc-7.10.1/hsope_3XpfF7vOgxLEUT7DVeoPSc --print-file-name libopencv_videostab.so
Loading package hs-opencv-binding-0.0.0 ... linking ... done.

That means GHC loaded the dynamic OpenCV libraries with dlopen(). In your case, it is apparently not doing that.

comment:15 Changed 7 months ago by basvandijk

Since I'm on NixOS I think it's very likely that OpenCV is build differently than on your Debian system.

Here's the full verbose cabal install output:

$ cabal install -v --ghc-option=-v ./play/
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/gcc -dumpversion
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/haddock --version
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hpc version
looking for tool hsc2hs near compiler in
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin
found hsc2hs in
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hsc2hs
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hsc2hs --version
/run/current-system/sw/bin/HsColour -version
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc -c /run/user/1001/1804289383846930886.c -o /run/user/1001/16816927771714636915.o -v
Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4
Using binary package database: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482
wired-in package base mapped to base-4.8.1.0-4f7206fd964c629946bb89db72c80011
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-90e8393d65f4ae44cb2026177a257f28
wired-in package ghc mapped to ghc-7.10.2-787f1a784665fb3ac2a1be1d9d85245b
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: 
Created temporary directory: /run/user/1001/ghc2412_0
*** C Compiler:
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x c /run/user/1001/1804289383846930886.c -o /run/user/1001/ghc2412_0/ghc_1.s -Wimplicit -S '-D__GLASGOW_HASKELL__=710' -include /nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/include/ghcversion.h -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw/include -I/nix/store/xgajz3ndnj863mx3zgmk5fx6c8rssz6v-gmp-5.1.3/include -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/include
*** Assembler:
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x assembler -c /run/user/1001/ghc2412_0/ghc_1.s -o /run/user/1001/16816927771714636915.o
*** Deleting temp files:
Deleting: /run/user/1001/ghc2412_0/ghc_1.s
*** Deleting temp dirs:
Deleting: /run/user/1001/ghc2412_0
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/ld -x -r /run/user/1001/16816927771714636915.o -o /run/user/1001/1957747793424238335.o
/nix/store/v0hr8wc2bfzax11a756lc8j54v98141g-gnutar-1.28/bin/tar --help
Reading available packages...
Choosing modular solver.
Resolving dependencies...
Ready to install play-0.0.0
Waiting for install task to finish...
Configuring play-0.0.0...
Dependency base ==4.8.1.0: using base-4.8.1.0
Dependency hs-opencv-binding ==0.0.0: using hs-opencv-binding-0.0.0
Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4
Using binary package database: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482
wired-in package base mapped to base-4.8.1.0-4f7206fd964c629946bb89db72c80011
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-90e8393d65f4ae44cb2026177a257f28
wired-in package ghc mapped to ghc-7.10.2-787f1a784665fb3ac2a1be1d9d85245b
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: 
Created temporary directory: /run/user/1001/ghc2487_0
*** C Compiler:
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x c /run/user/1001/7198853861649760492.c -o /run/user/1001/ghc2487_0/ghc_1.s -Wimplicit -S '-D__GLASGOW_HASKELL__=710' -include /nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/include/ghcversion.h -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw/include -I/nix/store/xgajz3ndnj863mx3zgmk5fx6c8rssz6v-gmp-5.1.3/include -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda-ghc-7.10.2/lib/ghc-7.10.2/include
*** Assembler:
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x assembler -c /run/user/1001/ghc2487_0/ghc_1.s -o /run/user/1001/5965166491189641421.o
*** Deleting temp files:
Deleting: /run/user/1001/ghc2487_0/ghc_1.s
*** Deleting temp dirs:
Deleting: /run/user/1001/ghc2487_0
Using Cabal-1.22.4.0 compiled by ghc-7.10
Using compiler: ghc-7.10.2
Using install prefix: /home/bas.van.dijk/.cabal
Binaries installed in: /home/bas.van.dijk/.cabal/bin
Libraries installed in:
/home/bas.van.dijk/.cabal/lib/x86_64-linux-ghc-7.10.2/play-0.0.0-4YsBlLA8LO69MV7S17lkjf
Private binaries installed in: /home/bas.van.dijk/.cabal/libexec
Data files installed in:
/home/bas.van.dijk/.cabal/share/x86_64-linux-ghc-7.10.2/play-0.0.0
Documentation installed in:
/home/bas.van.dijk/.cabal/share/doc/x86_64-linux-ghc-7.10.2/play-0.0.0
Configuration files installed in: /home/bas.van.dijk/.cabal/etc
No alex found
Using ar found on system at:
/nix/store/v7h3j43vx0dz5ahhkxg5z50by2iqc6k1-binutils-2.23.1/bin/ar
No c2hs found
No cpphs found
Using gcc version 4.9.3 found on system at:
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/gcc
Using ghc version 7.10.2 found on system at:
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc
Using ghc-pkg version 7.10.2 found on system at:
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc-pkg
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.16.1 found on system at:
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/haddock
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.67 found on system at:
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hpc
Using hsc2hs version 0.67 found on system at:
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hsc2hs
Using hscolour version 1.22 found on system at:
/run/current-system/sw/bin/HsColour
No jhc found
Using ld found on system at:
/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/ld
No lhc found
No lhc-pkg found
No pkg-config found
Using strip version 2.23 found on system at:
/nix/store/v7h3j43vx0dz5ahhkxg5z50by2iqc6k1-binutils-2.23.1/bin/strip
Using tar found on system at:
/nix/store/v0hr8wc2bfzax11a756lc8j54v98141g-gnutar-1.28/bin/tar
No uhc found
Component build order: executable 'play'
creating dist/build
creating dist/build/autogen
Building play-0.0.0...
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc-pkg init dist/package.conf.inplace
Preprocessing executable 'play' for play-0.0.0...
Building executable play...
creating dist/build/play
creating dist/build/play/play-tmp
/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc --make -no-link -fbuilding-cabal-package -O -static -outputdir dist/build/play/play-tmp -odir dist/build/play/play-tmp -hidir dist/build/play/play-tmp -stubdir dist/build/play/play-tmp -i -idist/build/play/play-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/play/play-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.8.1.0-4f7206fd964c629946bb89db72c80011 -package-id hs-opencv-binding-0.0.0-8f2416af7a2ee3c9cd620cc714b1aad9 -XHaskell2010 ./play.hs -v
Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4
Using binary package database: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/package.cache
Using binary package database: dist/package.conf.inplace/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482
wired-in package base mapped to base-4.8.1.0-4f7206fd964c629946bb89db72c80011
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-90e8393d65f4ae44cb2026177a257f28
wired-in package ghc mapped to ghc-7.10.2-787f1a784665fb3ac2a1be1d9d85245b
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: 
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482
wired-in package base mapped to base-4.8.1.0-4f7206fd964c629946bb89db72c80011
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-90e8393d65f4ae44cb2026177a257f28
wired-in package ghc mapped to ghc-7.10.2-787f1a784665fb3ac2a1be1d9d85245b
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *play.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
  [NONREC
      ModSummary {
         ms_hs_date = 2015-12-18 16:32:22.959647846 UTC
         ms_mod = Main,
         ms_textual_imps = [import (implicit) Prelude, import OpenCV]
         ms_srcimps = []
      }]
*** Deleting temp files:
Deleting: 
compile: input file play.hs
Created temporary directory: /run/user/1001/ghc2538_0
*** Checking old interface for Main:
[1 of 1] Compiling Main             ( play.hs, dist/build/play/play-tmp/Main.o )
*** Parser:
*** Renamer/typechecker:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
Loading package ghc-prim-0.4.0.0 ... linking ... done.
Loading package integer-gmp-1.0.0.0 ... linking ... done.
Loading package base-4.8.1.0 ... linking ... done.
Loading package hs-opencv-binding-0.0.0 ... linking ... ghc: /nix/store/yd25dral2yg4sdn31iq3cbzf1k2lsqlh-opencv-3.0.0/lib/libopencv_hal.a: unknown symbol `_ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5'
*** Deleting temp files:
Deleting: /run/user/1001/ghc2538_0/ghc_1.s
Warning: deleting non-existent /run/user/1001/ghc2538_0/ghc_1.s
*** Deleting temp dirs:
Deleting: /run/user/1001/ghc2538_0
ghc: unable to load package `hs-opencv-binding-0.0.0'
Failed to install play-0.0.0
cabal: Error: some packages failed to install:
play-0.0.0 failed during the building phase. The exception was:
ExitFailure 1

comment:16 Changed 7 months ago by rwbarton

What is the hs-opencv-binding package description? e.g. cabal sandbox hc-pkg describe hs-opencv-binding

comment:17 Changed 7 months ago by basvandijk

The following is from inside nix-shell -A env (i.e. inside an environment which has hs-opencv-binding installed):

$ ghc-pkg describe hs-opencv-binding
name: hs-opencv-binding
version: 0.0.0
id: hs-opencv-binding-0.0.0-8f2416af7a2ee3c9cd620cc714b1aad9
key: hsope_LkixZPC131K3fnJ17eOHEn
license: BSD3
exposed: True
exposed-modules:
    OpenCV
trusted: False
import-dirs: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv-binding-0.0.0/lib/ghc-7.10.2/hs-opencv-binding-0.0.0
library-dirs: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv-binding-0.0.0/lib/ghc-7.10.2/hs-opencv-binding-0.0.0
              /nix/store/yd25dral2yg4sdn31iq3cbzf1k2lsqlh-opencv-3.0.0/lib
data-dir: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv-binding-0.0.0/share/x86_64-linux-ghc-7.10.2/hs-opencv-binding-0.0.0
hs-libraries: HShs-opencv-binding-0.0.0-LkixZPC131K3fnJ17eOHEn
extra-libraries:
    opencv_shape opencv_stitching opencv_objdetect opencv_superres
    opencv_videostab opencv_calib3d opencv_features2d opencv_highgui
    opencv_videoio opencv_imgcodecs opencv_video opencv_photo opencv_ml
    opencv_imgproc opencv_flann opencv_core opencv_hal
include-dirs: /nix/store/yd25dral2yg4sdn31iq3cbzf1k2lsqlh-opencv-3.0.0/include
              /nix/store/yd25dral2yg4sdn31iq3cbzf1k2lsqlh-opencv-3.0.0/include/opencv
depends:
    base-4.8.1.0-4f7206fd964c629946bb89db72c80011
haddock-interfaces: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv-binding-0.0.0/share/doc/x86_64-linux-ghc-7.10.2/hs-opencv-binding-0.0.0/html/hs-opencv-binding.haddock
haddock-html: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv-binding-0.0.0/share/doc/x86_64-linux-ghc-7.10.2/hs-opencv-binding-0.0.0/html
pkgroot: "/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-7.10.2"

comment:18 Changed 7 months ago by rwbarton

  • Priority changed from high to normal
  • Resolution set to fixed
  • Status changed from infoneeded to closed
  • Version changed from 7.10.2 to 7.6.3

Okay, that's helpful and different from how my package was built. I managed to reproduce the error you saw by building an archive with an undefined symbol reference and specifying it with extra-libraries: and extra-lib-dirs: in hs-opencv-binding.cabal. (Of course, it's not a bug that GHC fails when there really is an undefined symbol!)

It turns out that the GHC runtime linker is still used in the following situation:

When loading a package into GHCi, the last step is to load libraries specified in the extra-libraries: field of the package registration. For each such library, GHCi will first try to find a matching shared library in the library path, then try to find a matching static library in the library path, then ask gcc where to find a shared library, and if all those fail, assume that dlopen will know where to find the shared library. (compiler/ghci/Linker.hs, function locateLib.) It is that second case that you are apparently in (I guess you only built OpenCV as a static library) and in that case the static library is loaded by the GHC runtime linker (in linkPackage in the same file).

That is all fine, except that the GHC runtime linker apparently doesn't understand this "u" symbol type. But that is almost certainly unrelated to the original ticket here, so I reset the ticket status back to its previous state.

I recommend that you simply use dynamic OpenCV libraries, if at all possible. If not, you will apparently need support for this "u" symbol type in the GHCi runtime linker. I'm not sure I understand exactly what the semantics of this symbol type are supposed to be, but it looks fairly straightforward to implement. However, that would obviously require a patch to GHC... so it would probably be easier for you just to use dynamic OpenCV libraries, and avoid the hairiness of the GHC runtime linker.

comment:19 Changed 7 months ago by basvandijk

Thanks for the excellent explanation!

I ended up using the HEAD version of OpenCV which doesn't have the libopencv_hal.a anymore. play now builds successfully.

Note: See TracTickets for help on using tickets.