Quantcast

Haskell plugin dynamic linking issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Haskell plugin dynamic linking issue

Lana Black
Hello,

I'm working on a Haskell plugin (a shared library) for a C program. When
I load the plugin, I get the following error:

> ./open
dlopen() failed:
/usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so:
undefined symbol: stg_thawArrayzh

open is just a testing wrapper around dlopen(). I found out that
stg_thawArrayzh symbol is exported by the rts, and my library isn't
linked to it, and neither is ghc-prim. How do I fix that? Adding
-lHSrts-ghc8.0.2 to ld-options doesn't seem to have any effect.

Thanks.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Niklas Hambüchen
I'm not sure if it's the solution to your problem already, but there's a
Cabal bug that makes it not pass cc-options and ld-options to GHC as
ghc-options correctly:

https://github.com/haskell/cabal/issues/4435

You need to additionally pass these options as `ghc-options: "-optl
-lyourlib"` if you want to be sure.

Further, looking at an example I have around, my cabal `library` output
(say I have mypackage.cabal with a "library" in there, it's called
"dist/build/libHSmypackage-...so") link against things like
libHSghc-prim, but not against the RTS (libHSrts...so). I think this
makes sense, because as far as I can tell, the RTS is only linked in
when you compile the final executable, and which RTS .so file is chosen
depends on whether you link in the standard runtime, the -threaded
runtime, the debug runtime, etc.

So I believe that when loading Haskell from C you will have to dlopen()
the RTS you want explicitly, before loading your own .so file. You
probably also need to load the RTS with the RTLD_GLOBAL dlopen flag so
that when you later load your .so, it can see the RTS symbols.

An alternative is probably to add HSrts-ghc-VERSION to
`extra-libraries`, like I do here:
https://github.com/nh2/call-haskell-from-anything/blob/0ba6737ea17a45e59704dfdc21c971fe10b7d692/detect-ghc-buildinfo.py#L25.
That links it explicitly like you planned to do.

According to
https://github.com/nh2/call-haskell-from-anything/issues/19#issuecomment-263688677
there is now a `foreign-library` stanza in Cabal that is supposed to
free you of manually having to link/load the RTS. I haven't tried it
yet, since at the time that comment was written, it wasn't released yet.
Now it might be.

Detail documentation of that feature:
https://github.com/haskell/cabal/blob/db26fa21cba92097d9fdeb580ddf797c35af8ed0/Cabal/doc/developing-packages.rst#foreign-libraries

Hope this helps!

Niklas
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Lana Black
On 10/04/17 13:50, Niklas Hambüchen wrote:

> I'm not sure if it's the solution to your problem already, but there's a
> Cabal bug that makes it not pass cc-options and ld-options to GHC as
> ghc-options correctly:
>
> https://github.com/haskell/cabal/issues/4435
>
> You need to additionally pass these options as `ghc-options: "-optl
> -lyourlib"` if you want to be sure.
>
> Further, looking at an example I have around, my cabal `library` output
> (say I have mypackage.cabal with a "library" in there, it's called
> "dist/build/libHSmypackage-...so") link against things like
> libHSghc-prim, but not against the RTS (libHSrts...so). I think this
> makes sense, because as far as I can tell, the RTS is only linked in
> when you compile the final executable, and which RTS .so file is chosen
> depends on whether you link in the standard runtime, the -threaded
> runtime, the debug runtime, etc.
>
> So I believe that when loading Haskell from C you will have to dlopen()
> the RTS you want explicitly, before loading your own .so file. You
> probably also need to load the RTS with the RTLD_GLOBAL dlopen flag so
> that when you later load your .so, it can see the RTS symbols.
>
> An alternative is probably to add HSrts-ghc-VERSION to
> `extra-libraries`, like I do here:
> https://github.com/nh2/call-haskell-from-anything/blob/0ba6737ea17a45e59704dfdc21c971fe10b7d692/detect-ghc-buildinfo.py#L25.
> That links it explicitly like you planned to do.
>
> According to
> https://github.com/nh2/call-haskell-from-anything/issues/19#issuecomment-263688677
> there is now a `foreign-library` stanza in Cabal that is supposed to
> free you of manually having to link/load the RTS. I haven't tried it
> yet, since at the time that comment was written, it wasn't released yet.
> Now it might be.
>
> Detail documentation of that feature:
> https://github.com/haskell/cabal/blob/db26fa21cba92097d9fdeb580ddf797c35af8ed0/Cabal/doc/developing-packages.rst#foreign-libraries
>
> Hope this helps!
>
> Niklas
>

