I have this error on windows while installing Pathfinder, which is among DSH dependencies. Is it possible to install DSH on Windows system?
D:\Devs>cabal install pathfinder Resolving dependencies... [1 of 1]
Compiling Main (
C:\DOCUME~1\kdv\LOCALS~1\Temp\Pathfinder-0
.5.103528\Pathfinder-0.5.10\Setup.hs,
C:\DOCUME~1\kdv\LOCALS~1\Temp\Pathfinder-0
.5.103528\Pathfinder-0.5.10\dist\setup\Main.o ) Linking
C:\DOCUME~1\kdv\LOCALS~1\Temp\Pathfinder-0.5.103528\Pathfinder-0.5.10\di
st\setup\setup.exe ... setup.exe: The program sh is required but it
could not be found. cabal: Error: some packages failed to install:
Pathfinder-0.5.10 failed during the configure step. The exception was:
ExitFailure 1
You can try to compile it using Cygwin or MSYS. You need at least the following command-line tools in your %PATH%:
sh
rm
cp
tar
pwd
make
ar
ld
These tools are necessary because the library uses an internal C library, which in turn uses autotools and associated configure and Makefiles, which are interpreted by sh and make respectively. If you install MSYS or Cygwin, you will have the necessary UNIX-like environment to be able to compile it.
You can of course also just install the library in a Linux environment; you'll have a much easier time because you won't have to potentially deal with MinGW version incompatibilities etc. In your position, I would at least consider installing a virtual machine running some form of Linux distribution and just do all of my development there - that's what I do on my main Windows machine. When you are ready for deployment, it is much easier to cross-compile Windows Haskell programs on Linux than actually compiling on Windows directly because you don't have to deal with version conflicts, and you also have the option to produce a Linux binary for Linux servers (which are what most RDBMS tend to run on, anyways).
Related
I am building a package with provides a wrapper around the cvode solver from the SUNDIALS ODE solving C library.
So far, I have been able to compile the package on my OS X machine by providing the source C files (taking inspiration from the Makevars from RcppCAF package) and making the static library on the fly and linking against it. The Makevars file can be found at the link below
https://github.com/sn248/Rcppsbmod/blob/master/src/Makevars
Earlier I was linking against static libraries on the system but now since I am making the static library (libsundials_all.a) on the fly when compiling the package, I believe users who don't have SUNDIALS installed on their system (at least on OS X) should be able to use this package also (Am I correct in thinking this?). I have checked the package compiled in such a way is able to integrate the a test ODE. Also, When I run a R CMD check (using Check option on RStudio, with --as-cran option), I get success, i.e.,
R CMD check results
0 errors | 0 warnings | 0 notes
However, I want users on Windows to be able to use this package, even if they don't have SUNDIALS installed on their machine, my questions are
Is this possible to do or Windows users need to have SUNDIALS installed?
Currently my Makevars.win is same as Makevars, so when I submit my package on R WinBuilder, I get the following message (which tells me that make is not able to find ar).
make: ar: Command not found
make: *** [../inst/libsundials_all.a] Error 127
Warning: running command 'make -f "Makevars.win" -f "D:/RCompile/recent/R-3.4.3/etc/i386/Makeconf" -f "D:/RCompile/recent/R-3.4.3/etc/i386/Makevars.site" -f "D:/RCompile/recent/R-3.4.3/share/make/winshlib.mk" SHLIB_LDFLAGS='$(SHLIB_CXXLDFLAGS)' SHLIB_LD='$(SHLIB_CXXLD)' SHLIB="Rcppsbmod.dll" ' had status 2
ERROR: compilation failed for package 'Rcppsbmod'
* removing 'd:/RCompile/CRANguest/R-release/lib/Rcppsbmod'
In R CMD INSTALL
Some searching revealed that RTools might not have ar,here but I don't think I am clear about what I should be doing to compile this package on Windows. I have looked a few Makevars.win files, but most of them are similar to Makevars. I feel I need to make a .dll (similar to libsundials_all.a, but I am not sure how to go about it at all.
Any suggestion here about how I can compile this package on Windows will be much appreciated!
Also, just for my curiosity, I often find code such (e.g., in Makevars.in of rcppgsl)
GSL_LIBS = #GSL_LIBS#
I am not sure what #GSL_LIBS# means and make tutorials didn't have this syntax either. Any explanation of this code will be very helpful.
Thanks!
Yes, it is possible to build a static library on Windows during package installation. I am doing that in the experimental windows branch of dqmagic:
PKG_CPPFLAGS = -I./libmagic -I./libgnurx -DHAVE_CONFIG_H
PKG_LIBS = -L. -lmagic -lregex -lshlwapi
all: $(SHLIB)
$(SHLIB): libmagic.a libregex.a
LIBMAGIC =libmagic/apprentice.o \
[... many object files ...]
libmagic.a: $(LIBMAGIC)
LIBREGEX = libgnurx/regex.o
libregex.a: $(LIBREGEX)
Note that I do not tell makehow to build a static library, leaving that to the automatic rules. That way there are no issues with ar missing. Note that the Linux/Mac OSX build uses a system installed library.
I think RcppGSL is not a good comparison in your case, since it uses an external library on all platforms. Reason is that with this package it has to be possible to compile and link with GSL after package installation. In your case, all the compilation and linking is done at installation time, right?
I'm trying to install ghc-mod for GHC 8.0.1 on windows/x64. When I try to install ghc-mod via cabal install ghc-mod I get an error saying my C compiler isn't working (it is using the c-compiler bundled with ghc).
Here is the output (of the second time I ran the command. Its basically what the first one says but reduced to the error message):
C:\Users\******>cabal install ghc-mod
Resolving dependencies...
Configuring old-time-1.1.0.3...
Failed to install old-time-1.1.0.3
Build log ( C:\Users\******\AppData\Roaming\cabal\logs\old-time-1.1.0.3.log ):
Configuring old-time-1.1.0.3...
bash.exe: warning: could not find /tmp, please create!
configure: WARNING: unrecognized options: --with-compiler
checking for gcc... C:\PROGRA~1\Haskell Platform\8.0.1\mingw\bin\gcc.exe
^ I think the error lies here, as you can see the file path is corrupted but I wasn't able to locate the cause for this
checking whether the C compiler works... no
configure: error: in `/cygdrive/c/Users/******/AppData/Local/Temp/cabal-tmp-6084/old-time-1.1.0.3':
configure: error: C compiler cannot create executables
See `config.log' for more details
cabal: Leaving directory 'C:\Users\******\AppData\Local\Temp\cabal-tmp-6084\old-time-1.1.0.3'
cabal: Error: some packages failed to install:
cpphs-1.20.2 depends on old-time-1.1.0.3 which failed to install.
ghc-mod-5.6.0.0 depends on old-time-1.1.0.3 which failed to install.
haskell-src-exts-1.17.1 depends on old-time-1.1.0.3 which failed to install.
hlint-1.9.35 depends on old-time-1.1.0.3 which failed to install.
old-time-1.1.0.3 failed during the configure step. The exception was:
ExitFailure 77
Could you please help me to install ghc-mod or provide any other way of installing it.
I already trieded reinstalling Haskell since I'm just starting off but this didn't make any difference.
And YES I added the 3 lines provided on the haskell homepage.
I can't know for certain, but thought I'd write an answer with what I think is going on.
The old-time package contains a configure script, which is a Unix shell script used to (surprise!) configure the package. The Cabal build system allows packages to automatically integrate configure, and will run the script for them. On POSIX systems, there's always a shell easily available. However, on Windows, that's not the case. I believe that's the problem you're running into.
Now the tricky part: why don't you have a shell? In theory, the Haskell Platform ships a shell. Well, here are my guesses:
For Stack usage, there's a Haskell Platform bug where Stack cannot find the MSYS tools, which include the shell script. Newer versions of Stack work around this bug, but passing in --no-system-ghc tells Stack to ignore any installed toolchain and manage the installation itself, which is more reliable than using HP's copy.
For Cabal usage, I'm less certain. I think the HP team decided to require you to use a special batch program to set environment variables correctly, so if you just run cabal install foo from a normal command window, Cabal won't find MSYS and it will fail. However, without more information, I can't be certain this is the case.
My personal recommendation: uninstall Haskell Platform, and use the recommended Stack installation instructions. In your case, that's just downloading and running the 64-bit Windows installer.
Finally: your suspected problem is not actually a problem; on Windows, pathnames longer than 8 characters can be compressed in the way you see (with ~1 at the end). There's nothing buggy in that path display.
I have decided to try to install gtk2hs on my Windows 8 (64 bit) machine. I am relying on the lastest Haskell Platform distribution.
So, I go on the wiki, and follow the instructions. I get gtk+ 32-bit distribution, version 2.24, in the all in one bundle. I unpack it correclty, set up PATH to point to gtk/bin, and create INCLUDE and LIB variables to point respectively to gtk/include and gtk/lib (this step does not seem necessary, but it can't hurt!)
I then verify all is in order by invoking
pkg-config --modversion gtk+-2.0
and the terminal happly chirps back
2.24.10
Great!
Then, I run cabal install
gtk2hs-buildtools
and that also goes well.
But then, when I run cabal install gtk, it complains that glib fails to install, because it can't find some C dependencies. I try to isolate the problem by running
cabal install glib
and get the following:
C:\Users\Federico>cabal install glib
Resolving dependencies...
Configuring glib-0.13.1.0...
Failed to install glib-0.13.1.0
Last 10 lines of the build log ( C:\Users\Federico\AppData\Roaming\cabal\logs\gl
ib-0.13.1.0.log ):
[1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist\setup-wrapper\Gtk2HsS
etup.o )
[2 of 2] Compiling Main ( SetupMain.hs, dist\setup-wrapper\Main.o )
Linking dist/setup-wrapper\setup.exe ...
Configuring glib-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
* Missing C libraries: gobject-2.0, gthread-2.0, glib-2.0, intl
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.
cabal: Error: some packages failed to install:
glib-0.13.1.0 failed during the configure step. The exception was:
ExitFailure 1
But this is utter crap! I KNOW the libraries are there. I can see them, in the gtk/bin folder! I re-check my path, and all is good. They are visible, in path. so is include, and lib. All of it. And yet, cabal complains it can't find them.
But this isn't the scariest bit yet...I download the 64-bit of the library, version 2.16...simply swap the two gtk folders...and now, cabal happly builds the whole thing! Of course, it's unsuable, because ghc on the plaftorm is 32-bit and the libraries are 64-bit, so ghc fails to link against it...but at least cabal was pleased.
I then remove glib, cairo, pango, gtk etc, and go about trying installing again, 2.16, 32-bit. And surely, cabal complains about C dependencies missing.
At this point, befuddled by this kafkian situation, I turn to the wisdom of stack overflow!
Is cabal trolling me? Are the error messages misleading? Or am I missing something obvious?
Thanks to all for the help!
If you are using 64 bit version of GHC, you want to use 64 bit version of gtk as well.
You can download it on this link. Scroll down a bit and download 2.x (not 3.x) all in one bundle, don't download 2.16:
http://www.gtk.org/download/win64.php
Above is no longer an option. You can try installing MSYS and than using MSYS console with pacman package manager to install gtk dev library on windows (I haven't tried it yet though). This pretty much sucks in my opinion.
I'm trying to install gcc4.9 on a SUSE system without an internet connection. I compiled gcc on an Ubuntu machine and installed it into a prefix, then copied the prefix folder to the SUSE machine. When I tried to run it gcc complained about not finding GLIBC_2_14, so I downloaded an rpm for libc6 online and included it into the prefix folders. my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64. When I try to run any program now (ls, cp, cat, etc) I get the error error while loading shared libraries: /home/***/prefix/lib64/libc.so.6: unexpected reloc type 0x25.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
As an alternative, is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64
See this answer for explanation of why this can't work.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
Your best bet is to install whatever GCC package comes with the SuSE system, then use that GCC to configure and install gcc-4.9 on it.
If for some reason you can't do that, this answer has some of the ways in which you can build gcc-4.9 on a newer system and have it still work on an older one.
is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
Contrary to popular belief, fully-static binaries are generally less portable then dynamic ones on Linux.
I was trying to install wxHaskell into a machine running Windows XP64, with MinGW/MSYS and wxWidget 3.0 built from source using gcc. I did:
cabal install wx
and got an error:
...
Configuring wxc-0.90.0.4...
setup.exe: wx-config: does not exist
Failed to install wxc-0.90.0.4
cabal.exe: Error: some packages failed to install:
wx-0.90.0.1 depends on wxc-0.90.0.4 which failed to install.
wxc-0.90.0.4 failed during the configure step. The exception was:
ExitFailure 1
wxcore-0.90.0.3 depends on wxc-0.90.0.4 which failed to install.
I had successfully used wxWidgets to write an sample application in C++ (gcc). So I do have a working wxWidget installation. And I have wx-config at:
$ which wx-config
/usr/local/bin/wx-config
The problem is that wx-config is a unix shell script, and cabal (called from MSYS) somehow refuses to recognize it even if it's on the system path. If I run wx-config in MSYS, I get something like:
$ wx-config --cxxflags
-I/usr/local/lib/wx/include/msw-unicode-3.0 -I/usr/local/include/wx-3.0 -D_LARGE
FILE_SOURCE=unknown -DWXUSINGDLL -D__WXMSW__ -mthreads
I have asked a question https://stackoverflow.com/questions/21998763/how-to-convert-msys-shell-scripts-to-windows-exe-files to see if it's possible to convert the script to an exe, but no one responded with any solutions.
There is also a related question here, wxHaskell installation on windows , and another here wx 0.90.0.1 fails to install on Haskell Platform 2012.2.0.0 (WinXP). In fact, I couldn't found an answer that's confirmed to work. Also, the errors/settings here seem to be different, or the answers therein don't seem solve my problem. In particular, I downloaded an external wx-config.exe from https://sourceforge.net/projects/wxhaskell/files/wx-config-win/ per http://www.haskell.org/haskellwiki/WxHaskell/Windows. But running wx-config.exe can't recognize my wxWidget installation and always gives me an error about cannot find wxWidgets, like this:
$ ./wx-config.exe --prefix=/usr/local/
wx-config Error: wxWidgets hasn't been found installed at 'C:\MinGW\msys\1.0\loc
al'.
Please use the --prefix flag (as in wx-config --prefix=C:\wxWidgets)
or set the environment variable WXWIN (as in WXWIN=C:\wxWidgets)
to specify where is your installation of wxWidgets.
Any idea how to work around this issue?
Thanks,
-- Update --
#JP I tried:
C:\temp\wxdirect-0.90.0.1>runhaskell Setup configure --extra-lib-dirs=c:\MinGW\lib --extra-include-dirs=c:\MinGW\include --extra-include-dirs=c:\MinGW\msys\1.0\local\include
Configuring wxdirect-0.90.0.1...
and got
Setup: At least the following dependencies are missing:
containers >=0.2 && <0.5, strict -any
I tweaked wxdirect.cabal to bypass containers >=0.2 && <0.5, but can't get pass strict.
I've written a powershell script that automates the setup of MinGW and the downloading/building of wxWidgets in order to build wxHaskell for Windows 7.
https://github.com/cessationoftime/wxHaskell-Windows-Builder