cabal install Cabal fails with "cannot find -lgmp", even though libgmp-dev is installed

[OscarSouth]

cabal install Cabal (or any other method of installation) fails with the following message:

[221 of 221] Compiling Distribution.Simple ( Distribution/Simple.hs, dist/build/Distribution/Simple.o )
/home/oscarsouth/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.2.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld.gold: error: cannot find -lgmp
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
cabal: Leaving directory '/tmp/cabal-tmp-3771/Cabal-2.2.0.1'
cabal: Error: some packages failed to install:
Cabal-2.2.0.1-4uyMvBhckykFcd8G4y9p9B failed during the building phase. The
exception was:
ExitFailure 1

However, libgmp-dev is installed

$ cabal --version
cabal-install version 2.2.0.0
compiled using version 2.2.0.0 of the Cabal library 

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.1

$ sudo apt update && sudo apt install libgmp-dev
Hit:1 http://ie.archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://ie.archive.ubuntu.com/ubuntu bionic-updates InRelease             
Ign:3 http://dl.google.com/linux/chrome/deb stable InRelease                   
Hit:4 http://security.ubuntu.com/ubuntu bionic-security InRelease              
Hit:5 http://ie.archive.ubuntu.com/ubuntu bionic-backports InRelease           
Ign:6 http://repo.vivaldi.com/stable/deb stable InRelease                      
Hit:7 http://dl.google.com/linux/chrome/deb stable Release               
Hit:8 http://repo.vivaldi.com/stable/deb stable Release                  
Reading package lists... Done                      
Building dependency tree       
Reading state information... Done
All packages are up-to-date.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libgmp-dev is already the newest version (2:6.1.2+dfsg-2).
0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.

[OscarSouth]

Further note to add that this is preventing me installing anything through Cabal at all.

Ubuntu 18.04

[23Skidoo]

Can you compile a C program that uses -lgmp with gcc?

[OscarSouth]

I’m not sure how to know if that is needed for these but I compiled both ghc and cabal-install from source.

I recently installed these things in the same process on a different OS without issue (this is Ubuntu 18.04 beta, that was AVLinux Debian).

[hvr]

Where did you install GHC from? For Ubuntu 18.04 I'd recommend using the ghc packages from my PPA https://launchpad.net/~hvr/+archive/ubuntu/ghc which track dependencies such as libgmp-dev automatically.

[OscarSouth]

Ah I see that this does have the versions I’m looking for. I just ‘automatically’ followed the same process which had previously worked for me on the Debian system, but I’ll try this ppa for Ubuntu - logically it seems like it should solve the problem.

[OscarSouth]

Update:

Added that ppa and installed ghc, cabal-install & stack. Getting the same message with all.

This is from a stack setup:

[1 of 1] Compiling Main             ( /tmp/stack-sanity-check1040/Main.hs, /tmp/stack-sanity-check1040/Main.o )
Linking /tmp/stack-sanity-check1040/Main ...

/home/oscarsouth/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.2.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld.gold: error: cannot find -lgmp
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

I've also installed zlib1g-dev and libmemcached-dev.

Very probable that I've caused this by building the source version first. This is a fresh OS install so I'm going to refresh it in an hour or so and see if the behavior changes.

[OscarSouth]

Completely fresh Ubuntu install, fully updated/upgraded install of haskell-stack installed using apt install method (no other Haskell related software installed on the system):

for more information. Exception was:
Running /home/oscarsouth/.stack/programs/x86_64-linux/ghc-nopie-8.2.2/bin/ghc /tmp/stack-sanity-check2177/Main.hs -no-user-package-db in directory /tmp/stack-sanity-check2177/ exited with ExitFailure 1

[1 of 1] Compiling Main             ( /tmp/stack-sanity-check2177/Main.hs, /tmp/stack-sanity-check2177/Main.o )
Linking /tmp/stack-sanity-check2177/Main ...

/home/oscarsouth/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.2.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld.gold: error: cannot find -lgmp
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