Unfortunately, adding rts to extra-libraries section doesn't help. Now I
get a build error from cabal:

    Process exited with code: ExitFailure 1
    Logs have been written to:
/home/void/dev/hs/test/.stack-work/logs/test-0.1.log

    Configuring test-0.1...
    Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2: Missing dependency on a
foreign
    library:
    * Missing C library: HSrts-ghc8.0.2
    This problem can usually be solved by installing the system package that
    provides this library (you may need the "-dev" version). If the
library is
    already installed but in a non-standard location then you can use
the flags
    --extra-include-dirs= and --extra-lib-dirs= to specify where it is.

Relevant cabal file options:
  extra-lib-dirs:      /usr/lib/ghc-8.0.2/rts
  extra-libraries:     HSrts-ghc8.0.2
  ghc-options:         -Wall -Werror -shared -fPIC -dynamic

Note that this is a library, not an executable as in
call-haskell-from-anything.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Harendra Kumar
In reply to this post by Lana Black
You can try using ghc directly (instead of cabal) so that you have full control over what flags are passed, like this:

ghc -fPIC -dynamic -package xx -c plugin.hs
ld -shared -Bsymbolic -L<path to rts lib> -lHSrts-ghc8.0.2 -o plugin.so plugin.o

If this works then you can find what is wrong/different with your cabal setup by using verbose flags and looking at what is being passed to ghc.

-harendra

On 10 April 2017 at 18:14, Lana Black <[hidden email]> wrote:
Hello,

I'm working on a Haskell plugin (a shared library) for a C program. When
I load the plugin, I get the following error:

> ./open
dlopen() failed:
/usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so:
undefined symbol: stg_thawArrayzh

open is just a testing wrapper around dlopen(). I found out that
stg_thawArrayzh symbol is exported by the rts, and my library isn't
linked to it, and neither is ghc-prim. How do I fix that? Adding
-lHSrts-ghc8.0.2 to ld-options doesn't seem to have any effect.

Thanks.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Lana Black
On 10/04/17 18:41, Harendra Kumar wrote:

> You can try using ghc directly (instead of cabal) so that you have full
> control over what flags are passed, like this:
>
> ghc -fPIC -dynamic -package xx -c plugin.hs
> ld -shared -Bsymbolic -L<path to rts lib> -lHSrts-ghc8.0.2 -o plugin.so
> plugin.o
>
> If this works then you can find what is wrong/different with your cabal
> setup by using verbose flags and looking at what is being passed to ghc.
>
> -harendra

Thank you for the idea. That way everything works.

I created a repo with a small demo of this issue [1]. For some reason,
when options -fPIC -dynamic -shared are present, cabal creates an
executable a.out and links in with RTS instead. The shared library on
the other hand isn't linked with RTS in any case unless ghc is called
directly.

~/devel/hs/cabal-bug> cabal build
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring cabal-bug-0.1...
Building cabal-bug-0.1...
Preprocessing library cabal-bug-0.1...
[1 of 1] Compiling Cabal.Bug        ( src/Cabal/Bug.hs,
dist/build/Cabal/Bug.o )
Linking a.out ...

~/devel/hs/cabal-bug> ldd a.out
        linux-vdso.so.1 (0x00007ffc403e6000)
        libHSrts-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/rts/libHSrts-ghc8.0.2.so
(0x00007f62fb591000)
        libHSbase-4.9.1.0-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/base-4.9.1.0/libHSbase-4.9.1.0-ghc8.0.2.so
