I need to compile some code starting from the GHC version 7.0.4 until the most recent 8.0.2.
I know that using stack I can do something like:
stack init --resolver lts ...
on the local project but the lts versions don't go further than GHC 7.8.3.
How can I switch back to older version of GHC without using stack?
No, you cannot have stack use ghc 7.0.4 because it's not in their snapshot. The oldest compiler stack supports is 7.8.3.
Theoretically, stack can provide support for older compilers, but the Stackage server was announced at August, 2014 and GHC 7.0.4 was released on June, 2011. That's my educated guess of why 7.0.4 is not present.
If you want your code to have support for older compilers, I would recommend you to use a CI system like Travis. Another alternative if you are using a Ubuntu machine is to use Herber's PPA for installing the older compilers.
Do you really need stack to build the project, i.e. stack.yaml and stack build?
If it is not the case and you just want multiple ghc versions, you might want to try
nix, it have various ghc versions.
But keep in mind that older than 8.0.2 is not officially support but it might still working.
docker, use it to setup any version you want
travis, as previous answer suggested.
Related
I'm trying to install the accelerate library from hackage, but it keeps giving me an error saying that my version of base package (4.15.1.0) is too new. Is there a way to force it to ignore the base package that's installed as a system-wide package, and instead download the correct version of the base package?
I'm using Manjaro Linux, ghc version 9.0.2, and cabal version 3.4.0.0. I can't seem to find any documentation on how to force it to ignore a system package. I've tried searching on https://cabal.readthedocs.io/en/3.6/ , but it doesn't seem to mention it anywhere.
The base package is always hard-fixed to the compiler version. The only way to switch base is to switch to a different GHC. That's easier with Stack than it is with Cabal-install – just select a snapshot that has a suitable base version (lts-18.24 would do), and Stack will automatically install the corresponding compiler.
But it could well be that you can actually use base-4.15, and just accelerate has conservative dependency bounds. Try installing it with --allow-newer=base. If that works, give the maintainers a PR that the version bounds can be relaxed.
I have two haskell versions downloaded. 8.6.5 and 8.2.2.
The last thing I did was running stack upgrade in the cmd. But I don't know how to change from one version to the other.
PD: I'm using Windows
if you're using stack, the lts gives you the compiler version. For example lts 14.9 is compiler version 8.6.5 (correspondeces in official webpage).
What's important to remember is that when executed outside a project folder, stack picks up the global configuration (typically at ~/.stack/global-project/stack.yaml). The confusion comes from the fact that global configuration may have a different lts than project configuration. In such case stack will download both version and use each depending on the enviroment it is executed (global or project).
As a recommendation, pick up a lts and use it in your global config and project config so you'll avoid stack downloading many different versions of haskell compiler.
I've installed the Haskell platform which came with the 7.10.2 version of ghc and the 1.22.6.0 version of cabal. My favorite editor is Atom, so I've installed the ide-haskell and haskell-ghc-mod. Since the ghc-mod has some problems with cabal>=1.22, I need to downgrade cabal. Haskel platform came with an activate-hs script to switch versions but I didn't understand how it works.
The ./activate-hs script only switches between different already installed platform versions. So if you don't have a prior version of the platform installed it won't help. More generally, you should not probably not downgrade cabal versions, as often compilers are coupled to particular releases of cabal.
But if you did want to, the correct way would just be to create a sandbox and then run cabal-install cabal-install-1.20.2.0 or the like. You can then take the resultant binary and move it into your path directly.
Redhat 5 has the required 2.6.18 kernel but not the latest glibc, g++ and certainly no clang. The binary distribution doesn't run, complaining about glibc version.
Has anyone made an attempt to back port to old Linux? I could imagine cobbling together a frankensystem with an old kernel but new compilers and try to compile against old glibc or statically compile in some of new glibc but it seems like a fraught course.
Just wondering if anyone has tried and can offer guidance?
I'm thinking there must be a distro setup to do such builds. Anaconda, for example, includes lots of new technologies but works fine on Redhat 5. I wonder how they build it?
Update: Once you get some newer compilers working on RHEL5 it's still not possible to build Rust because it depends on a working binary of itself to bootstrap. See: https://github.com/rust-lang/rust/issues/9545#issuecomment-54865031
Anaconda packages are built against CentOS 5 (which is equivalent to Redhat 5). The important thing is to compile against an old enough glibc, as it is strictly forward compatible (as you saw). The version of glibc is typically tied to the version of the distro, so your best bet is to make a VM with CentOS 5 and build on that.
The version of the compiler used is not as important, and in fact in some cases it is necessary to use a newer compiler than the old one that comes with the system to get things to work. I have gcc 4.8 built for CentOS 5 which you can get with conda (conda install -c asmeurer gcc).
I hit this very issue this weekend, because Skylight supports Linux 2.6.18, including CentOS 5.10, and we use Rust in our agent.
Alex Crichton of the Rust core team was kind enough to get this working again by using CentOS 5.10 boxes for the build, which uses glibc 2.5 and Linux 2.6.18.
A C program compiled here runs fine on our Ubuntu servers. But when a somebody else tries to run it on their particular Linux server they get the following errors:
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./myprog-install)
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.7' not found (required by ./myprog-install)
Do I need to upgrade our glibc libraries and recompile? Or are they missing something on their server?
If I run apt-cache show libc6 my Ubuntu tells me the version is:
Package: libc6
Priority: required
Section: libs
Installed-Size: 9368
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss#lists.ubuntu.com>
Original-Maintainer: GNU Libc Maintainers <debian-glibc#lists.debian.org>
Architecture: i386
Source: eglibc
Version: 2.11.1-0ubuntu7.10
If I look at http://packages.ubuntu.com/hardy/libc6 the current version appears to be 2.7-10ubuntu8.1.
I'm confused by the numbers. On the one hand 2.11-1-0 is a higher number than 2.7-11. On the other hand 7.10 is a lower number than 8.1.
Is it just a matter of me upgrading the C library package and recompiling do you think? Or is the other person's server missing some needed library there for compatibility?
You have built on glibc-2.11 system. You are trying to run on a system with glibc-2.3 or older. That's not going to work.
Is it just a matter of me upgrading the C library package
No: upgrading your glibc will only make things worse.
You may want to try solutions listed here.
Is this something we can reasonably request the other party to upgrade their system to support, rather than downgrade our compiler?
Usually the client will strongly resist requests to upgrade their system: it's working fine for them as is, and any upgrade can break other existing applications.
If you are planning to distribute binaries on Linux (as opposed to building them on the target system), then you need to learn how to make binaries that will run everywhere, or you need to state your requirements (minimum kernel and libc versions, etc.) and turn clients who can't meet these requirements away.
Update:
Why did they get two errors. Why didn't they just get one for GLIBC_2.11.1 which is apparently what I built with?
Symbol versioning doesn't work that way.
When a new symbol is introduced, it is marked with the current libc version, e.g. readdir64##GLIBC_2.2, posix_spawn##GLIBC_2.15, etc.
When you link a program that uses both of the above symbols, and try to run it on e.g. glibc-2.1 system, you would get two errors.
But if you link a program that doesn't use any of the above symbols, e.g.
int main() { return 0; }
then your program will just run without any errors.
Update 2:
they don't have to add both GLIBC_2.4 and GLIBC2.7 to their Linux system, do they?
No, they don't. The GLIBC_2.11 will have all the previous symbols in it. In fact, they couldn't install both glibc-2.4 and 2.7 even if they wanted to: it is quite difficult to have multiple versions installed at the same time, and impossible to have multiple versions installed in default location.
You've built it against a version of glibc that is too new. Build it against an older version of glibc, preferably the one that they are using.
you need to build on a system that uses same versions of libraries as you do. This is where docker and VM's are very convenient. There is probably a pre-made docker image for whatever version the customer has.