I have a problem compiling Haskell programs, that import the Text.Regex.Posix module. I have tried to isolate the problem in a small test program:
module Main () where
import Text.Regex.Posix ((=~))
main = return ()
Running the interpreter works fine:
/regex-test$ runghc Main.hs
/regex-test$
However, compiling this program with ghc yields:
/regex-test$ ghc -o tester Main.hs
Main.o: In function `rmS_info':
(.text+0xf3): undefined reference to `__stginit_regexzmposixzm0zi72zi0zi3_TextziRegexziPosix_'
collect2: ld returned 1 exit status
After this, the interpreter also stops working:
/regex-test$ runghc Main.hs
<interactive>:1:32: Not in scope: `main'
/projects/regex-test$
I can get it to work again by saving the file again without making any changes.
Does anyone have an idea how to solve this?
Some info on my system:
/regex-test$ uname -a
Linux Hello-Ubuntu 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:49:34 UTC 2009 i686 GNU/Linux
and
/regex-test$ ghc-pkg list
/usr/local/lib/ghc-6.10.3/./package.conf:
Cabal-1.6.0.3, HUnit-1.2.0.3, QuickCheck-1.2.0.0, array-0.2.0.0,
base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1,
directory-1.0.0.3, (dph-base-0.3), (dph-par-0.3),
(dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3),
(dph-seq-0.3), extensible-exceptions-0.1.1.0, filepath-1.1.0.2,
(ghc-6.10.3), ghc-prim-0.1.0.0, haddock-2.4.2, haskell-src-1.0.1.3,
haskell98-1.0.1.0, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1,
mtl-1.1.0.2, network-2.2.1, old-locale-1.0.0.1, old-time-1.0.0.2,
packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1,
pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1,
regex-base-0.72.0.2, regex-base-0.93.1, regex-compat-0.71.0.1,
regex-posix-0.72.0.3, regex-tdfa-1.1.2, rts-1.0, stm-2.1.1.2,
syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.3, unix-2.3.2.0,
xhtml-3000.2.0.1
~/.ghc/i386-linux-6.10.3/package.conf:
HTTP-4000.0.4, zlib-0.5.0.0
I'd expect at least main to be exported... i.e.
module Main (main) where
but that's not the problem here.
$ ghc -o tester -package regex-posix Main.o
Linking like this works perfectly fine.
You should either use cabal as your buildsystem, compile and link with ghc --make, or take care to expose all requisite packages manually.
Do exactly what you did but pass --make to ghc as well.
You're missing --make flag, which has GHC solve the missing library dependencies for you.
Related
I am on a Mac powerbook with Gnu Fortran installed
gfortran -static-libgfortran -o prog.exe prog.f
still produces an executable that tries to link to dynamic library routines. I am happy to load and compile whatever static library I need and also try to point gfortran to it. (This issue seems to have been around for several years) Is there no easy solution. Simple steps?) (In the tries below I clearly don't know what I am doing.)
gfortran -static -o prog.exe prog.f
ld: library not found for -lcrt0.o
libquadmath.a and libcrt0.0 come up missing
sudo dnf install libcrt0.o-static
sudo: dnf: command not found
g -static-libgfortran -lgfortran.a -lquadmath.a -o prog prog.f
ld: library not found for -lgfortran.a
i have a problem that is driving me crazy. I just did a clean installation of UBUNTU 18.04 LTS and installed VS Code and gfortran-9 successfully. The problem is that i can't compile a simple hello world program.
The file is saved as hello.f90 and i tried to compile it in several ways, like:
`gfortran-9 hello.f90 -o hello.exe
`gfortran-9 hello.exe
or using object file. I always end up with the same error:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
the code is simply:
program hello
implicit none
print *, 'hello world'
end program hello
I searched everywhere on the internet, but since i'm new to ubuntu when it comes to solution like: "installing libraries", or similar i just can't go on without anyone who explain me step by step...I hope in you.
I solved it. Basically i was trying to execute the executable with the command gfortran namefile.exe but then i realised that maybe i should've used the command ./namefile.exe and in fact it worked. So the compiling process was good, it was me who was wrong in the execution.
(See end of this post if you want to see how I installed dtrace - for now I'll assume you already have it installed)
I made a custom probe with no problems at all by following these steps:
A. Create thing.d with my probe definition
provider thing {
probe test();
};
B. Create a simple main.cpp
#include "thing.h"
int main()
{
// Fire my probe
THING_TEST();
// Something to prevent immediate exit
for(;;)
sleep(1);
// Bye
return 0;
}
C. Compile (but don't link) main.cpp. Note how you must define _DTRACE_VERSION or else your probes will be commented out in thing.h.
g++ -D _DTRACE_VERSION -c main.cpp -o main.o
D. Build the probe object file (note that you must include main.o as part of this)
dtrace -G -s thing.d -o thing.o main.o
E. Link it all up
g++ main.o thing.o -o thing
Here's the problem: Run the app, and terminate with CTRL-C (obviously the app won't stop by itself because of the infinite loop...).
In fact, do this a few times.
Now, from a superuser terminal:
# dtrace -l | grep thing
322991 thing28217 thing main test
322992 thing28403 thing main test
322994 thing28636 thing main test
These guys are just hanging around... It's like they never got de-registered or something.
I've run "ps" to see if there are any procs with those pids (28217, 28403, 28636) and nope, nothing there.
INTERESTINGLY, if I remove the infinite loop from main.cpp (the sleep() loop) and just let the app immediately exit, then the probes are properly removed. So it seems like the issue has to do with CTRL-C being detected inside of sleep() - perhaps some kind of atexit() handler isn't being called?
Here's my system info:
$ uname -a
Linux beavis 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:18:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ g++ --version
g++ (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
DTRACE INSTALLATION
I am not using the default dtrace that comes with Ubuntu, but rather the dtrace4linux stuff which I installed like this:
http://askubuntu.com/questions/60940/how-do-i-install-dtrace
NOTE: I am using the latest version from Paul Fox's site:
ftp://crisp.dyndns-server.com/pub/release/website/dtrace/dtrace-20130317.tar.bz2
On OSX 10.6.4 with i686-apple-darwin10-g++-4.2.1 compiling using TextMate and a Makefile which in the first place has been made für a Linux and I am trying to translate for OSX.
When compiling a c++ project I get the "can't link with a main executable" error:
g++ -Wall -g -I ~/svnX-Repository/axp-Projekte/xrlfupa/trunk/src/ -I ~/svnX-Repository/boost_1_44_0 -I /opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -I /opt/local/var/macports/software/gsl/1.14_0/opt/local/include/ -o xrfLibTest xrfLibTest.o excitFunctions.o xrfFunctions.o filterFunctions.o detectorFunctions.o -L/opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -L/opt/local/var/macports/software/gsl/1.14_0/opt/local/lib/ -lm -lxrlTUB -lboost_serialization -lgsl -lgslcblas # Debug 1
ld: in /usr/local/lib/libxrlTUB.so, can't link with a main executable
collect2: ld returned 1 exit status
make: *** [prog] Error 1
The library that is mentioned (libxrlTUB.so) is in its place (/usr/local/lib/libxrlTUB.so) but, possibly that is where the problem came from, the libxrlTUB.so has been compiled by myself beforehand as well.
The compile process went through, it was generated by swig, though there was a warning:
g++ -arch x86_64 -m32 -g -fpic -I /usr/include/python2.6 -c PyXrl_wrap.cxx
In function 'void SWIG_Python_AddErrorMsg(const char*)':
warning: format not a string literal and no format arguments
which, as far as I could find out, shouldnt be a problem. (Or is it?)
Unfortunately this whole thing is part of a project from the university. Actually I am supposed to write an X-ray-analysis script in python, which would be fine, if... well if I wouldn't be expected to use the librarys that are meant to result from this c++ project.
(Afterwards they should be used via import in python.)
I am not really experienced with c++, neither with compiling on OSX systems. So far I have been bothering with scipting (python, bash, etc). So Maybe I am just missing something simple. Hopefully someone can give me an hint where I can continue reading in order to deal with the above "can't link with a main executable" error...
Thanx in advance,
Liam
The error message is telling you the problem—it is that /usr/local/lib/libxrlTUB.so is not a shared library; it's an executable. You can't link against an executable. Probably whatever build process you used for libxrlTUB.so didn't understand how to build shared libraries on the Mac (it's more suspect because .dylib is the correct extension to use.)
Take a look at Apple's documentation on compiling dynamic libraries. You can use file to make sure your output is of the correct type, for example:
% gcc -c foo.c
% gcc -dynamiclib foo.o -o foo.dylib
% file foo.dylib
foo.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Without -dynamiclib you end up with an executable, which may be the problem you've run into.
I am trying to compile a linear system solver using PARDISO.
The test case (pardiso_sym.c) also downloaded from the same website above.
I have the following files inside the directory:
[gv#emerald my-pardiso]$ ls -lh
total 1.3M
-rw-r--r-- 1 gv hgc0746 1.3M Aug 7 11:59 libpardiso_GNU_IA64.so
-rw-r--r-- 1 gv hgc0746 7.2K Nov 13 2007 pardiso_sym.c
Then I try to compile it with the following command:
[gv#emerald my-pardiso]$ gcc pardiso_sym.c -o pardiso_sym -L . -llibpardiso_GNU_IA64.so -L/home/gv/.boost/include/boost-1_38 -llapack
But it gives this error:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.2/../../../../x86_64-unknown-linux-gnu/bin/ld:
cannot find -llibpardiso_GNU_IA64.so
collect2: ld returned 1 exit status
What's wrong with my compilation method?
This is the additional info of my system:
[gv#emerald my-pardiso]$ uname -a
Linux gw05 2.6.18-92.1.13.el5 #1 SMP Wed Sep 24 19:32:05 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux
[gv#emerald my-pardiso]$ gcc --version
gcc (GCC) 4.3.2
Update:
The library is recognized using Dave Gamble's suggestion. But now it gives different
error:
$ gcc pardiso_sym.c -o pardiso_sym -L . -lpardiso_GNU_IA64 -L/home/gv/.boost/include/boost-1_38 -llapack
./libpardiso_GNU_IA64.so: undefined reference to `s_stop'
./libpardiso_GNU_IA64.so: undefined reference to `s_wsfe'
./libpardiso_GNU_IA64.so: undefined reference to `e_wsfe'
./libpardiso_GNU_IA64.so: undefined reference to `z_abs'
./libpardiso_GNU_IA64.so: undefined reference to `s_cat'
./libpardiso_GNU_IA64.so: undefined reference to `s_copy'
./libpardiso_GNU_IA64.so: undefined reference to `do_fio'
EDIT: I read the pardiso manual. Here's the fix:
gcc pardiso_sym.c -o pardiso_sym -L . -lpardiso_GNU_IA64 -L/home/gv/.boost/include/boost-1_38 -llapack
Here I've removed the "lib" from the start and the ".so" from the end of -lpardiso_GNU_IA64
EDIT:
For new errors you'll need -lg2c after -lapack (fortran compatibility library)
EDIT2:
Also add -lgfortran and anything else you might need. Googling for a missing symbol usually finds mentions of library it contains. Keep adding libraries one by one untill all dependencies are satisfied.
So in your case routine is like this:
linked lapack -- got unresolved symbol from g2c
added g2c -- got symbols from gfortran
added gfortran -- got some other symbols, look them up and add libs one by one.
Libray order matters, if you include g2c before lapak for example, linker will throw away all its symbols before it knows they are needed for lapak (MS linker does 2 passes to fix that). So if you see a missing symbol that is in a lib you already include, look at which library needs it and move the lib with the symbol to be after it.