(0x00007f62fa987000)
        libHSinteger-gmp-1.0.0.1-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/integer-gmp-1.0.0.1/libHSinteger-gmp-1.0.0.1-ghc8.0.2.so
(0x00007f62fa751000)
        libHSghc-prim-0.5.0.0-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so
(0x00007f62fa366000)
        libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f62fa0c8000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f62f9dc5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f62f9a2c000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f62f9823000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f62f961f000)
        libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f62f9416000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f62f91f9000)
        /lib64/ld-linux-x86-64.so.2 (0x000055768de76000)

~/devel/hs/cabal-bug> ldd
dist/build/libHScabal-bug-0.1-50NTk4EdDNe8utEsR21Nft-ghc8.0.2.so
        linux-vdso.so.1 (0x00007fff249d9000)
        libHSbase-4.9.1.0-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/base-4.9.1.0/libHSbase-4.9.1.0-ghc8.0.2.so
(0x00007f6c90bb4000)
        libHSinteger-gmp-1.0.0.1-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/integer-gmp-1.0.0.1/libHSinteger-gmp-1.0.0.1-ghc8.0.2.so
(0x00007f6c9097d000)
        libHSghc-prim-0.5.0.0-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so
(0x00007f6c90592000)
        libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f6c902f5000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6c8fff1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6c8fc58000)
        /lib64/ld-linux-x86-64.so.2 (0x000055f911c1d000)


Is this a bug in cabal?

[1]: https://github.com/greydot/cabal-bug
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Niklas Hambüchen
I don't know if it's a cabal bug, but when I try to make foreign
libraries, I always put them into an `executable` section and use
`-no-hs-main -fPIC -shared -dynamic`:

https://github.com/nh2/call-haskell-from-anything/blob/d750f9881b4023ead32172967c0b1c88f36038f8/call-haskell-from-anything.cabal#L66
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Albert Y. C. Lai
In reply to this post by Lana Black
On 2017-04-10 04:58 PM, Lana Black wrote:
> ~/devel/hs/cabal-bug> cabal build
> Package has never been configured. Configuring with default flags. If this
> fails, please run configure manually.
> Resolving dependencies...
> Configuring cabal-bug-0.1...

I am surprised that at this point you did not receive the warning I
received:

Warning: Instead of 'ghc-options: -lHSrts-ghc8.0.2' use
'extra-libraries: HSrts-ghc8.0.2'

In my http://www.vex.net/~trebla/haskell/so.xhtml I use the
extra-libraries route (and build-type: Configure to automate "8.0.2").
Also I do not use ghc-options, see below.

> Building cabal-bug-0.1...
> Preprocessing library cabal-bug-0.1...
> [1 of 1] Compiling Cabal.Bug        ( src/Cabal/Bug.hs,
> dist/build/Cabal/Bug.o )
> Linking a.out ...

This a.out is not an executable. It is a shared library. The name
"a.out" is a historical generic bland default name for any linker output
whenever the user fails to specify "-o realname". Linker output could be
executable or library depending on other flags.

Now to see why this a.out exists at all, you really should use "cabal
build -v" to see how cabal uses GHC. But the short story is:

cabal calls GHC at least 3 times:

1st time is to compile *.hs files to *.o files, e.g., Bug.hs to Bug.o.
(If you have multiple *.hs files, it is still one call, and you also see
a -j2 or -j4 or -j65536 according to your number of CPU cores to tell
GHC to parallelize.)

2nd time is to produce the *.a library.

3rd time is to produce the *.so library.

Now, if you hardcode the blunt sledgehammer that is ghc-options: -fPIC
-dynamic -shared, as opposed to letting cabal do it at the right times
(namely, -shared during the 3rd time only), then the extraneous -shared
during the 1st time, which is supposed to be *.o only, tricks GHC into
calling the linker to produce an extraneous *.so (except there is no -o
so the name comes out as a.out).

But do not think that you can declare victory now and take this a.out
and get away with it.