[23Skidoo]

@OscarSouth What happens if you try to compile and run this example with gcc: https://gmplib.org/list-archives/gmp-discuss/2008-March/003085.html ?

[hvr]

The part that confuses me is this occurence of /home/oscarsouth/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.2.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld.gold:

that's not what you'd get on a "fresh ubuntu" install; you seem to be having a custom/different ld/ld.gold in your $PATH that isn't supposed to be there (possibly with custom library search paths, which would explain the inability to find the system-wide libgmp)

[sgraf812]

I'm having problems with a nix setup on Ubuntu 18.04 and am getting the same errors. It's probably related to ld.gold.

Edit: Although it's only happening when going through stack for me.

[OscarSouth]

Apologies for the delay - lot of balls in the air at the moment.

@hvr I installed Miniconda before stack. I also noticed that message and assume that there's some conflict involved. I previously (in that case) got it working temporarily by installing a system level ghc externally and instructing stack to use that. I reformatted my system to an Arch Linux based install and installed in the reverse order - doesn't seems to have caused an issue so far but I'll report back if anything comes up.

Maybe worth noting that installing Anaconda/Miniconda before stack can cause an issue.

[23Skidoo]

Looks like this was some system configuration fiasco, so not a bug in cabal-install. Closing.

[toelli-msft]

