I am trying to compile the openlase library from www.marcansoft.com and have been running into problems with CMake. CMake is returning an error stating that it cannot find Curses, and after a lot of looking I am still stumped as to what the issue is. I have checked that I have the various ncurses packages installed but still the error persists. Im not very familiar with CMake but I was able to resolve other dependency issues that arose before this one. The following is the output in terminal.
tom#SILVER:~/dev/openlase$ cmake ./
-- Found JACK
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH)
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindCurses.cmake:159 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
examples/27c3_slides/CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
Any help would be greatly appreciated.
Tom
Here is what fixed my problems on Ubuntu 12.04 x86_64 (64 bit) (Thanks syslogic )
For whatever reason (1:00 am maybe?) setting CURSES_USE_NCURSES TRUE didn't seem to work. So I went with a hack job.
Verified it's installed:
$ sudo apt-get install libncurses5-dev
You will see something to the effect: libncurses5-dev is already the newest version.
So find the library and include.
$ locate libncurses.so
Note location, mine: /usr/lib/x86_64-linux-gnu/libncurses.so
$ locate curses.h
Note location again, mine:
/usr/include
In: <cmake source dir>/Modules/FindCurses.cmake
add at the top, right after the comments
set( CMAKE_INCLUDE_PATH "/usr/include")
set( CMAKE_LIBRARY_PATH "/usr/lib/x86_64-linux-gnu/libncurses.so")
then rinse repeat the build process
./bootstrap
make
sudo make install
ccmake should now be installed.
Your pal,
Another way to fix it is to add these 2 lines to FindCurses.cmake (on top):
set(CURSES_LIBRARY "/opt/lib/libncurses.so")
set(CURSES_INCLUDE_PATH "/opt/include")
Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
Do you have the corresponding -dev package installed too? On Ubuntu (and probably anything derived from Debian) it is libncurses5-dev. Other systems may use -devel or similar tags.
The compiler is looking for the library headers, and those aren't provided by the standard package. (The headers aren't needed at runtime, only when compiling software, so they make it easy to remove extra useless stuff for systems that aren't going to be doing any software compiling.)
The openlase wiki was not displaying all of the needed packages. Check there wiki pages on github for updated instructions. For curses the missing package was libncurses5-dev sudo apt-get install libncurses5-dev
Temporarily set CURSES_NEED_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
set(CURSES_NEED_NCURSES TRUE)
CURSES_USE_NCURSES is used by FindCurses.cmake internally, so setting that won't help.
Related
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
Background:
I've been using the gloss library for some simple diagram work. But when it came time for something more interactive, I found I wanted a more powerful library. After doing some research, I decided that I liked the features of the SDL library and wanted to try to install the Haskell bindings for it. I have to this point been unsuccessful.
Part 1:
How do I install and configure the SDL binaries so that they can be used by the Haskell bindings?
Part 2:
Which one of the numerous and ill documented SDL packages on Hackage it the current preferred binding in the community? How do I get that package to install correctly?
Part 3: (Optional)
If SDL is not a good fit for haskell development what is the preferred alternative?
I am going to answer your question for SDL2 (should also work for SDL1 with some modifications).
Install pkg-config for Windows
(How to install pkg config in windows?)
This tool is very important. It is used by various Cabal packages to search for libraries and contains directions for linking and compiling.
Download the SDL development libraries for Windows/MinGW:
http://libsdl.org/release/SDL2-devel-2.0.3-mingw.tar.gz
If you have installed the 32-bit version of the Haskell platform, extract the folder i686-w64-mingw32
For 64-bit versions extract x86_64-w64-mingw32
You will get following layout:
include
share
bin
lib
"Register" the library with pkg-config.
Either copy lib/pkgconfig/sdl2.pc into the folder of your pkg-config.exe or modify/create the PKG_CONFIG_PATH accordingly. Check that you set up everything correctly:
C:\pkg-config --list-all | grep sdl2
sdl2 sdl2 - Simple DirectMedia Layer is a cross-platform multimedia
library designed to provide low level access to audio, keyboard,
mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.
Add the bin folder to your PATH environment variable.
Install the sdl2 package via the Cabal installer and tell Cabal where to find your libraries.
Example:
cabal install sdl2 --extra-include-dirs=C:\lib\sdl2\include --extra-lib-dirs=C:\lib\sdl2\lib\
To test my installation, I have written a small example:
https://github.com/ftl2014/haskell-stuff/blob/master/sdl/
Caveat emptor:
If Cabal complains about a "missing" library, it might be the case that library was actually found but it is incompatible (e.g. using a 32-bit instead of a 64-bit version) or corrupt. The same is true for header files.
For some reason, Cabal complained about not finding SDL.h, and I had to use the headers in the root include folder of the archive (but maybe I was just drinking too much Kool-aid).
I wasn't able to get it to install on my system. Here's what I tried. Strangely, I was able to get configure find the header files but not the actual binary.
Let's try it. I have installed the new 2014 Haskell Platform.
cabal install sdl
Configuring SDL-0.6.5...
setup.exe: The package has a './configure' script. This requires a Unix
compatibility toolchain such as MinGW+MSYS or Cygwin.
Failed to install SDL-0.6.5
GHC in the Haskell Platform comes with MinGW, so we probably need to install MSYS. The MSYS page says to install minggw get, which says to install
An automated GUI installer assistant called mingw-get-setup.exe is the preferred method for first time installation. This will guide you through the setup of the mingw-get installer proper; you will then use this to perform further package installations, and to manage your installation.
Running the installer with the default options gives us the following screen:
We already have mingw from installing the Haskell platform, so we'll click on only the last item in the list, msys-base, and select "Mark for Installation". Then, in the "Installation" menu in the top left, select "Apply Changes". This asks if it is ok to proceed, and we select "Apply"
This installer didn't put msys-base in the path, we can add it to the path, and try installing sdl again
set PATH=C:\MinGW\msys\1.0\bin\;%PATH%
cabal install sdl
Configuring SDL-0.6.5...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for sdl-config... no
checking for sdl11-config... no
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5
We need to download and install libsdl. I went to the libsdl download page and downloaded the Win32 development libraries, SDL-devel-1.2.15-mingw32.tar.gz. I extracted this archive (7-zip can extract both tar archives and gzip compressed files). For convenience, I moved the SDL-1.2.15 directory to c:. We'll add this to the path, as suggested by the previous error, and try again
set PATH=C:\SDL-1.2.15\bin\;%PATH%
cabal install sdl
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
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.
If the header file does 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.
We can make part of this error go away by adding the suggested --extra-include-dirs flag, but still get the following error
cabal install sdl --extra-include-dirs=c:\SDL-1.2.15\include
* Missing C library: SDL
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.
Adding the --extra-lib-dirs flag with c:\SDL-1.2.15\bin or C:\SDL-1.2.15\lib or c:\SDL-1.2.15 failed to fix this problem.
I'm attempting to build a new version of wireshark 1.10 on a RHEL5 box with the intent of making an RPM so that customers that I support can install it. Possibly others if I can find a place to host it.
WS1.10 depends on GTK+ as well as several other libraries that aren't supported by the available rpm packages. Therefore, I have to build them by hand. GTK+ needs pango(1.24.5) with cairo(1.8.8) support.
After having built and installed a newer version of cairo from source, a ./configure of pango gives the following error
checking for CAIRO... yes
checking which cairo font backends could be used... none
configure: Disabling cairo support
and then at the end ./configure displays
configuration:
backends: X
I can verify that Cairo is installed by looking at the pkg_config in my /usr/local/lib.
I've even taken a look at the pango config.log. But I don't see anything that is any different then the messages I copypasta'ed above.
What are some places I should be looking to figure out a less terse error message? I'm kind of at a loss troubleshooting this.
I encountered this issue today and solved it by installing HARFBUZZ, which is mentioned in the README file of Pango. After installation of Harfbuzz we have access to FreeType. So follow this procedure:
Build and install FreeType
Build and install fontconfig
Build and install Cairo (after ./configure please make sure freetype and fontconfig are found)
Build and install Harfbuzz
Build and install Pango
In case of you still have problems even though you are following the guideline of Xiao Jia, take care to look into config.log. It will help you to find out why the package does not find particular components on your system. In my case the fontconfig-devel and freetype-devel package from default repository of my distro was too old.
I could manage it by installing the whole stack into a location outside of /usr (not that difficult as it sounds) by adding configuration file to /etc/ld.so.conf.d and a environment expanding script to /etc/profile.d.
I am trying to compile VIM with native support for ruby and am using MinGW for that.
The compilation goes as expected until the make file tries to execute windres -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 ..... vim.rc gobj/vimres.res
This step failes with a windres: unexpected version string length 68 != 32 + 8. I am at a complete loss what kind of error this is and how I am supposed to fix it.
As far as I can see I downloaded the newest version of both the vim sources and MinGW environment.
Searching the internet hinted me at trying to do a mingw-get install --reinstall binutils=2.22-1 which I did. But I still get the same error message.
It seems that the
mingw-get install --reinstall binutils=2.22-1
did not actually install a previous version.
Instead, with
mingw-get remove binutils
mingw-get install binutils=2.22-1
I was able to install the previous version. Now, the windres step works.
I just compiled Vim with MinGW/MSYS and among others dynamic ruby support. Check out this gist for a guide through the process with gvim74.exe installation file as output.
I experienced a (for me) strange behaviour today: Using QMake with the PkgConfig-options etc. I was able to link the opencv libraries, but then I switched to CMake using PkgConfig. Once I tried to build my software, the linker complained that it was not able to find the library libcvaux, which pkg-config returns asked to deliver the libraries for opencv (pkg-config --libs opencv).
In /usr/lib I found a libcvaux.so.{version}, but no "plain" entry libcvaux.so. So what I did was to create a symlink, and now it works.
Now I wonder why it worked before. Is there something to pass ld an option saying "use the newest version, and you get the version by looking at the numbers behind the so suffix"? Or is it more some kind of bug that the maintainers of the opencv package forgot to add this symlink? Because e.g. libcv or libhighgui have such symbolic links.
Thank you!
From the ldconfig manpage:
ldconfig checks the header and file
names of the libraries it encounters
when determining which versions should
have their links updated.
Maybe an earlier ldconfig run deleted the link.