For all practical purposes you will need to include some C code in the
library. See again my article for why. But the short story is: Who's
gonna call hs_init?

The 1st call to GHC does not mention the C code whatsoever. The a.out
thus produced will be missing the C code. It is incomplete.

There are extra calls after the 1st and before the 2nd to compile *.c to
*.o.

Only by the 3rd call are all *.o files, from both Haskell and C, brought
together into a complete *.so. (Well, the 2nd call too, but you are not
going after the *.a.)

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Lana Black
On 10/04/17 22:46, Albert Y. C. Lai wrote:
> I am surprised that at this point you did not receive the warning I
> received:
>
> Warning: Instead of 'ghc-options: -lHSrts-ghc8.0.2' use
> 'extra-libraries: HSrts-ghc8.0.2'
>
> In my http://www.vex.net/~trebla/haskell/so.xhtml I use the
> extra-libraries route (and build-type: Configure to automate "8.0.2").
> Also I do not use ghc-options, see below.

Thank you for this suggestion. Now things start to get rather strange. I
have changed the cabal file accordingly [1]. When I run cabal configure,
I get the following error:

> cabal configure
Resolving dependencies...
Configuring cabal-bug-0.1...
cabal: Missing dependency on a foreign library:
* Missing C library: HSrts-ghc8.0.2
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.

However, that doesn't prevent cabal build from succeeding, and now I
have a shared library linked to RTS.

> cabal build
Building cabal-bug-0.1...
Preprocessing library cabal-bug-0.1...
[1 of 1] Compiling Cabal.Bug        ( src/Cabal/Bug.hs,
dist/build/Cabal/Bug.o )

> ldd dist/build/libHScabal-bug-0.1-50NTk4EdDNe8utEsR21Nft-ghc8.0.2.so
        linux-vdso.so.1 (0x00007ffea75c9000)
        libHSrts-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/rts/libHSrts-ghc8.0.2.so
(0x00007f8057193000)
        libHSbase-4.9.1.0-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/base-4.9.1.0/libHSbase-4.9.1.0-ghc8.0.2.so
(0x00007f8056589000)
        libHSinteger-gmp-1.0.0.1-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/integer-gmp-1.0.0.1/libHSinteger-gmp-1.0.0.1-ghc8.0.2.so
(0x00007f8056353000)
        libHSghc-prim-0.5.0.0-ghc8.0.2.so =>
/usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so
(0x00007f8055f68000)
        libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f8055cca000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f80559c7000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f805562e000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f8055425000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f8055221000)
        libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f8055018000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8054dfb000)
        /lib64/ld-linux-x86-64.so.2 (0x000056212e051000)

However, if I run cabal build without calling cabal configure first, the
latter fails and the build process is stopped at that point. This also
prevents me from building my project with stack.

>> Building cabal-bug-0.1...
>> Preprocessing library cabal-bug-0.1...
>> [1 of 1] Compiling Cabal.Bug        ( src/Cabal/Bug.hs,
>> dist/build/Cabal/Bug.o )
>> Linking a.out ...
>
> This a.out is not an executable. It is a shared library. The name
> "a.out" is a historical generic bland default name for any linker output
> whenever the user fails to specify "-o realname". Linker output could be
> executable or library depending on other flags.
>
> Now to see why this a.out exists at all, you really should use "cabal
> build -v" to see how cabal uses GHC. But the short story is:
>
> cabal calls GHC at least 3 times:
>
> 1st time is to compile *.hs files to *.o files, e.g., Bug.hs to Bug.o.
> (If you have multiple *.hs files, it is still one call, and you also see
> a -j2 or -j4 or -j65536 according to your number of CPU cores to tell
> GHC to parallelize.)
>
> 2nd time is to produce the *.a library.
>
> 3rd time is to produce the *.so library.
>
> Now, if you hardcode the blunt sledgehammer that is ghc-options: -fPIC
> -dynamic -shared, as opposed to letting cabal do it at the right times
> (namely, -shared during the 3rd time only), then the extraneous -shared
> during the 1st time, which is supposed to be *.o only, tricks GHC into
> calling the linker to produce an extraneous *.so (except there is no -o
> so the name comes out as a.out).

