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.
Related
I am running stack Version 2.1.3, x86_64 hpack-0.31.2 on cygwin. A Haskell project that I am trying to build requires the use of regex-pcre-0.94.4 which in turn requires the pcre library. The exact message I get is:
$ stack build
regex-pcre> configure
regex-pcre> Configuring regex-pcre-0.94.4...
regex-pcre> Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe: Missing dependency
on a foreign library:
regex-pcre> * Missing C library: pcre
regex-pcre> This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is already
installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
There does not seem to be an easy way of obtaining a relatively recent version of pcre binaries for Windows (the ones at http://gnuwin32.sourceforge.net/packages/pcre.htm are too old for my purposes). There is a video showing how to build the binaries from source but before I go that route, there are some relatively recent precompiled binaries available at https://github.com/dragokas/PCRE but I have no idea what to do with them or where to place them. This is beginning to look like a lot of work that I am wondering if its worth it or I should just drop the idea of doing it in Windows and move to Linux. Any ideas or suggestions?
PS. I also notice that cygwin already has a pcre library (/bin/cygpcre2-16-0.dll). but as this looks like a 16-bit library I assume it won't work, and again I am not sure how to tell stack to use this.
Here I found the answer:
regex-pcre doesn't support Windows, at least the current
regex-pcre.cabal doesn't work well on Windows.
Try regex-pcre-builtin, it's the same as regex-pcre, but with
PCRE sources bundled in. I don't know why the author doesn't merge it
into regex-pcre, but creating a new package for this.
I had to change only name regex-pcre to regex-pcre-builtin (as versioning is the same) in my .cabal file that installs dependencies with stack build. (example: ./your-project-name.cabal)
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.
I am trying to build a program as most others available on linux:
configure, make, make install.
However when I try to configure it I get the following message:
checking for gtk-config... no
checking for GTK - version >= 1.2.0... no
*** The gtk-config script installed by GTK could not be found
*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GTK_CONFIG environment variable to the
*** full path to gtk-config.
configure: error: Cannot find GTK: Is gtk-config in path?
I have got gtk 2.x on the host machine. And when I run which and locate on gtk-config I get nothing back. Since I have the source what patches can I apply to fix this?
You need to install the development files for GTK 1.2; the name of the package depends on your distribution.
I'd like to warn you, though, that GTK 1.2 was last released 15 years ago, in 2001, and hasn't been updated since — which also implies that the application you're trying to build is also hopelessly outdated.
GTK+ 2.0.0 was also released in 2001 and it's currently in deep maintenance mode (the latest version is 2.24.29 and was released in 2015); GTK+ 3.0.0 was released in 2011, and it's the currently developed version of the API.
You cannot really apply patches to compile an application written with the GTK 1.x API using any newer major versions of GTK+ (e.g. 2.x or 3.x); each time the major version of GTK is bumped, the API is changed in a non-compatible way. You would need to port the application to the new API.
Additionally, if an application depends on GTK 1.x it's also likely that it will depend on older versions of existing libraries; or deprecated ones. You will need to find all the dependencies and ensure that they can be installed in parallel with the ones you have installed in your system.
You could try using the compatibility wrappers developed by OpenSUSE team that try to emulate GTK1.2 by some wrappers and/or automatically patching source code to be compiled, to be able to use GTK2.0 instead.
Have a look at https://github.com/openSUSE/gtk1-compat - perhaps it may work for you. I didn't test it, however, myself.
I have the latest Haskell Platform (2012.2.0.0) 64bit OSX. But.. I have run into an issue with the 64bit compiler on Mac, which means that yesod devel crashes as soon as it starts.
I can't swap to the 32 bit version because of completely different issues with getting GTK+ to work.
I see the issue with GHC is fixed in 7.6.1 but the latest HP comes with 7.4. So, can I install GHC 7.6 on top of my working HP installation, or is that going to screw everything up?
Yes just install it in a separate directory and remember to change your path each time you wanna use it with the different versions, or change the name of the simulink in your bin like how mac ports does i.e. for instance in my bin i have ghc , ghc-7.4.1 and ghc-7.4.2 which are all different versions.
so in your case i would create two simulinks in /bin ghc-32 and ghc-64 for each of the two separate versions
Also it is important not to forget to CHANGE YOUR INSTALL PREFIX each build, usually denoted by --prefix when compiling GHC
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.