I've installed Haskell via the pre built installer v6.8.2.
When trying to compile this sample file with GHC
module Main where
import Text.ParserCombinators.Parsec
import System.Environment
main :: IO ()
main = do args <- getArgs
putStrLn ("Hello")
I get the following error:
D:\src\Haskell>ghc -o read read.hs
ghc -o read read.hs
read.o(.text+0x1b5):fake: undefined reference to `__stginit_parseczm2zi1zi0zi0_TextziParserCombinatorsziParsec_'
collect2: ld returned 1 exit status
I have installed Parsec via cabal.
Does anyone have any idea's as to what is wrong?
Try ghc --make -o read read.hs. GHC will take care of linker dependencies.
I'll put out one other way to make this work
ghc -package parsec -o read read.hs
From the ghc documentation
-package P
This option causes the installed package P to be exposed. The package P can be
specified in full with its version number (e.g. network-1.0) or the version number
can be omitted if there is only one version of the package installed. If there are
multiple versions of P installed, then all other versions will become hidden.
The -package P option also causes package P to be linked into the resulting
executable or shared object. Whether a packages' library is linked statically or
dynamically is controlled by the flag pair -static/-dynamic.
see http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
According to the Parsec docs (section 1.2.1 Compiling with GHC), you should do this:
When your linking the files together,
you need to tell GHC where it can find
libraries (-L) and to link with the
Parsec library too (-l):
ghc -o myprogram myfile1.o myfile2.o -Lc:\parsec -lparsec
This documentation on the Haskell compiler may help.
Related
I have downloaded Bellhop, which is an underwater acoustic simulator written in Fortran. It can be found here with the Makefile.
Question 1: I would like to know if it is possible to compile Fortran code, including everything needed, so a user without gfortran installed, can run it.
I have read here the following:
static linking
This section does not apply to Windows users, except for Cygwin users with gcc4-4.3.2-2 or later.
gfortran is composed of two main parts: the compiler, which creates the executable program from your code, and the library, which is used when you run your program afterwards. That explains why, if gfortran is installed in a non-standard directory, it may compile your code fine but the executable may fail with an error message like library not found. One way to avoid this (more ideas can be found on the binaries page) is to use the so-called "static linking", available with option -static gfortran then put the library code inside the program created, thus enabling it to run without the library present (like, on a computer where gfortran is not installed). Complete example is:
gfortran -static myfile.f -o program.exe
Reading this, I suppose that it is possible to do what I'm asking but I'm not very familiarized with fortran and makefiles. I don't understand this:
put the library code inside the program created
Question 2: How can I put the library code inside the program? Where can I find the library? What does "inside the program" means?
I'm running OSX 10.9.4 and gfortran
I solved my problem about compiling Fortran code with gfortran using static libraries.
As #M.S.B. said, using static-libgfortran worked for me under MacOS.
If somebody is having issues with linking the libquadmath.0.dylb library, remove libquadmath.0.dylib and libquadmath.dylib from /usr/local/gfortran/lib/
This doest the trick. Further information can be found here
I think the meaning of the bold part is actually
gfortran then puts the library code inside the
program created
That means using -static should be enough, there is no additional step. Just be advised you will need a static version of all the libraries that you link with.
I know this is very old tracker, but maybe somebody will be still interested in the solution that works.
Let's say we have code:
! fort_sample.f90
program main
write (*,*) 'Hello'
stop
end
First, compile the stuff:
gfortran -c -o fort_sample.o fort_sample.f90
Then, link stuff
ld -o ./fort_sample -no_compact_unwind \
-arch x86_64 -macosx_version_min 10.12.0 \
-lSystem \
/usr/local/gfortran/lib/libgfortran.a \
/usr/local/gfortran/lib/libquadmath.a \
/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0/libgcc.a \
fort_sample.o
You can execute it
./fort_sample
Hello
You can notice that quadmath is no longer there
> otool -L fort_sample
fort_sample:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1)
I guess this is what you were looking for in a first place. No removing dylibs, no symbolic links, etc.
The current version of the option is -static-libgfortran. This means that the Fortran specific libraries of gfortran will be included into the executable. These are libraries are automatically found for a good installation of gfortran. This should produce an executable that should run on other computers with the same OS, even if that computer doesn't have gfortran installed. This option likely doesn't statically link all libraries, so there is some risk that some other shared library used on your computer won't be available on the other computer.
I'm having trouble building the hmatrix library on OS X Lion. Looking at the .cabal file, it requires the gsl library, so I installed it with macports. The .a files are in /opt/local/lib and the .h files are in /opt/local/include/gsl
As suggested here I changed the built-type from Custom to Simple. (without that change I get a similar error).
When I use cabal configure I get the following output:
* Missing C library: gsl
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.
So I tried cabal --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib configure, but I still get the same error. I can compile and link a c program that includes gsl. What files is cabal looking for? If I have the right files, how do I tell it how to find them?
libgsl.a is a universal binary:
$ file /opt/local/lib/libgsl.a
/opt/local/lib/libgsl.a: Mach-O universal binary with 2 architectures
/opt/local/lib/libgsl.a (for architecture x86_64): current ar archive random library
/opt/local/lib/libgsl.a (for architecture i386): current ar archive random library
ghc looks like it's 64-bit:
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/llvm-gcc")
,("C compiler flags"," -m64 -fno-stack-protector -m64")
,("ar command","/usr/bin/ar")
,("ar flags","clqs")
,("ar supports at file","NO")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("perl command","/usr/bin/perl")
,("target os","OSDarwin")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has subsections via symbols","True")
,("Project version","7.4.2")
,("Booter version","7.4.2")
,("Stage","2")
,("Build platform","x86_64-apple-darwin")
,("Host platform","x86_64-apple-darwin")
,("Target platform","x86_64-apple-darwin")
,("Have interpreter","YES")
,("Object splitting supported","NO")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2")
,("Global Package DB","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2/package.conf.d")
,("Gcc Linker flags","[\"-m64\"]")
,("Ld Linker flags","[\"-arch\",\"x86_64\"]")
]
As an alternative to mac-ports you can use the nix package manager for mac. It does a pretty good job of taking care of the c dependancies for for the libraries available through it. In general I have been more happy with it then any other package manager on mac.
Unfortunately mac(darwin) unlike for linux does not have as many binaries available through nix so installing ghc often means waiting for it to compile.
The commands to install ghc and hmatrix after installation of nix are:
nix-env -iA nixpkgs-unstable.haskellPackages.ghc
nix-env -iA nixpkgs-unstable.haskellPackages.hmatrix
All of the needed dependencies will be taken care of for you.
I just tried it on my macbook pro and hmatrix seems to be working correctly in ghci after trying commands from the first few pages of the tutorial.
I'm not a mac person, but it really sounds like you haven't installed the "-dev" version. For a mac, I suspect you need to install gsl-devel in addition to gsl. If the problem persists, verify that you have libgsl0-dev on your library path.
I tried to compile and link simple program using ghc, but it failed during linking:
import System (getArgs)
main = do
args <- getArgs
print args
I tried to compile with
% ghc -c -O Main.hs
% ghc -o Main Main.o
ld: warning: could not create compact unwind for .LFB3: non-standard register 5 being saved in prolog
Undefined symbols for architecture i386:
"___stginit_haskell98zm1zi1zi0zi1_System_", referenced from:
___stginit_Main_ in Main.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
zsh: exit 1 ghc -o Main Main.o
However, when compiling with --make:
% ghc --make Main.hs
everything works (besides tons of ld warnings)
Some more informations about environment:
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
From Haskell Platform for Mac OS X 10.6 (Intel, 32 bit GHC)
System: Max OS X Lion 10.7.2
Any ideas what's wrong?
(Btw, I tried to install HP x64 but it failed during installation)
Michael is historically right. With --make, ghc figures out which packages it has to use and link in by itself (unless two installed packages expose the same module name, then it can't figure out which one to use), without --make, you have to tell it. However, as of 7.0, --make is the default mode of ghc, so plain ghc Main.hs is now the same as ghc --make Main.hs. The difference here is the two-step compilation. I don't know the precise details, but the cause is that the module System is in the haskell98 package (a propos, please use the hierarchical modules, getArgs should be imported via System.Environment, as of 7.2, haskell98 can't be used together with base), which by default is not linked in. So ghc -o Main Main.o doesn't find the symbol in the default packages. You'd have to tell it explicitly to look in the haskell98 package, ghc -c -O Main.hs; ghc -package haskell98 -o Main Main.o should work (and it works here, I've tested with 7.0.4 to make sure).
Perhaps it's because you're using something from System? ghc --make probably auto-detects which Haskell libraries it needs to link, and ghc by itself does not.
I need to build some C code and then reference that C code via the FFI. I would like to use my binding from inside ghci on osx. On of my constraints is that I cannot just hand the C sources to ghc in the .cabal file. This is due to a limitation with ghc/cabal that may be fixed in the next release of ghc (but I want my code to work now and on older releases). See this bug for details.
The gist of that bug is that the C code needs to be compiled with some Objective-C modules and ghc misinterprets those as linker scripts. I've tried many things and building the files myself with a makefile is the only thing that has worked. Really, this shouldn't be an issue though because it should be the same as if I decided to use a external C library that I didn't build myself. For the sake of this issue, let's pretend it's a separate C library that I can easily rebuild with different options.
If I build the C library as a .a, then ghci comlains that it cannot open the .dylib. My first question is: Why does ghci need a .dylib and does it really use it?
When I build a dylib I get a segfault when loading the code into ghci.
Keep in mind, this binding works already on other platforms, both linux and windows, and the binding works fine on osx when I'm compiling instead of using ghci. This problem specific to the osx/ghci combo.
In that trace above, I'm using gdb but it crashes regardless of whether I use gdb. I tracked it down to the lines that cause the crash:
void _glfwClearWindowHints( void )
{
memset( &_glfwLibrary.hints, 0, sizeof( _glfwLibrary.hints ) );
}
The trouble maker is that memset line, well actually the problem is that when running inside ghci writing to the hints structure of _glfwLibrary is a memory access violation. The hints struct is simply a bunch of ints. It's very flat and simple, and thus I think the problem is an issue either with how I'm linking things or with the way ghci is loading the code.
Here are the bits of my makefile that I use to build the dylib and the .a:
GCCFLAGS := $(shell ghc --info | ghc -e "fmap read getContents >>= \
putStrLn . unwords . read . Data.Maybe.fromJust . lookup \
\"Gcc Linker flags\"")
FRAMEWORK := -framework Cocoa -framework OpenGL
GLFW_FLAG := $(GCCFLAGS) -O2 -fno-common -Iglfw/include -Iglfw/lib \
-Iglfw/lib/cocoa $(CFLAGS)
all: $(BUILD_DIR)/static/libglfw.a $(BUILD_DIR)/dynamic/libglfw.dylib
$(BUILD_DIR)/dynamic/libglfw.dylib: $(OBJS)
$(CC) -dynamiclib -Wl,-single_module -compatibility_version 1 \
-current_version 1 \
$(GLFW_FLAG) -o $# $(OBJS) $(GLFW_SRC) $(FRAMEWORK)
$(BUILD_DIR)/static/libglfw.a: $(OBJS)
ar -rcs $# $(OBJS)
Most of the flags are taken straight from the GLFW Makefile so I think they should be correct for that library.
The first line looks a bit weird but it's the solution I used for this problem.
Platform details:
OSX 10.6.6
x86_64
4 cores
GHC version 7.0.3 installed via Haskell Platform installer
Source repo: https://github.com/dagit/GLFW-b
Edit: Here are my questions:
Should this work with ghci?
If so, what am I doing wrong or how can I fix the crash?
Can I just get by with the static .a version of the library with ghci?
Initial Questions
Should this work with ghci?
If so, what am I doing wrong or how can I fix the crash?
On OSX 10.6.7 (using the Haskell Platform /w GHC 7.0.2) I could load your built shared lib into ghci as follows:
➜ GLFW-b git:(master) ✗ ghci dist/build/Graphics/UI/GLFW.hs -Lbuild/dynam
ic -lglfw
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) glfw ... done
final link ... done
[1 of 1] Compiling Graphics.UI.GLFW ( dist/build/Graphics/UI/GLFW.hs, inte
rpreted )
Ok, modules loaded: Graphics.UI.GLFW.
*Graphics.UI.GLFW> initialize
True
Note: I built the glfw libs using your provided Makefile, and additionally used your .cabal file to process src/Graphics/UI/GLFW.hsc and build dist/build/Graphics/UI/GLFW.hs (i.e. I'd previously run cabal configure/build).
Can I just get by with the static .a version of the library with ghci?
Yes, support for loading static libs was included in GHC 7.0.2 (GHC Manual). compiler/ghci/Linker.lhs is a great read, and will give you a high-level sense of how ghci decides what to make of the command line arguments passed to it. Additionally, when navigating various platform support issues, I've found this documentation exceedingly useful.
Linking static archives with ghci.
As of writing, line 1113 of compiler/ghci/Linker.hs demonstrates that ghci currently requires that static archives be built by the package system (i.e. named HSlibname.a)
locateOneObj :: [FilePath] -> String -> IO LibrarySpec
locateOneObj dirs lib
| not ("HS" `isPrefixOf` lib)
-- For non-Haskell libraries (e.g. gmp, iconv) we assume dynamic library
= assumeDll
| not isDynamicGhcLib
-- When the GHC package was not compiled as dynamic library
-- (=DYNAMIC not set), we search for .o libraries or, if they
-- don't exist, .a libraries.
= findObject `orElse` findArchive `orElse` assumeDll
Further investigation of cmd line argument parsing indicates that libraries specified are collected at line 402 in the reallyInitDynLinker function:
; classified_ld_inputs <- mapM classifyLdInput cmdline_ld_inputs
where classifyLdInput is defined over
classifyLdInput :: FilePath -> IO (Maybe LibrarySpec)
classifyLdInput f
| isObjectFilename f = return (Just (Object f))
| isDynLibFilename f = return (Just (DLLPath f))
| otherwise = do
hPutStrLn stderr ("Warning: ignoring unrecognised input `" ++ f ++ "'")
return Nothing
This means that outside of a package specification, there currently is no direct way to link an archive file in ghci (or said differently, there currently is no cmd-line argument to do so).
Fixing your cabal package
In your .cabal package specification, you are attempting to build two conflicting libraries:
A: link in a pre-built library (built according to your specification in Setup.hs and Makefile, and linked as per the extra-libraries and extra-lib-dirs directives)
B: build a new library inline (the c-sources and frameworks directives).
A simple fix for the error above is to simply remove all directives enabling B when building for Mac OSX, as follows:
include-dirs:
glfw/include
glfw/lib
- c-sources:
- glfw/lib/enable.c
- glfw/lib/fullscreen.c
- glfw/lib/glext.c
- glfw/lib/image.c
- glfw/lib/init.c
- glfw/lib/input.c
- glfw/lib/joystick.c
- glfw/lib/stream.c
- glfw/lib/tga.c
- glfw/lib/thread.c
- glfw/lib/time.c
- glfw/lib/window.c
+
+ if !os(darwin)
+ c-sources:
+ glfw/lib/enable.c
+ glfw/lib/fullscreen.c
+ glfw/lib/glext.c
+ glfw/lib/image.c
+ glfw/lib/init.c
+ glfw/lib/input.c
+ glfw/lib/joystick.c
+ glfw/lib/stream.c
+ glfw/lib/tga.c
+ glfw/lib/thread.c
+ glfw/lib/time.c
+ glfw/lib/window.c
and
if os(darwin)
- include-dirs:
- glfw/lib/cocoa
- frameworks:
- AGL
- Cocoa
- OpenGL
extra-libraries: glfw
- extra-lib-dirs: build/static build/dynamic
+ extra-lib-dirs: build/dynamic
I've not tested anything beyond verifying that the following now works properly:
➜ GLFW-b git:(master) ✗ ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :m + Graphics.UI.GLFW
Prelude Graphics.UI.GLFW> initialize
Loading package GLFW-b-0.0.2.6 ... linking ... done.
True
Prelude Graphics.UI.GLFW>
haskell 'openid' package depends on HsOpenSSL and nano-hmac packages which requires openssl. I've compiled openssl for MinGW in C:\OpenSSL\ directory and installed openid package with following command:
cabal install openid --extra-include-dirs=C:\OpenSSL\outinc --extra-lib-dirs=C:\OpenSSL\out
When I'm trying to compile haskell program using this package I'm receiving lots linking errors.
test.hs:
import Network.OpenID
main = print "ok"
ghc --make test.hs:
Linking test.exe ...
C:\OpenSSL\out/libcrypto.a(m_sha1.o):m_sha1.c:(.text+0x60): multiple definition of `EVP_sha1'
C:\OpenSSL\out/libeay32.a(deegs01228.o):(.text+0x0): first defined here
C:\OpenSSL\out/libcrypto.a(m_sha1.o):m_sha1.c:(.text+0x100): multiple definition of `EVP_sha256'
C:\OpenSSL\out/libeay32.a(deegs01230.o):(.text+0x0): first defined here
.....
C:\OpenSSL\out/libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x2d4): undefined reference to `X509_VERIFY_PARAM_set_purpose'
C:\OpenSSL\out/libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x2f1): undefined reference to `X509_VERIFY_PARAM_set_purpose'
C:\OpenSSL\out/libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x314): undefined reference to `X509_VERIFY_PARAM_set_trust'
.....
collect2: ld returned 1 exit status
What I'm doing wrong?
I suspect there may be a version mismatch somewhere. Try using the precompiled binaries for OpenSSL here: http://www.openssl.org/related/binaries.html
I was able to get the instructions here to work with the latest version of HsOpenSSL: http://hackage.haskell.org/trac/ghc/wiki/Builder (in fact I worked with the maintainer to make these instructions work without needing to patch the package.)