`tidal-listener` builds in Nix are failing on 1.9

[matthewkaney]

Currently, the Nix build of tidal-listener is failing on 1.9-dev with a pretty cryptic error message. My vague sense from searching around is that this means GHC is not loading some internal interfaces in the correct place? We disabled tidal-listener builds in main because of potential 2.0 incompatibilities, but I don't think that's the issue here—in particular, the listener seems to build fine outside of nix.

Here's an example the error in question

I know that the listener needs to be compiled with the --dynamic flag (or at least does on Windows?) Perhaps some nuance of the compilation setup isn't getting applied correctly in the nix build?

I don't know anything about nix, and only slightly understand the tidal-listener, so @mitchmindtree or @polymorphicengine, do either of you have any thoughts about what might be going on here? Thanks so much :sweat_smile:

[mitchmindtree]

After a quick look I'm not too sure off the top of my head :thinking:

Curiously, while nix build .#tidal-listener fails, doing nix develop and then cd tidal-listener && cabal run appears to work without issue. This does indicate there's some kind of impurity in the non-nix cabal build approach that we're not capturing in the tidal-listener flake package output.

Could you elaborate on the need for --dymanic you mentioned? Does cabal try to link to a system dynamic libs while building tidal-listener or something?

[mitchmindtree]

I kept your --dynamic hint in mind and had a look at tidal-listener.cabal file.

It looks like commenting out these ghc-options: -dynamic-too lines in the tidal-listener.cabal file allows nix build .#tidal-listener to work without issue.

https://github.com/tidalcycles/Tidal/blob/5d20eecb303a2669d0f5d475f40c8cc7f679521e/tidal-listener/tidal-listener.cabal#L37-L38

The reason it was added appears to be something to do with haskell-lint? This issue is linked above:

https://github.com/haskell-hint/hint/issues/156

@polymorphicengine it looks like that issue has since been closed, but I'm unfamiliar with haskell-hint - are we able to remove the -dynamic-too ghc option? If so that would make this an easy fix :smile:

[polymorphicengine]

i'm not completely sure, but i think the dynamic flag should be enough, i only found this fix through experimenting and it might well be that i added the dynamic-too flag without good reason.. it is very hard to verify though, since a successful build will not mean it working automatically... someone with nix would have to try it out for us

[mitchmindtree]

I can confirm that removing the -dynamic-too ghc option makes it possible to build and run tidal-listener successfully with Nix (on linux at least). Or were you referring to checking that haskell-hint continues to work?

[polymorphicengine]

yes, not sure if hint will still work,.. on that note i'm not sure if any of the builds actually would work with the dynamic flag, i think we are at a state where if someone wants to use tidal-listener they have to compile themselves anyways (using the dynamic flag)

this whole issue is unfortunately very confusing and i'm pretty much at the end of my wits (see the now closed immense issue on the hint github)

[matthewkaney]

We already disable Nix tidal-listener builds for unstable 2.0 Tidal. Should we also disable them for 1.9 and leave it at that?

(For what it's worth, I've been learning how to implement new programming languages partially in order to avoid learning how hint works 🙂)

[polymorphicengine]

(For what it's worth, I've been learning how to implement new programming languages partially in order to avoid learning how hint works 🙂)

nice! not to discourage, but writing our own interpreter would be quite an immense effort (unless we introduce some big restrictions, like in estuary tidal where every function basically becomes a keyword)

anyways, if you like to talk about it sometime hit me up :)