I've just come across a similar problem in an internal support ticket. I don't know a solution (perhaps disable Conda, perhaps install gmp into conda? I don't know.) I do want to leave this diagnostic tool for anyone who comes across errors to do with not being able to find libgmp. Please run the following:

echo -e '#include <gmp.h>\nint main() { mpz_t integ; mpz_init(integ); return 0; }' > /tmp/foo.c
gcc -o /tmp/foo /tmp/foo.c -lgmp
ldd /tmp/foo

[tomjaguarpaw]

I can now explain one reason why this might happen. An Anaconda environment with gcc and ld installed (conda install gcc_linux-64 binutils) will have $CC and $LD set, amongst other "helpful" environment variables.

$ echo $CC && echo $LD
/home/test/anaconda3/bin/x86_64-conda_cos6-linux-gnu-cc
/home/test/anaconda3/bin/x86_64-conda_cos6-linux-gnu-ld

If ghc is installed via ghcup then ./configure runs during the install process picking up the locations for cc and ld from these environment variables (or PATH or perhaps something else in the environment, I'm not sure).

checking whether we are using the GNU C compiler... yes
checking whether /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-cc accepts -g... yes
checking for /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-cc option to accept ISO C89... none needed
checking how to run the C preprocessor... /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-cpp
checking for /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-cc option to accept ISO C99... none needed
checking for /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-cc option to accept ISO C99... none needed
checking for /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-cc option to accept ISO C99... none needed
checking for -ld... /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-ld
...
checking for ranlib... /anaconda/envs/py37_default/bin/x86_64-conda_cos6-linux-gnu-ranlib

Then it creates a file ~/.ghcup/ghc/<version>/lib/ghc-<version>/settings containing, amongst other things,

[...
 ("Haskell CPP command","/home/test/anaconda3/bin/x86_64-conda_cos6-linux-gnu-cc"),
 ("ld command", "/home/test/anaconda3/bin/x86_64-conda_cos6-linux-gnu-ld"),
 ...
 ("ranlib command", "/home/test/anaconda3/bin/x86_64-conda_cos6-linux-gnu-ranlib"),
 ]

Now every time that ~/.ghcup/ghc/<version>/bin/ghc is run it will look in this file to discover which gcc and, more importantly for this bug, which ld it should use. It will forever use Anaconda's ld, even you are not using it within an Anaconda environment! I believe the same will apply to ghc installed via Stack or via the source or binary distributions on haskell.org but I am not certain. ghc installed via a Linux distribution package manage will probably not experience this problem because the contents of the settings file will have been determined at package build time, not package install time.

This behaviour might even be OK if Anaconda could provide libgmp straightforwardly. It does not. I'm not sure what incantations one is supposed to utter to expose Anaconda's gmp to Anaconda's ld but it is not accessible by default. I have to specify both -I and -L flags to Anaconda's bare gcc to get it to find the libraries that were installed through Anaconda itself.

(base) $ conda install gcc_linux-64 gmpinux-64 gmp
Collecting package metadata (current_repodata.json): done
Solving environment: done

# All requested packages already installed.
(base) $ echo -e '#include <gmp.h>\nint main() { mpz_t integ; mpz_init(integ); return 0; }' > /tmp/foo.c/foo.c
(base) $ x86_64-conda_cos6-linux-gnu-gcc -o /tmp/foo /tmp/foo.c -lgmp
/tmp/foo.c:1:10: fatal error: gmp.h: No such file or directory
 #include <gmp.h>
          ^~~~~~~
compilation terminated.
(base) $ x86_64-conda_cos6-linux-gnu-gcc -I$HOME/anaconda3/include -o /tmp/foo /tmp/foo.c -lgmp
/home/test/anaconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
(base) $ x86_64-conda_cos6-linux-gnu-gcc -I$HOME/anaconda3/include -Lanaconda3/lib -o /tmp/foo /tmp/foo.c -lgmp && ldd /tmp/foo
        linux-vdso.so.1 (0x00007fffef447000)
        libgmp.so.10 => /home/test/anaconda3/lib/libgmp.so.10 (0x00007fcd3c7b0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcd3c3b0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fcd3cc00000)

I am not aware of any way of telling cabal or ghc to pass these flags to the toolchain subprocesses it calls, but one wouldn't want to have to do that anyway; it's far too messy.

Given the directory that gmp and its headers are in this problem must apply to every package that's installed via Anaconda. I don't know how Anaconda users are supposed to access the libraries they have installed through it. Perhaps with Make CFLAGS, configure, or something else.

Summary

If you installed ghc through ghcup, stack or the source or binary distributions whilst an Anaconda environment containing ld was active you will probably end up with a broken ghc that will not be able to compile anything without low level surgical intervention. I recommend deleting what you installed (e.g. ghcup rm <version> or even rm -r ~/.ghcup) and starting again whilst Anaconda is not active.

[quinn-dougherty]

Thanks tomjaguarpaw for a thorough explanation. I had the same problem without ghcup just stack, and after uninstalling and reinstalling stack a few times I gave up and sudo rm -r ~/anaconda3 haha. seems to have worked perfectly.

[shamiek]

Yes, I had to remove anaconda3 too from Ubuntu 18.04. Thank you.

[FredericLatour]

Pop-os 22.04 here (basically an ubuntu).
No Anaconda install and same problem.

Fresh installation through ghcup (I didn't install stack )

mkdir graham-hutton-haskell && cd graham-hutton-haskell
cabal init
cabal run

Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - graham-hutton-haskell-0.1.0.0 (exe:graham-hutton-haskell) (first run)
Preprocessing executable 'graham-hutton-haskell' for graham-hutton-haskell-0.1.0.0..
Building executable 'graham-hutton-haskell' for graham-hutton-haskell-0.1.0.0..
Linking /home/frederic/devel/learning/graham-hutton-haskell/dist-newstyle/build/x86_64-linux/ghc-8.10.7/graham-hutton-haskell-0.1.0.0/x/graham-hutton-haskell/build/graham-hutton-haskell/graham-hutton-haskell ...
/usr/bin/ld.gold: error: cannot find -lgmp
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

Any clue ?

[ulysses4ever]

@FredericLatour it may be better to open a new issue, as yours look sufficiently different.

Have you tried #5280 (comment)?

[ulysses4ever]

Also, have you installed both of libgmp10 and libgmp-dev? https://www.reddit.com/r/haskellquestions/comments/sxvcas/comment/hykh0uv/

[tomjaguarpaw]

@FredericLatour Have you inspected the contents of ~/.ghcup/ghc/<version>/lib/ghc-<version>/settings as per #5280 (comment)? Does it contain what you expect? Can you paste it here?

[FredericLatour]

@ulysses4ever @tomjaguarpaw
Thanks for the help guys.

After reading the reddit link, I just installed the mentioned libs

sudo apt-get install libgmp10 libgmp-dev

And it worked.

It's entirely possible that I didn't pay attention to some message telling me those libs were missing.

That being said, it would be a good idea to add, on the ghcup installation page, a warning/recommendation to pay attention to any message related to missing libs.

Haskell language seems like a thing of beauty, however setting up a working env is really challenging.
Not to mention the stack / cabal part. From my readings, I get that:

• Stack was supposed to be the needed modern tooling required by any mordern langage, however, it seems that stack development has slowed down while cabal is catch up.

I had therefore decided to start my Haskell journey without installing stack, however, for some reason, vscode extension says that I need to download stack-2.7.5.
If you don't mind sharing, would you recommend stack over cabal ?

In any cases, thanks for pointing me into the right direction.

[Mikolaj]

Frankly, I'd start minimalist. A text editor, cabal or stack in a terminal. Make sure you are able to do all basic things and learn how it all works. It's not too complex. If you are modifying a project that has a well maintained stack configuration file, go with stack. If not, I'd use cabal.

HLS adds a lot of value (that's the extension, right?) and vscode probably adds too much value, but they come with their own problems and postpone the moment you feel in control, if ever.

[FredericLatour]

@Mikolaj Thanks for the suggestion. However, vscode being my everyday editor, I'd rather stick with it..

[Mikolaj]

Oh, apologies. In any case, stack uses cabal under the hood and they are not that different, until you need to port a large project to a newer GHC (at which point with cabal it's instant, but the project crashes, and with stack it's super slow and if you use a standard enough set of packages and versions, the project works), so don't worry.

[bgamari]

For what it's worth, my sense is generally that int-native would be a better default choice. However, I would like to have some benchmarks to be certain that we aren't catastrophically regressing any bignum operations.

[FredericLatour]

My linux install is somewhat messed up since I tried to install haskell missing libs.
Wouldn't it be possible to have an up-to-date development container?
It would at least make it way simpler to test/learn the language without going into circles.

[Mikolaj]

Wouldn't it be possible to have an up-to-date development container?

I hope there are many Haskell dev containers. E.g., here is one family focused on static linking: https://github.com/utdemir/ghc-musl/. We even use a container in our CI, I think, but that one is ancient.

[hasufell]

Wouldn't it be possible to have an up-to-date development container?

I hope there are many Haskell dev containers. E.g., here is one family focused on static linking: https://github.com/utdemir/ghc-musl/. We even use a container in our CI, I think, but that one is ancient.

ghc-musl container is not necessary. In CI we just use alpine. That's enough.

[FredericLatour]

I was thinking of a “VS Code” development container.

When I decided to learn Haskell, finding a VS Code dev container was my first bet (practical, easy to install, ...).
I could find one that was unfortunately not updated (https://github.com/hmemcpy/haskell-hie-devcontainer). On the GitHub page, they recommend using the “now” official dev container. However, the link points to an endless discussion that don't really make sense for someone just trying to get to learn the language.
Reading the discussion, I could find some dev container made by some guy. However, it didn't work: I can't remember exactly, but they were various problems.
That's when I decided to install Haskell directly on my machine. I mean, I'm using Linux, that should be trivial.
Well, in the end not so much either.

Of course, it's open source and I can't assume anything for granted. That being said, having an official VS Code dev container available directly from the Haskell website would be, in my mind, a game changer for leveraging Haskell learning or adoption.

[Mikolaj]

Right. I'm afraid it may be hard to find any volunteer here. The same with GHC HQ and Haskell.org. I think people decided to focus on ghcup and not confuse newcomers with a dozen options in various stages of decay or just not updated to the latest toolset for a month or two, which is absolutely reasonable, but a horror to a neecomer that tries to follow the newest tutorial or fool around with a new feature from latest release notes.

Perhaps on any of the Haskell-VS forums people can be persuaded or they already use something like that. Really no idea. Please stick around, though. :)

[hasufell]

Well, in the end not so much either.

That's too unspecific to make someone help you.

[FredericLatour]

@hasufell In the end, things seem to be working now but here is my experience :

• following my unfortunate experience trying to get a VS Code dev container working, and reading a few comments here and there on how ghcup was easy and straightforward (indeed the website makes it sound like it's a piece of cake), I decided to install Haskell directly on my machine using ghcup (believing that this would be trivial on linux).
• Unfortunately, things didn't work after ghcup installation as I explained in this post: cabal install Cabal fails with "cannot find -lgmp", even though libgmp-dev is installed #5280 (comment)
• One of the links I was provided with mentioned installing some libs. That's what I did and it worked.
• however, later on, I realized that I could not update my system anymore.
• After reading a couple of articles, I had to do some configuration and fix install (that was related to some libs I had to install for my Haskell installation to run) so that I could update my system again. Don't ask me the exact details, I accepted to do things without understanding what was exactly going on, as I had other things to do.

Just to say that the overall experience in order to get a working Haskell config was really painful.

I had the project of having my son learn the language as well, but he is running windows, and I'm not sure if I want to mess up with his config.

A properly configured "VS Code" development container would make it for a way better experience.

[Mikolaj]

@FredericLatour, thank you for sharing. I really appreciate the time you spent beyond just getting things fixed for yourself. In a better world somebody would even be able to act on it, but oh well. :)

[hasufell]

It's entirely possible that I didn't pay attention to some message telling me those libs were missing.

Yes, you didn't pay attention.

That being said, it would be a good idea to add, on the ghcup installation page, a warning/recommendation to pay attention to any message related to missing libs.

In my experience people who don't pay attention to prompts (you have to press enter when it tells you to install the libs) also won't pay attention to details on the website.

Duplicating existent clearly visible information is not the solution.

You went on doing some configuration and further installation and a distro upgrade or whatnot, not remembering any of it. Which leads me to believe you didn't pay attention to what you did there either.

For people who don't want to pay attention to toolchain management at all, ghcup might not be the right choice, but something like an online playground, like https://play-haskell.tomsmeding.com/

There are more elaborate services that support Haskell and just require you to type code, I think.

[tomjaguarpaw]

@FredericLatour I'd like to echo @Mikolaj: thank you very much for the feedback. It's very helpful for us to know details about user experience so we can (hopefully) improve things. That said, I'm still confused by a couple of your points:

• however, later on, I realized that I could not update my system anymore.

• After reading a couple of articles, I had to do some configuration and fix install (that was related to some libs I had to install for my Haskell installation to run) so that I could update my system again. Don't ask me the exact details, I accepted to do things without understanding what was exactly going on, as I had other things to do.

I don't understand what this means. Are you claiming that GHCup stopped you from being able to update your Linux system somehow? Could you please elaborate?

[ulysses4ever]

@FredericLatour thank you for the overview of your experience so far. I’m really sorry you had so much trouble with setting things up and hope that you’ll get more luck in the future. This kind of environment issues (missing shared libs) is tricky to debug remotely, unfortunately… I have a question for you, though: you mention a developer container several times; could you reference a similar setup to what you have in mind about this container implemented and advertised for another language / ecosystem (Rust, NPM, whatever looks close enough to you)?

[tomjaguarpaw]

Hmm, sorry, didn't mean to reopen.

[tomjaguarpaw]

This kind of environment issues ... is tricky to debug remotely

Yes it is, which is why it would be nice to have some sort of diagnostic tool.

[FredericLatour]

@hasufell Not sure why you are being so unpleasant - do you think I'm stupid, and you are smart ? :

That being said, it would be a good idea to add, on the ghcup installation page, a warning/recommendation to pay attention to any message related to missing libs.

In my experience people who don't pay attention to prompts (you have to press enter when it tells you to install the libs) also won't pay attention to details on the website.

Before running ghcup, I clicked the following links and looked around just to check is they were any specific recommendations or even specific distro packages :

• what does this do ?
• I don't like curl

No specific warning related to possible missing libs.
Plus, the Ghcup page looks like everything is taken care of.

Duplicating existent clearly visible information is not the solution.

Being warned of paying attention to some kind of initial diagnostic message that, as far as I can see is not accessible afterward, is not "duplicating information" in my book.

You went on doing some configuration and further installation and a distro upgrade or whatnot, not remembering any of it. Which leads me to believe you didn't pay attention to what you did there either.

You got this in a crystal ball ?

For people who don't want to pay attention to toolchain management at all, ghcup might not be the right choice, but something like an online playground, like https://play-haskell.tomsmeding.com/

Sounds perfectly legit that one is not interested with the intricacies of an installation while learning or evaluating some language / platform.
A playground will usually fall short if you would like to have multiple files, etc.

There are more elaborate services that support Haskell and just require you to type code, I think.

What does that ever mean ?

[hasufell]

Not sure why you are being so unpleasant - do you think I'm stupid, and you are smart ?

Not at all. But I'm convinced that in this case the problem is the user. The ghcup homepage lists help channels for that reason, where helpful people (like me) give real time assistance.

I'm afraid your input so far doesn't allow me to improve ghcup user experience.

[FredericLatour]

@tomjaguarpaw

@FredericLatour I'd like to echo @Mikolaj: thank you very much for the feedback. It's very helpful for us to know details about user experience so we can (hopefully) improve things. That said, I'm still confused by a couple of your points:

• however, later on, I realized that I could not update my system anymore.
• After reading a couple of articles, I had to do some configuration and fix install (that was related to some libs I had to install for my Haskell installation to run) so that I could update my system again. Don't ask me the exact details, I accepted to do things without understanding what was exactly going on, as I had other things to do.

I don't understand what this means. Are you claiming that GHCup stopped you from being able to update your Linux system somehow? Could you please elaborate?

No, Ghcup is not at fault here.

This happened following the installation of a couple missing libraries. Installing those libs fixed my initial Hasell installation but, for some reason, made it impossible to update (apt upgrade) my system.
Because of some unmet dependencies, I had to dpkg config and fix-install.
Maybe I installed more libs than necessary.
Maybe if I had seen the exact libs that were missing instead of relying on an article and try and see.

[hasufell]

Yeah, I think this is not the right place for distro support. And we're not having enough information for this to be useful to others.

Please open a proper bug report if you have accurate information.

[FredericLatour]

Yeah, I think this is not the right place for distro support. And we're not having enough information for this to be useful to others.

Please open a proper bug report if you have accurate information.

@hasufell I was answering to someone else, as the quote should have told you.
Are you some kind of Haskell authority that can decide what is the right place or not ?

[ffaf1]

Bonsoir @FredericLatour, your feedback is greatly valued.
For the benefit of the larger Haskell community and to improve Haskell onboarding, can you tell me:

• which OS are you running
• which libraries were missing and
• how you installed them?

[tomjaguarpaw]

Personally I am very grateful that @FredericLatour is continuing to participate in the discussion because it's improving my understanding of how new users experience Haskell onboarding. This is the cabal issue tracker though, so we defer to them regarding whether they would like the discussion to move elsewhere.

For what it's worth, I think that when I was a new user I could easily have missed the instructions to install the necessary libraries. That's why I think a technical solution like a diagnostic tool could be useful.

[FredericLatour]

@hasufell

I'm afraid your input so far doesn't allow me to improve ghcup user experience.

A couple of suggestions though:

• making it clear from the installation page that some diagnostic is taking place pre-installation.
• mentioning in the troubleshooting section of possible overlook of missing libraries.
• Showing missing libs on user interface "tui".
• Having a diagnostic tool like suggested by @tomjaguarpaw. So as no to multiply tools, this diagnostic could be run through ghcup using some option.

That being said, I understand perfectly that you or the Haskell community doesn't owe me anything.
Those are just suggestions and experience feedback.

[FredericLatour]

Bonsoir @FredericLatour, your feedback is greatly valued. For the benefit of the larger Haskell community and to improve Haskell onboarding, can you tell me:

• which OS are you running
• which libraries were missing and
• how you installed them?

Bonsoir (did my accent betrayed me? :) ) @ffaf1

• OS: Pop_os 22.04 (a derivative of Ubuntu)
• Missing lib: Unfortunately, I can't say for sure because I had overlooked the initial diagnostic and as far as I understand things, it's not possible to get this information afterward (or maybe, I'm missing something here).
  Following the links suggested by @ulysses4ever, I went to sudo apt-get install -y libtinfo-dev libgmp10 libgmp-dev. As far as Haskell is concerned, it fixed the installation.

[Mikolaj]

This is the cabal issue tracker though, so we defer to them regarding whether they would like the discussion to move elsewhere.

Tom, please continue. There's absolutely no reason to stifle this or, currently, any other discussion on this but tracker by referring to who owns which bug tracker (I do) and what is permitted and what is not. OTOH, everybody is free to voice opinions on what kind of feedback is useful or not and to offer suggestions. Internet is a difficult medium so we can count on frequent misunderstandings and we have to gracefully go through that. :)

[FredericLatour]

@FredericLatour thank you for the overview of your experience so far. I’m really sorry you had so much trouble with setting things up and hope that you’ll get more luck in the future. This kind of environment issues (missing shared libs) is tricky to debug remotely, unfortunately… I have a question for you, though: you mention a developer container several times; could you reference a similar setup to what you have in mind about this container implemented and advertised for another language / ecosystem (Rust, NPM, whatever looks close enough to you)?

@ulysses4ever

I've successfully used those and a couple of other dev containers as well:

• F#
• Rust

Here is the github repository that contains many VS Code dev containers:

• https://github.com/microsoft/vscode-dev-containers/tree/main/containers

The VS code dev container experience is great:

• you copy the .devcontainer folder in some folder of yours where you will host your dev project.
• you launch VS Code in the folder.
• you will be asked if you want to open the dev container. (1st time, it will download the image defined in the configuration, it will also add vscode extensions as defined in the configuration files: language server, formatters, etc..)
  That's it. Your source code is local, the dev environment is in the container.

If you look at the GitHub folder, you can see there is a Haskell dev. Container. For some reasons, it didn't work for me. Now that I have a bit more insight (not much though), I may give it another try.

[jneira]

If you look at the GitHub folder, you can see there is a Haskell dev. Container. For some reasons, it didn't work for me. Now that I have a bit more insight (not much though), I may give it another try.

Just in case,there is am ongoing pr to the haskell dev container: microsoft/vscode-dev-containers#1478
Maybe it is more reliable (or at least it could save you some steps)

Also hls itself has a gitpod configuration which lets you use that online devcontainer service: https://github.com/haskell/haskell-language-server/blob/master/.gitpod.yml
That config allows open any pr of the repo in such environment; https://gitpod.io/#https://github.com/haskell/haskell-language-server/pull/2966
I have not tried it in a while so not sure if it works

[FFFluoride]

@FredericLatour Have you inspected the contents of ~/.ghcup/ghc/<version>/lib/ghc-<version>/settings as per #5280 (comment)? Does it contain what you expect? Can you paste it here?

This helped me aswell

[FredericLatour]

I haven't had much time to dedicate to Haskell those days (which is a shame as I've loved every bit of my journey with the language).

That being said, for what is worth, the vscode dev container that is provided with

• IHaskell/learn-you-a-haskell-notebook: Jupyter adaptation of Learn You a Haskell for Great Good!

works pretty well (in particular, IO as well).

For those who would like to learn the language without the hassle of installing the complete environment on their system, this is a great resource.