Open bladyjoker opened 2 years ago
After the fixes are applied this is the result of hls invocation. I'd push the branch here but I don't have access.
[nix-develop:~/Desktop/plutus-use-cases/mlabs]$ haskell-language-server-wrapper
Files that failed:
* /home/bladyjoker/Desktop/plutus-use-cases/mlabs/Setup.hs
* /home/bladyjoker/Desktop/plutus-use-cases/mlabs/demo/Main.hs
* /home/bladyjoker/Desktop/plutus-use-cases/mlabs/src/Mlabs/NFT/Api.hs
Completed (98 files worked, 3 files failed)
@bladyjoker can you create a PR from your fork into staging?
Thanks @zygomeb the PR is #308
Hi Dražen, thanks for the fixes you've provided. I've been working with HLS for a while, and we recently migrated to nix flakes and thought I'd give it another shot. Ironically, I ended up at this issue after independently performing the first two fixes and searching for a solution to the third.
That said, I'd actually like to reopen this.
The
GHC runtime linker: fatal error: I found a duplicate definition for symbol sqlite3_fts3_may_be_corrupt
error is giving us issues over in LiqwidX, and causes HLS to fail on (essentially) the entire project.
I'm not 100% sure of the progeny of our nix setup, but I'd imagine that there's a common ancestor between this repo and LiqwidX, and given that this has been plaguing us for a while, I think it is worthwhile to track down the root cause and fix it where-ever it lies.
Hi Peter, please do reopen, if you're working towards fixing HLS and have it seamlessly run in our nix/flake/* environments all the power to you! Let me know if I can help somehow.
Sounds good. I'm not seeing an option to re-open on github, so I may not have the correct permissions. But I will be sure to keep you (and this issue) updated if I find a solution :)
I just hit this issue again
GHC runtime linker: fatal error: I found a duplicate definition for symbol
sqlite3_fts3_may_be_corrupt
whilst processing object file
/nix/store/w43xg9ni6gk28ndl1mgzlinb2dxxpdci-persistent-sqlite-lib-persistent-sqlite-2.13.0.3/lib/x86_64-linux-ghc-8.10.4.20210212/persistent-sqlite-2.13.0.3-8rnIaulr0SMFWDeiU7TZN4/HSpersistent-sqlite-2.13.0.3-8rnIaulr0SMFWDeiU7TZN4.o
The symbol was previously defined in
/nix/store/ck5zqxqir93dighfhr2rkxr09bwv7qsk-direct-sqlite-lib-direct-sqlite-2.3.26/lib/x86_64-linux-ghc-8.10.4.20210212/direct-sqlite-2.3.26-Gg0YVBPVrMk3LDxZxB2Bzf/HSdirect-sqlite-2.3.26-Gg0YVBPVrMk3LDxZxB2Bzf.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
Right, let me reopen this issue. I don't think anyone on our team uses HLS so it does slip under our radar
Is this a duplicate of https://github.com/mlabs-haskell/liqwidx-contracts/issues/102, or is there more to it?
It happens to me wheenever I use the nat
quasiquoter.
Unless someone can reproduce elsewhere, I would suggest closing both these issues in favour of an issue on https://github.com/Liqwid-Labs/plutus-extra, at least until we get a bit more insight.
Is this a duplicate of mlabs-haskell/liqwidx-contracts#102, or is there more to it?
They are duplicates. I didn't think everyone had access to the private Liqwid repos, and stumbled across this issue when I was searching for solutions a few weeks back.
I was also able to trace it to the Nat quasiquoter, alongside the conflicting SQL libraries on the issue you linked.
Hi there, I've been going through the repo code base, generally trying to figure out the build system, setting up the dev environment (emacs, lsp/hls, nix) and reading through code. However, I kept running into issues while using HLS so I wanted to share my findings here just in case they are relevant and actual.
In summary the following types of errors occur...
The package mlabs-plutus-use-cases has no file target
Seems like HLS and Cabal can't find under which component the source file should be built.
which I tried out manually with:
The fix seems to be to update the hie.yaml file with appropriate path -> component mappings.
Program error: GHC Core to PLC plugin: E043:Error: Reference to a name which is not a local, a builtin, or an external INLINABLE function
The fix seems to be simply add the
-fplugin-opt PlutusTx.Plugin:defer-errors
GHC flag, however I'm not sure whether it's safe to simply add it unconditionally.GHC runtime linker: fatal error: I found a duplicate definition for symbol sqlite3_fts3_may_be_corrupt
During linkage this error is raised as the same symbol seems to be defined by different libs.
Not sure what the fix would be for this one, however, it seems to be affecting only this one file.