I have a C program foo which I am compiling and debugging with GDB just fine. (I'm using QtCreator as an IDE if relevant).
When I call function bar(), in library libbar.so.1, in debian package libbar1, I don't get the expected result so I'd like to step into it.
apt source libbar1 gets sources for libbar.so.1 and I've found the implementation of bar() in /tmp/libbar-1.0/src/bar.c.
apt install libbar1-dbgsym installs the debugging symbols to /usr/lib/debug/.build-id/{22,fb}/*.debug
How can I debug foo and step into the implementation of bar() in GDB?
I suspect I must have to add startup commands to GDB with the location of debug symbols and sources.
I've tried adding this to gdb startup commands:
> directory /tmp/libbar-1.0/src/
Next, I'm thinking it might be related to set substitute-path from to, but I'm not sure whether /tmp/libbar-1.0/src goes in from or to and what the other one would be.
GDB complaining about missing raise.c gave me a start to solving this. This is the full solution where I don't have the luxury of halting on a signal during runtime:
We need the following from the Debian archive:
sudo apt install libbar1: This deploys /usr/lib/x86_64-linux-gnu/libbar.so.1. It's already installed if your program is running.
sudo apt install libbar1-dbgsym: This deploys /usr/lib/debug/.build-id/22/*.debug
apt source libbar1: This deploys ./libbar-1.0/src/bar.c
Now we need to open the library in gdb and look for the original source path:
$ gdb /usr/lib/x86_64-linux-gnu/libbar.so.1
...
Reading symbols from /usr/lib/x86_64-linux-gnu/libbar.so.1...Reading symbols from /usr/lib/debug/.build-id/22/8b32043be712018feacacb319a48ebf5400ebf.debug...done
(gdb) info sources
./obj-x86_64-linux-gnu/./src/bar.c
The ./obj-x86_64-linux-gnu/. is important. This was the original location where the sources were built. We need to substitute that with the location of our sources so GDB can find them and add that new path to our list of searchable sources:
(gdb) set substitute-path ./obj-x86_64-linux-gnu/. /tmp/libbar-1.0
(gdb) directory /tmp/libbar-1.0
Source directories searched: /tmp/libbar-1.0:$cdir:$cwd
(gdb) info sources
/tmp/libbar-1.0/src/bar.c
(gdb) list bar
2 int bar(int x) {
3 return x+1;
4 }
You're using QtCreator to drive gdb. In that case under "Tools > Options > Debugger > GDB" there is a text box labeled: "Additional Startup Commands". Add the following to that text box and you can debug!
set substitute-path ./obj-x86_64-linux-gnu/. /tmp/libbar-1.0
directory /tmp/libbar-1.0
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 install the xv6 OS on my macOS (version 10.14.3) following the instructions of this site, only with the newest versions of the needed files and when I'm getting at the binutils configuration stage I'm getting from my terminal:
Config.guess failed to determine the host type. You need to specify one.
Usage: configure [OPTIONS] [HOST]
Options: [defaults in brackets]
--prefix=MYDIR install into MYDIR [/usr/local]
--exec-prefix=MYDIR install host-dependent files into MYDIR[/usr/local]
--help print this message [normal config]
--build=BUILD configure for building on BUILD [BUILD=HOST]
--host=HOST configure for HOST [determined via config.guess]
--norecursion configure this directory only [recurse]
--program-prefix=FOO prepend FOO to installed program names [""]
--program-suffix=FOO append FOO to installed program names [""]
--program-transform-name=P transform installed names by sed pattern P [""]
--site=SITE configure with site-specific makefile for SITE
--srcdir=DIR find the sources in DIR [. or ..]
--target=TARGET configure for TARGET [TARGET=HOST]
--tmpdir=TMPDIR create temporary files in TMPDIR [/tmp]
--nfp configure for software floating point [hard float]
--with-FOO, --with-FOO=BAR package FOO is available (parameter BAR)
--without-FOO package FOO is NOT available
--enable-FOO, --enable-FOO=BAR include feature FOO (parameter BAR)
--disable-FOO do not include feature FOO
Where HOST and TARGET are something like "sparc-sunos", "mips-sgi-irix5", etc.
What can I do to solve it? does anyone have better and validated instruction for installing xv6 on macOS? (I've also tried this website and it didn't work of course.)
all I needed to do is:
Install xCode and agree the terms of use.
Download xv6 from https://github.com/mit-pdos/xv6-public.
Install MacPorts from https://www.macports.org/.
Open a terminal window where I downloaded the OS.
Install Qemu by writing sudo port install qemu.
sudo port install i386-elf-gcc gdb.
Replace the existing Makefile to a new one.
In order to run, write in the terminal window make qemu clean.
I am trying to use CLion on Windows and I installed my environment using cygwin but I'm getting this warning in the settings. Moreover, it's almost impossible to debug because the debugger just stops showing debugger info in the middle.
I had the very same problem. I wasn't able to make CLion work with gdb 7.10.x but I was able to make cygwin install gdb 7.8-1. My method should work to install any version you want.
The following steps describe the way I managed to do it, I'm a newbie using cygwin, so maybe some of them are unnecessary.
Create a cache directory for cygwin and place the cygwin setup.exe in it (in my case C:\cygwinCache). [Source]
Execute the setup.exe and follow the usual steps for installing from Internet. Select Install from Internet, select your cygwin root directory (in my case C:\cygwin64), create and select a directory inside your cygwin cache directory (in my case C:\cygwinCache\downloaded), select the connection option your Internet connection requires, then select any server with gdb available (I selected http://cygwin.mirror.constant.com) and click Next. This will download and parse a setup.ini file that contains the available packages in the server you selected. This setup.ini file will be located in your cache directory in a sub directory named after the server you selected (C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64).
From the link that #H. DJEMAI found (this one) download the gdb installation and source files of the version you want (I downloaded gdb-7.8-1.tar.xz and gdb-7.8-1-src.tar.xz). As a backup, I uploaded these files in here.
In the directory where the setup.ini file is located create the \release\gdb directory. In this newly created \release\gdb directory place both of the gdb files you downloaded in the last step. Now you have the gdb installation and source files in the following paths:
C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\gdb\gdb-7.8-1.tar.xz
C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\gdb\gdb-7.8-1-src.tar.xz
Open the setup.ini file, and look for a line with this string: # gdb. This section has the information of the gdb package and information about the files it may contain. It should look like this:
# gdb
sdesc: "The GNU Debugger"
ldesc: "The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data."
category: Devel
requires: cygwin libexpat1 libiconv2 libintl8 liblzma5 libncursesw10 libreadline7 python
version: 7.10.1-1
install: x86_64/release/gdb/gdb-7.10.1-1.tar.xz 2670932 cd1fa152888faa3e4cb8e1d075604fb2e039d73acdd159d7c9553741fd7710778c742495c93476b234e3386d54bd5bdc5275007290b6eb940d70197feb21b573
source: x86_64/release/gdb/gdb-7.10.1-1-src.tar.xz 18542336 758428a83148af8425cff2712ac15d842f449d824f0edc9bb8db1d1d84bf963e2f371372d0c645408c202914ffb088a9da32be5a9b62a637a71f2fe9b7d4614f
[prev]
version: 7.9.1-1
install: x86_64/release/gdb/gdb-7.9.1-1.tar.xz 2550148 f62f65865a11757b945f431a3662e16d0357dc9a0cbc720d16f5e99543cd3231f34bacd245daeb113ad38501358d9b1e7d128a1a45871d02c2bfb1c15891fbcb
source: x86_64/release/gdb/gdb-7.9.1-1-src.tar.xz 17888340 b90d198404a0a16268b443f4a4ec9672dac1d531f3fbda848f807fee7c004f5394e1985253c64ab0cdc2dcf7c088645c60edbf8e9f39dce0f149bce4b11f5085
Now edit the file to make cygwin install the version you want. To achieve this modify the lines where it says version, install and source with the information of the files you want to install. I modified the lines after the [prev] string replacing 7.8-1 instead of 7.9.1-1 so cygwin points to the correct location. Note that the lines that start with install: and source: contain the relative location of the files you previously downloaded and placed in the \release\gdb directory. After this relative location the setup.ini file contains the byte size and SHA-512 of the specified file. You can get the bite size for your file in the file properties. To get the SHA-512 you have to use other software like this one. In the case of the 7.8-1 files I got the following:
# gdb
sdesc: "The GNU Debugger"
ldesc: "The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data."
category: Devel
requires: cygwin libexpat1 libiconv2 libintl8 liblzma5 libncursesw10 libreadline7 python
version: 7.10.1-1
install: x86_64/release/gdb/gdb-7.10.1-1.tar.xz 2670932 cd1fa152888faa3e4cb8e1d075604fb2e039d73acdd159d7c9553741fd7710778c742495c93476b234e3386d54bd5bdc5275007290b6eb940d70197feb21b573
source: x86_64/release/gdb/gdb-7.10.1-1-src.tar.xz 18542336 758428a83148af8425cff2712ac15d842f449d824f0edc9bb8db1d1d84bf963e2f371372d0c645408c202914ffb088a9da32be5a9b62a637a71f2fe9b7d4614f
[prev]
version: 7.8-1
install: x86_64/release/gdb/gdb-7.8-1.tar.xz 2491984 4c8d81984fe2ccbf92614c857737a42c4ec0c4016a5f8cf1dbc0fd117a1978baa7a8eadd2415a6d52041a1eecbe6b4e1373ba6850db6584869311a5e02a6e3b2
source: x86_64/release/gdb/gdb-7.8-1-src.tar.xz 17669132 a71b6886774cb004baa7dc88ed767983a72fc94c7585bd79ff64c2bd2071c411cf0de76584c56aa3553d9541172eaf31f1dd142a6dedec50c5446ff2986c6d48
Don't forget to save the setup.ini file after you modified it.
Open the cygwin setup inside the cache directory. Now instead of selecting the install from Internet option select Install from Local Directory, then set your root directory and as local package directory select your cache directory (C:\cygwinCache\downloaded). It will parse the setup.ini file, and if you edited it successfully, it will show you the grid to install, upgrade or uninstall packages. If the parsing fails an error will be shown.
Look for the gdb package under Devel category, it should appear installed with a current version:
Click it where it says Keep until you see the version you want. Then click next, this will start the installation, when the process is done, click finish.
You're done. You can open the cygwin terminal and type gdb --version and see that the correct version is installed:
After all these steps, now you can open clion and go to Settings > Toolchains and see the result:
PS. I achieved this with cygwin setup version 2.873 (64 bits).
While LuissRicardo's answer seems like it will work, I stumbled upon a solution online that is a lot more straightforward. See: http://kennyroh.blogspot.co.uk/2016/04/cygwin-clion-gdb-current-version-is-gnu.html
Download gdb-7.8-2.tar.xz from http://cygwin.mirror.constant.com/x86_64/release/gdb/ and put it somewhere in your Cygwin filesystem.
Open a Cygwin terminal at that location, and run: tar Jxvf gdb-7.8-2.tar.xz. The instructions use zxvf, but that won't work for .xz archives.
cd into the folder you just extracted (for me this was just cd usr).
Run the command cp -R * /usr/ to copy this to the correct location in the filesystem.
Run gdb --version just to make sure it's set to 7.8.2. If it's not then maybe try restarting Cygwin, and if that doesn't work then maybe post on StackOverflow or something :p
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).