I have a problem with ghci and I need an advice on how to debug it. The problem is that when I execute a function from my imported project I have a duplicate definition error and ghci exits because it can't continue:
> ghci -v0 --interactive -ignore-dot-ghci -isrc -idist/build/autogen tests/System/Console/Hawk/PreludeTests.hs -no-user-package-db -package-db /mnt/git/hawk/.cabal-sandbox/x86_64-linux-ghc-7.6.3-packages.conf.d
*System.Console.Hawk.PreludeTests> test [] "1" ""
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
__stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch
whilst processing object file
/mnt/git/hawk/.cabal-sandbox/lib/x86_64-linux-ghc-7.6.3/stringsearch-0.3.6.5/libHSstringsearch-0.3.6.5.a
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
The problem is that I can't find where this is happening. The symbol is unique in my cabal sandbox:
> for f in `find .cabal-sandbox -type f -iname "*.a"`; do nm $f | grep '__stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch$'; done
0000000000000000 D __stginit_stringsearchzm0zi3zi6zi5_DataziByteStringziSearch
so probably the stringsearch library is somehow loaded two times, but ghci is vague about it.
I would like to know if there is a way to debug this or, at least, to get more informations on the error before ghci kills itself. I already tried to change verbosity but I still get no informations.
Often this can occur when you are indirectly depending on two different versions of a library that both export the same symbol. This could occur, for example, if you also had a library from outside your sandbox (e.g. in the global package db) that depended on a stringsearch from there.
Additionally, to get more debug info, you should pass a flag indicating a higher verbosity.
Related
I am compiling using cmake. I am on Linux with an intel processor. The important cmake lines are
set(SRCS srcA.FOR srcB.FOR ... srcK.FOR)
add_executable(filename ${SRCS})
I get no errors, just warnings. There are three types of warnings:
I am not using a variable (bad on my part but surely not code-breaking)
"this name has not been given a specific type"
"no action performed for file 'path/to/file/filename.FOR.o'"
Right before the "no action..." warning it says
Linking Fortran executable filename
and the last line says
Built target filename
That last line in particular to me implies that there should be an executable file, but I cannot find it. I have tried searching for it using
find -type f -name "*.exe" and `find -type f -name "filename" and neither are returning anything.
I will note that I am new to compiling these types of files on Linux, so I am sure there is something small I am doing wrong and don't know what it is
EDIT Added more detailed error output
Note that the "no action performed..." error appears once for each file and is identical (besides the filename of course)
ifort: warning #10145: no action performed for file 'CMakeFiles/dynamicmpm.dir/getversion.for.o'
EDIT #2 Adding the contents of the cmake file below
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(MPM)
enable_language (Fortran)
get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME)
MESSAGE("Fortran_COMPILER_NAME = ${Fortran_COMPILER_NAME}")
set(CMAKE_Fortran_FLAGS "-nologo -O2 -assume buffered_io -fpp -Dinternal_release -reentrancy threaded -free -warn all -real_size 64 -Qauto -fp:strict -fp:constant -libs:static -threads -Qmkl:sequential -c -Qm64")
if (Fortran_COMPILER_NAME MATCHES "gfortran")
# gfortran
set(COMMON_FLAGS "-fmax-identifier-length=63 -ffree-form -ffree-line-length-none -fdefault-real-8")
set (CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} ${COMMON_FLAGS}")
set (CMAKE_Fortran_FLAGS_DEBUG "${CMAKE_Fortran_FLAGS_DEBUG} ${COMMON_FLAGS}")
endif()
set(SRCS srcA.FOR srcB.FOR ... srcK.FOR) #theres a bazillion files so I made this dummy line for the post
add_executable(filename ${SRCS})
EDIT 3
I get the following error now after making the changes recommended below:
[100%] Linking Fortran executable dynamicmpm
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_createprofiledss_':
Solver.FOR:(.text+0x1143): undefined reference to `dss_create_'
Solver.FOR:(.text+0x11a8): undefined reference to `dss_define_structure_'
Solver.FOR:(.text+0x1471): undefined reference to `dss_reorder_'
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_solveequations_':
Solver.FOR:(.text+0x35ec): undefined reference to `dss_factor_real_d__'
Solver.FOR:(.text+0x361d): undefined reference to `dss_solve_real_d_'
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_destroyequations_':
Solver.FOR:(.text+0x4495): undefined reference to `dss_delete_'
CMakeFiles/dynamicmpm.dir/Solver.FOR.o: In function `modsolver_mp_initialisereducedsolution_':
Solver.FOR:(.text+0x5a58): undefined reference to `dss_create_'
Solver.FOR:(.text+0x5abd): undefined reference to `dss_define_structure_'
Solver.FOR:(.text+0x606d): undefined reference to `dss_reorder_'
at the top of Solver.FOR I have use mkl_dss and mkl_dss.f90 is included in
set(SRCS srcA.FOR srcB.for mkl_dss.f90 ... otherSources.FOR)
Am I linking the files incorrectly?
no action performed for file 'path/to/file/filename.FOR.o' - You passed -c to flags, so compiler does not know what to do with object files. Research what -c flag means. Remove -c flag.
get_filename_component (Fortran_COMPILER_NAME - use CMAKE_Fortran_COMPILER_ID STREQUAL "GNU" instead.
Do not use set(CMAKE_Fortran_FLAGS. Prefer target_compiler_options, target_link_options, target_link_libraries or add_compile_options instead.
Do not write long lines. Split them with newlines as a list.
set(COMMON_FLAGS - if they are common, why add them to _RELEASE and _DEBUG separately? Just add_compile_options them.
--extra-lib-dirs should ostensibly function like LD_LIBRARY_PATH, but when used with stack exec I see different results:
$ stack --extra-lib-dirs=$MATLAB_PATH/bin/glnxa64 --extra-include-dirs=$MATLAB_PATH/extern/include --nix exec matlab-engine-test
/home/bebarker/workspace/haskell-matlab/.stack-work/install/x86_64-linux-nix/24c5769e9013838d87aa76fb4cdd10a09798b6904a6faa380de6fe6949e2c952/8.6.5/bin/matlab-engine-test: error while loading shared libraries: libmx.so: cannot open shared object file: No such file or directory
$ LD_LIBRARY_PATH=$MATLAB_PATH/bin/glnxa64 /home/bebarker/workspace/haskell-matlab/.stack-work/install/x86_64-linux-nix/24c5769e9013838d87aa76fb4cdd10a09798b6904a6faa380de6fe6949e2c952/8.6.5/bin/matlab-engine-test
matlab-engine-test: user error (engOpen)
LD_LIBRARY_PATH behaves as expected in this case (though clearly I have another unrelated issue to deal with there). Should I be looking for another option or am I using --extra-lib-dirs incorrectly?
I don't tend to use Stack, but in build systems the library path provided by command line flags is usually only passed to the linker. Observe (with main = print =<< lookupEnv "LD_LIBRARY_PATH"):
$ stack --extra-lib-dirs=/foopath/bin/glnxa64 --extra-include-dirs=/foopath/extern/include exec ./foo
Just ""
$
Compare with what you did second:
$ LD_LIBRARY_PATH=/foopath/bin/glnxa64 ./foo
Just "/foopath/bin/glnxa64"
This is really just out of curiosity.
A typo made me notice that in Bash, the following:
$ .anything
does not print any error ("anything" not to be interpreted literally, it can really be anything, and no space after the dot).
I am curious about how this is interpreted in bash.
Note that echo $? after such command returns 127. This usually means "command not found". It does make sense in this case, however I find it odd that no error message is printed.
Why would $ anything actually print bash:anything: command not found... (assuming that no anything cmd is in the PATH), while $ .anything slips through silently?
System: Fedora Core 22
Bash version: GNU bash, version 4.3.39(1)-release (x86_64-redhat-linux-gnu)
EDIT:
Some comments below indicated the problem as non-reproducible at first.
The answer of #hek2mgl below summarises the many contributions to this issue, which was eventually found (by #n.m.) as reproducible in FC22 and submitted as a bug report in https://bugzilla.redhat.com/show_bug.cgi?id=1292531
bash supports a handler for situations when a command can't be found. You can define the following function:
function command_not_found_handle() {
command=$1
# do something
}
Using that function it is possible to suppress the error message. Search for that function in your bash startup files.
Another way to find that out is to unset the function. Like this:
$ unset -f command_not_found_handle
$ .anything # Should display the error message
After some research, #n.m. found out that the described behaviour is by intention. FC22 implements command_not_found_handle and calls the program /etc/libexec/pk-command-not-found. This program is part of the PackageKit project and will try to suggest installable packages if you type a command name that can't be found.
In it's main() function the program explicitly checks if the command name starts with a dot and silently returns in that case. This behaviour was introduced in this commit:
https://github.com/hughsie/PackageKit/commit/0e85001b
as a response to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1151185
IMHO this behaviour is questionable. At least other distros are not doing so. But now you know that the behaviour is 100% reproducible and you may follow up on that bug report.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Outputting Haskell GHCi command results to a txt file
I am new to Haskell and I am trying to redirect test cases output results to a text file. The way it is set up now, is a AddAllTestCases.hs contains all the test cases I need to run in order to test a function I created. I run the test cases on GHCi by loading AddAllTestCases.hs and then simply typing main and hitting enter. That causes test case output results to print inside the GHCi perfectly.
Because there hundreds of test cases, I need to redirect output results to text file.
Attempt #1:
writeFile "myoutput.txt" $ show $ main
I get the following error:
No instance for (Show(IO())) arising from a use of show
Attempt #2 in CMD (trying to create an executable, then outputting executable results to text file):
ghc --make AddAllTests.hs -o testResults.exe
Which gives me the following error:
Warning: output was redirected with -o, but no output will be generated because there is no Min module
This is weird because when I am using GHCi (attempt #1) and I type in main it executes everything perfectly, which I would assume, implies that there is a main module?
I greatly appreciate any help with redirecting test case results to a text file.
Many thanks in advance!
You need a Main module (and a main action) to produce an executable. You can rename your module to Main, or you can specify the module to be considered Main on the command line,
ghc --make -main-is AddAllTests AddAllTests.hs -o testResults.exe
to produce an executable without a module named Main.
A method without compiling would be
ghc AddAllTests.hs -e "main" > testResults.txt
Another method would be to have a file in which you just list all test cases,
3 + 2 :: Rational
reverse "foobar"
:q
and run ghci with redirected in- and output
ghci < testCases > testResults.txt
I'm trying to compile a haskell file that has a HUGE number of errors in it. I want to start debugging the first one but unfortunately there are so many that they go off the screen.
I want to pipe the error messages to a file so that I can read from the top, but normal methods don't seem to work.
I've tried:
ghc File.hs > errors.log
ghc File.hs >> errors.log
ghc File.hs | more
None of them work. Using > and >> only writes the first couple of lines to the file and then the rest to standard output. Using more, less, cat etc doesn't make any difference at all.
Is there a flag for GHC that will let me output to a file?
(I should probably let you know that I'm working on a Windows machine with Cygwin.)
Most programs write output to the standard output (file descriptor 1) and error messages to the standard error (file descriptor 2).
You can ask your shell to redirect the standard error to another location like this:
ghc File.hs > output.log 2> errors.log
or if you want them in the same file:
ghc File.hs > output.log 2>&1
See your shell's manpage section of redirections for full details. Note that the shells are picky about the order of the redirections.
You can also view the output directly, using the same redirect as sarnold's solution, but without the intermediate output file:
ghc File.hs 2>&1 | less
(same goes for more instead of less, etc.)