Thanks for this explanation.

> But do not think that you can declare victory now and take this a.out
> and get away with it.
>
> For all practical purposes you will need to include some C code in the
> library. See again my article for why. But the short story is: Who's
> gonna call hs_init?

Yes, I'm aware of this. The real code in question has calls to hs_init()
and hs_exit(). All I'm trying to do now is to solve the linking problem.

[1]: https://github.com/greydot/cabal-bug/blob/extra-lib/cabal-bug.cabal

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Albert Y. C. Lai
On 2017-04-11 03:20 AM, Lana Black wrote:

>> cabal configure
> Resolving dependencies...
> Configuring cabal-bug-0.1...
> cabal: Missing dependency on a foreign library:
> * Missing C library: HSrts-ghc8.0.2
> This problem can usually be solved by installing the system package that
> provides this library (you may need the "-dev" version). If the library is
> already installed but in a non-standard location then you can use the flags
> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>
> However, that doesn't prevent cabal build from succeeding, and now I
> have a shared library linked to RTS.

[...]

> However, if I run cabal build without calling cabal configure first, the
> latter fails and the build process is stopped at that point. This also
> prevents me from building my project with stack.

Here is the thing. I cannot reproduce either outcome.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Lana Black
On 13/04/17 18:42, Albert Y. C. Lai wrote:

> On 2017-04-11 03:20 AM, Lana Black wrote:
>>> cabal configure
>> Resolving dependencies...
>> Configuring cabal-bug-0.1...
>> cabal: Missing dependency on a foreign library:
>> * Missing C library: HSrts-ghc8.0.2
>> This problem can usually be solved by installing the system package that
>> provides this library (you may need the "-dev" version). If the
>> library is
>> already installed but in a non-standard location then you can use the
>> flags
>> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>>
>> However, that doesn't prevent cabal build from succeeding, and now I
>> have a shared library linked to RTS.
>
> [...]
>
>> However, if I run cabal build without calling cabal configure first, the
>> latter fails and the build process is stopped at that point. This also
>> prevents me from building my project with stack.
>
> Here is the thing. I cannot reproduce either outcome.
>

I dug a bit further, and it looks like the cabal configure error is
somehow related to Gentoo, since I'm only able to reproduce it there.
Otherwise the solution you linked works perfectly.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Haskell plugin dynamic linking issue

Lana Black
In reply to this post by Albert Y. C. Lai
On 13/04/17 18:42, Albert Y. C. Lai wrote:

> On 2017-04-11 03:20 AM, Lana Black wrote:
>>> cabal configure
>> Resolving dependencies...
>> Configuring cabal-bug-0.1...
>> cabal: Missing dependency on a foreign library:
>> * Missing C library: HSrts-ghc8.0.2
>> This problem can usually be solved by installing the system package that
>> provides this library (you may need the "-dev" version). If the
>> library is
>> already installed but in a non-standard location then you can use the
>> flags
>> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>>
>> However, that doesn't prevent cabal build from succeeding, and now I
>> have a shared library linked to RTS.
>
> [...]
>
>> However, if I run cabal build without calling cabal configure first, the
>> latter fails and the build process is stopped at that point. This also
>> prevents me from building my project with stack.
>
> Here is the thing. I cannot reproduce either outcome.

Disregard my previous email. The cause of this issue is that cabal tries
to link a test executable with only libraries specified in extra-libs.
Therefore the test build fails, because RTS isn't linked to base or
ghc-prim.

Now, here's the fun part. Because the test code supplied by cabal has no
actual calls to any library functions, ld may filter out any unused
libraries, which includes RTS in our case. This behaviour is controlled
by --as-needed option and is enabled by default in Ubuntu, which, I
assume, you are using.

In my case, the workaround here would be to enable --as-needed by
default in the system.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Loading...