Packages that are distributed without using stack or cabal usually have a set of implied dependencies. This sometimes mean that running ghc directly on said packages will not work without installing packages into ghcs global package database.
I would like to use stack ghc as a replacement for ghc to this end I have defined the following in my shells init file:
export PATH="`stack path --compiler-bin`:$PATH"
Now the command ghc will use stack's ghc - it does not however do the same as stack ghc. For one, it does not load the "snapshot" and "global-project" package database as can be seen with the following commands:
$ ghc -v
Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3
Using binary package database: ~/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/package.conf.d/package.cache
...
$ stack ghc -- -v
Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3
Using binary package database: ~/.stack/programs/x86_64-linux/ghc-nopie-8.0.1/lib/ghc-8.0.1/package.conf.d/package.cache
Using binary package database: ~/.stack/snapshots/x86_64-linux-nopie/lts-7.9/8.0.1/pkgdb/package.cache
Using binary package database: ~/.stack/global-project/.stack-work/install/x86_64-linux-nopie/lts-7.9/8.0.1/pkgdb/package.cache
...
Does anyone have guidance on how to achieve using stack ghc as a replacement for ghc.
The use-case I currently have is that I have been given a make-file that refers to ghc - but I do not have this command on my machine.
If you execute the makefile within stack exec, it will set the GHC_PACKAGE_PATH environment variable. It will also extend PATH appropriately.
Alternatively, to have this set in your shell you could do
export GHC_PACKAGE_PATH=`stack path --ghc-package-path`
Related
Using Windows 10 64-bit, Cabal-3.4.0.0, ghc-8.10.7.
I installed OpenBLAS in MSYS2 environment with command
pacman -S mingw-w64-x86_64-openblas.
Than, I successfully installed hmatrix-0.20.2 with command
cabal install --lib hmatrix --flags=openblas --extra-include-dirs="C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\bin" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\lib"
I am trying to build simple test project using cabal build cabalhmatrix with Main
module Main where
import Numeric.LinearAlgebra
main :: IO ()
main = do
putStrLn $ show $ vector [1,2,3] * vector [3,0,-2]
But now I am getting output
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
- hmatrix-0.20.2 (lib) (requires build)
- cabalhmatrix-0.1.0.0 (exe:cabalhmatrix) (first run)
Starting hmatrix-0.20.2 (lib)
Failed to build hmatrix-0.20.2. The failure occurred during the configure
step.
Build log (
C:\cabal\logs\ghc-8.10.7\hmatrix-0.20.2-6dd2e8f2795550e4dd624770ac98c326dacc0cac.log
):
Warning: hmatrix.cabal:21:28: Packages with 'cabal-version: 1.12' or later
should specify a specific version of the Cabal spec of the form
'cabal-version: x.y'. Use 'cabal-version: 1.18'.
Configuring library for hmatrix-0.20.2..
cabal-3.4.0.0.exe: Missing dependencies on foreign libraries:
* Missing (or bad) C libraries: blas, lapack
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.If
the library files do exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
cabal-3.4.0.0.exe: Failed to build hmatrix-0.20.2 (which is required by
exe:cabalhmatrix from cabalhmatrix-0.1.0.0). See the build log above for
details.
What should I do to correctly build that package?
I guess I need to somehow pass arguments --flags=openblas --extra-include-dirs="C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\bin" --extra-lib-dirs="C:\\ghcup\\msys64\\mingw64\\lib" to hmatrix during compilation, but don't know how to do that. To be honest, I don't understand for what program exactly are those arguments (cabal, ghc, ghc-pkg or something else) and why cabal is trying to install hmatrix again. I see hmatrix in directory "C:\cabal\store\ghc-8.10.7\hmatrix-0.20.2-e917eca0fc7690010007a19f4f2a3602d86df0f0".
Created cabal.project file:
packages: .
package hmatrix
flags: +openblas
extra-include-dirs: C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS
extra-lib-dirs: C:\\ghcup\\msys64\\mingw64\\bin, C:\\ghcup\\msys64\\mingw64\\libenter code here
After adding libopenblas.dll location to PATH variable cabal project is working.
Even though there is the --lib flag, it's generally best to work under the assumption that Cabal doesn't do library installs. Never install a library, instead just depend on it – and have Cabal install, update etc. it whenever necessary.
But then how can you pass the necessary flags? With a cabal.project file.
packages: .
package hmatrix
flags: openblas
extra-include-dirs: C:\\ghcup\\msys64\\mingw64\\include\\OpenBLAS
...
Put this file in the working directory of your own project, together with cabalhmatrix.cabal. Then running cabal build in that directory will use a hmatrix install with the suitable library etc. flags.
I'm trying to use pp (the perl compiler) to create an application that can run independent of the perl installed library and interpreter.
It successfully creates a compiled executable although I had to use the -x -c options to get it to find dependencies successfully. It will run on my machine but when I try it on another machine I get this error so clearly there is still some dependency:
501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)
I am running it on MacOS 10.14.1 if that makes any difference. Thanks!
LWP::Protocol::https is loaded dynamically when needed, so pp has no way of knowing it's needed by default.
Solution 1
Pass -x to pp, and make sure the module is actually loaded in the run pp uses to determine the modules to include. This would probably be achieved by using LWP to make an HTTPS request during that run. --xargs=... might come in useful for this.
Solution 2
Pass -M LWP::Protocol::https to pp. You could also pass -M 'LWP::Protocol::**' to get all protocols handlers you have installed.
Solution 3
Add use LWP::Protocol::https (); to your script or an included module. Including a comment indicating why you are doing this would be appropriate.
You were building Net::SSLeay on MacOS 10.14 linking it to libssl.44.dylib which is not present on MacOS 10.12 where you try to run it.
I've found it annoying having to switch between build and test systems to find out which of the libraries are missing or incompatible and need to be packed.
I am now using the following strategy:
I use perlbrew instead of system perl.
For alien dependencies I use homebrew instead of the system libraries.
I build the packed executable using pp and run the resulting program with export DYLD_PRINT_LIBRARIES=YES being set (on the development machine)
I examine the list of loaded libraries and add all those referenced in the homebrew directory tree (/usr/local/opt/ and /usr/local/cellar/in my case) using pp -l /full/path/name -l ...
I rebuild the executable.
I still check on a target machine before deploying, but chances are very high now that it just works.
I'm trying to compile the libxkbcommon library for kodi for my Raspberry Pi 2.
The host machine is a dedicated Server running Ubuntu 16.04 x64.
Now there are two errors when I'm trying to compile libxkbcommon, depending on what yacc I'm using:
byacc:
YACC src/xkbcomp/parser.c
yacc: e - line 219 of
"/opt/kodi/xbmc/tools/depends/target/libxkbcommon/raspberry-pi2-release/src/xkbcomp/parser.y", syntax error
%destructor { FreeStmt((ParseCommon *) $$); }
^
Makefile:1637: recipe for target 'src/xkbcomp/parser.c' failed
btyacc:
parser.y:85: syntax error
Here is the source code of libxkbcommon:
https://github.com/xkbcommon/libxkbcommon
The xbcomp/parser.y file requires a number of (very useful) bison extensions, so it can't be processed by all yacc variants.
btyacc does not support bison-compatible pure-parser declarations. (It has a different, not entirely compatible mechanism which implements the same feature.) So it fails on the first instance of one of those declarations.
It should be possible to use byacc, but not the version which is available in the Ubuntu package repository. Although the Ubuntu package repository change history seems to suggest that the intention was to include the build option which allows %destructor, the actual binary currently available in the byacc repository was built without that option. (It is also several years old, and I think it would be useful to use a more recent version.) I reported this as launchpad bug 1776270, along with a suggestion for a possible fix.
I'm sure you'll be able to build the software using Gnu bison, which is available as the Ubuntu package bison. Since that's the most popular yacc version installed on developer machines, a failure to build with bison would probably have been noticed long ago.
If you would prefer to use byacc, for whatever reason, you'll have to download and build it yourself. You can get the most recent version from Thomas Dickey's byacc page, and then build it with the usual procedure: untar, configure, make, make install. When I tested this, I used the following configure line:
./configure --enable-btyacc --program-prefix=b --prefix=/usr
Only the first option is mandatory
* --program-prefix=b Install it as `byacc` rather than `yacc`
* --enable-btyacc Necessary for %destructor support
* --prefix=/usr Install it in /usr/bin and /usr/man. The default
is /usr/local/bin and /usr/local/man, which failed on
my Ubuntu install because of a missing -D option in the
install command in the Makefile.
My current problem is with libwebkitgtk-3.0-0, but I guess this problem is generic enough.
My application is crashing somewhere in the webkit code. My assumption is we are doing something stupid and want to find out what. Easiest thing will be to set a breakpoint or use debug version of library.
How do I get exact source code with which library was built? I am getting stack trace after it dumps the core, but line number gdb is saying do not match with those I see in the code. In other words if I install libwebkitgtk-3.0-0 I want to get exact source code of that.
I have installed debug version of webkit library. Do these debug versions have same functionality as if you are compiling webkit with with --enable-debug flag? Debug versions of webkit enable logging based on WEBKIT_DEBUG environment variable, but I could not get the same logging even if use debug version of library.
How to use the debug version I managed to compile? I managed to compile webkit on my machine and tried fiddling with load paths and such. My application does not pickup new shared library no matter what I do - I can tell based on user agent signature. At one point, I managed to pick up the library, but then SSL stops working. Same SSL problem does happen with GtkLauncher. So I am making mistake somewhere.
Thanks for the pointers.
TL;DR: Install libwebkitgtk-3.0-0-dbg , then you have the necessary debug symbols.
##For debug symbols, you don't usually have to install from source.
As you know, to get debug symbols for software you're building yourself, you can run GCC with -g.
For software installed through your operating system's package manager (which includes libwebkitgtk-3.0-0, here), at least for official packages, there are usually also packages providing debug symbols.
You don't actually need to have a debug build of a program or library to get a symbolic stack trace in gdb. gdb also supports files providing "add-on" debug symbols in /usr/lib/debug.
You use Ubuntu, according to the tags on your question. On Ubuntu, debug symbol packages are available in two varieties: -dbg and -dbgsym. A program or library located at /path gets debug symbols at /usr/lib/debug/path.
##-dbg Packages
These packages are often named differently from the corresponding packages providing the actual executables or library files. They are often named similarly to -dev packages (which provide header files) and -doc packages. A -dbg package sometimes has less library version numbering in the name than the actual library packages, sometimes covering binaries provided in multiple other packages.
For example, libgtkmm-3.0-1's corresponding -dbg package is libgtkmm-3.0-dbg.
On the other hand, sometimes a -dbg package is named the same as the package whose symbols it provides (except the -dbg suffix). For example, libwebkitgtk-3.0-0's corresponding -dbg package is libwebkitgtk-3.0-0-dbg. That's the one you want.
You can install it in the Software Center or by running:
sudo apt-get update && sudo apt-get install libwebkitgtk-3.0-0-dbg
Now, when you debug a program that links to a library provided by libwebkitgtk-3.0-0, gdb will automatically load symbols from a file provided by libwebkitgtk-3.0-0-dbg.
##-dbgsym Packages
Sometimes binary executables provided by an official package don't have symbols provided in any -dbg package. When this happens, usually you can install the -dbgsym package.
Unlike -dbg packages, -dbgsym packages:
are almost always simply (and predictably) named X-dbgsym where X is the package providing the program or library itself.
are provided by special software sources (repositories), not the same software sources as provide the corresponding program/library packages and -dbg packages.
Since -dbgsym packages are in separate repositories, you must enable these repositories. Their DEB lines are:
deb http://ddebs.ubuntu.com YOUR_RELEASE main restricted universe multiverse
deb http://ddebs.ubuntu.com YOUR_RELEASE-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com YOUR_RELEASE-security main restricted universe multiverse
deb http://ddebs.ubuntu.com YOUR_RELEASE-proposed main restricted universe multiverse
To enable them, you can run these commands (adapted from DebuggingProgramCrash by "Contributors to the Ubuntu documentation wiki", section 2):
echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-security main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse
" | sudo tee -a /etc/apt/sources.list.d/ddebs.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01
sudo apt-get update
Leave out the italicized lines, if you are on a development release (alpha or beta). Make sure to add them if you continue using the release once stable, though.
Those commands do three things:
Create the file /etc/apt/sources.list.d/ddebs.list (which contains the DEB lines).
Import the signing key for these repositories.
Update your system's information about what packages and versions are available for installation from where.
So if you ever want to use the -dbgsym-provided symbols instead of the -dbg provided symbols, the -dbgsym package for libwebkitgtk-3.0-0 is (in accordance with the simple naming convention above) libwebkitgtk-3.0-0-dbgsym.
You can have both -dbg and -dbgsym packages installed on the same system, but not if they provide symbols for any of the same files. So libwebkitgtk-3.0-0-dbg and libwebkitgtk-3.0-0-dbgsym conflict with each other; they cannot both be installed (at the same time).
##Using the Symbols
On most Unix-like OSes, the debugger will automatically look for installed symbols. Ubuntu is no different--in Ubuntu, gdb automatically looks for them in /usr/lib/debug. So you don't need to do anything special.
However, if you ever did need to tell gdb to load a specific debug symbol file, you would use the -s file flag. See the GNU manual and gdb(1) for details.
1) When I need to dig into a library that I installed through a package, the first thing I do is install it from source. I mean configur/make/make install. I typically put the source code in /usr/local/src and install it in /usr/local . This, in my opinion is the most reliable way of running the exact code for which you have the source.
3)
How to use the debug version I managed to compile?
This sounds like you did what I described above. What you need to do is make sure that your software is using the include and link directories that are hosting your compiled, debug enabled, library. Meaning making sure that -I/usr/local/include and -L /usr/local/lib flags are set and they come before /usr/include and /usr/lib.
You can be even more certain by removing the binary version of the libraries from the ubuntu installation, making sure that that version that you built and installed is the only version present on the hard disk. This way you will know for sure that you were able to configure your app to use that library. Otherwise it'll just fail, instead of you constantly wondering whether it's using the new library or the old library.
2) Typically yes. But it'd depend on how the library is written, and what the ubuntu packager decided to do.
Once you compile the program using your locally built library, see if you are getting the same exact error first. If not then that is also a data point. Maybe the problem got fixed since the last time ubuntu packaged the library. Maybe the library is not packaged properly and that's the problem. You might even get new errors, because the ubuntu packager configured the library a certain way so that it'd work and you didn't do the same thing. You will get interesting leads anyway.
Good luck
#Eliah's answer tells how to get symbols in a convenient way.
The question remains, "how do I get the exact source code?".
I normally do apt-get source <pkgname> which is well and good except then I must manually tell gdb dir <path-to-wherever-I-put-the-source> and woe betide if it is a package like eglibc where one must figure out that the path references are from the nss subdirectory, not the root.
On RHEL one simply does e.g. yum install --enable-repo rhel-debuginfo libX11-debuginfo (just yum install libX11-debuginfo on CentOS 7) and instantly you get full symbols and source in gdb with no extra messing around. I'm still looking for that convenience on Ubuntu.
In order to debug against dynamic libraries you can add the dgb gears with symbol and source distro packages as suggested.
Then it's necessary to check if the compilation directories of the debug symbol table matches the paths of the installed source, if it's not you should mapping the paths in gdb. Following the commands to enable debugging of glibc
$ objdump -g /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.27.so | sed -n '/<.*>\s\+DW_AT_comp_dir/ {s/\s\+<.*>\s\+//; p;}' | sort | uniq
DW_AT_comp_dir : (indirect string, offset: 0x1127a): /build/glibc-OTsEL5/glibc-2.27/malloc
...
DW_AT_comp_dir : (indirect string, offset: 0xd139): /build/glibc-OTsEL5/glibc-2.27/stdio-common
DW_AT_comp_dir : (indirect string, offset: 0xef40): /build/glibc-OTsEL5/glibc-2.27/libio
$ ls -ld glibc-2.27/{stdio-common,libio}
drwxrwxr-x 3 fusillator fusillator 12288 feb 1 2018 glibc-2.27/libio
drwxrwxr-x 3 fusillator fusillator 4096 feb 1 2018 glibc-2.27/stdio-common
$ gdb ./hello
Reading symbols from ./hello...done.
(gdb) set substitute-path /build/glibc-OTsEL5/glibc-2.27 glibc-2.27
(gdb) b main
Breakpoint 1 at 0x63e: file hello.c, line 10.
(gdb) run
Starting program: hello
Breakpoint 1, main () at hello.c:10
10 printf("hello world\n");
(gdb) s
_IO_puts (str=0x5555555546e4 "hello world") at ioputs.c:33
33 {
(gdb) backtrace
#0 _IO_puts (str=0x5555555546e4 "hello world") at ioputs.c:33
#1 0x000055555555464a in main () at hello.c:10
I am trying to update the glfw package to use glfw 2.7 on the mac. The problem becomes that there is a new cocoa port which introduces 'm' files.
So I wanted to use the -x c option on just those files, but I can't figure out how to get it to operate just on these 'm' files.
The relevant section of my cabal file:
if os(darwin)
include-dirs: glfw/lib/cocoa
frameworks: AGL Cocoa OpenGL
cc-options: -msse2
ghc-options: -x c -- **** global not just local.
c-sources:
glfw/lib/cocoa/cocoa_enable.m
glfw/lib/cocoa/cocoa_fullscreen.m
glfw/lib/cocoa/cocoa_glext.m
glfw/lib/cocoa/cocoa_init.m
glfw/lib/cocoa/cocoa_joystick.m
glfw/lib/cocoa/cocoa_thread.m
glfw/lib/cocoa/cocoa_time.m
glfw/lib/cocoa/cocoa_window.m
Any ideas how I can fix this cabal issue?
My source code resides at https://github.com/iaefai/glfw-haskell if you want to test it.
Try the GLFW-b bindings instead. I've worked with the author of GLFW-b to make all the necessary changes to get 2.7 working on OSX. It even works in GHCI.
You can cabal install nehe-tuts to see a demo of it working.
There's no way to do it via a .cabal flag. You may need to do a pre-processing stage manually (e.g. cabal makefile mode or configure mode).