Building and using the shared library is difficult

[abooij]

This project consists of a bunch of Haskell modules (which can be used as normal), and a dynamic library that can be used to run existing C code. However, this library is hard to build and use.

• The readme is missing build instructions.
• Building this package as a plain cabal package will fail because of missing files: this package (confusingly) depends on libwayland, even though it claims to replace it.
• The resulting package will not contain the actual C libraries in the correct location, hence will not install correctly.
• It is unclear how to run existing binaries that were built against libwayland, such that they use this library instead of libwayland (the C library).

[abooij]

Commits d09d392 and c776e60 should partially resolve this.

Can anyone watching this project comment on the progress on this bug? Is it easy to build, and does it work correctly?

[xavier83]

got this message on running stack build the second time

stack build
Warning: Specified resolver could not satisfy all dependencies. Some external packages have been added as dependencies.
You can suppress this message by removing it from stack.yaml

There were multiple candidates for the Cabal entry "Main.hs" (/.../sudbury/Main.hs), picking /media/.../sudbury/tests/Main.hs

and the symlink libwayland-client.so.0 doesn't get resolved after building with stack as
.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/libwayland-client.so.0/ is where stack builds it for me.

[abooij]

Thanks for your feedback. The warning should be fixed now.

I'm not sure how to make this run under stack - to be honest I'm not even sure why it works with cabal. Does it work with a (sandboxed) cabal for you?

More appropriate build tools would be much appreciated...

[abooij]

Hi @xavier83,

Forget about the cabal thing. Could you try adding the following to the provided stack.yaml

ghc-options:
    sudbury: -lHSrts-ghc7.10.3

and trying the following

$ stack clean
$ stack build
$ LD_LIBRARY_PATH=.stack-work/install/x86_64-linux/lts-5.11/7.10.3/bin weston-flower

(where 7.10.3 is your GHC version, and weston is running before invoking weston-flower)

[xavier83]

it worked 👍
got this message on quiting the flower app 😄 . I guess it is a wip.

weston-flower: symbol lookup error: weston-flower: undefined symbol: wl_display_
disconnect

[abooij]

Thanks. Yes, that is WIP. Currently that bug actually functions as a feature since it indicates that sudbury is used rather than libwayland.

[abooij]

Some people are working on getting Cabal to build shared libraries. That would be excellent for us. See haskell/cabal#141

[abooij]

Using a development version of cabal, the library can now be built and installed by cabal without any hacks. (Relevant .cabal section in added in 3db3ec3, see haskell/cabal@382143a for the cabal commit that introduces foreign-library)

[abooij]

I am working on some cabal patches that should make it really really easy to use sudbury. Eventually, one will be able to run wayland programs using the sudbury implementation of libwayland using cabal exec, e.g.:

$ cabal exec weston-flower

(instead of $ weston-flower).
This will require cabal >= 1.25.