Trying to build gearman from the gearmand-0.33.tar.gz from Launchpad using bzr, on a Fedora 64 system.
doing the ./configure by tiself, as well as using the "-with-boost=/usr/include" param generates warnings an errors as the configure process can't seem to find/locate the boost header files.
we've removed/reinstalled the boost header files via "yum install boost*" as well
Any pointers will be tried!
Thanks
./configure
.
.
.
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
checking for Boost headers version >= 1.39.0... yes
checking for Boost's header version... 1_41
checking for the toolset name used by Boost for g++... gcc44 -gcc
checking boost/program_options.hpp usability... no
checking boost/program_options.hpp presence... yes
configure: WARNING: boost/program_options.hpp: present but cannot be compiled
configure: WARNING: boost/program_options.hpp: check for missing prerequisite headers?
configure: WARNING: boost/program_options.hpp: see the Autoconf documentation
configure: WARNING: boost/program_options.hpp: section "Present But Cannot Be Compiled"
configure: WARNING: boost/program_options.hpp: proceeding with the compiler's result
configure: WARNING: ## -------------------------------------------------- ##
configure: WARNING: ## Report this to https://bugs.launchpad.net/gearmand ##
configure: WARNING: ## -------------------------------------------------- ##
checking for boost/program_options.hpp... no
configure: error: cannot find boost/program_options.hpp
Just have dealt with this problem, installed gcc-c++ and that has resolved it
The correct option is probably --with-boost, you should check that with ./configure -h.
Also, check whether the directory /usr/include/boost exists, because that seems to be what it's looking for.
Furthermore, make sure you shouldn't be using --with-boost-include=/usr/include (and maybe also --with-boost-libs (or -lib)).
In my case, using --with-boost=/path/to/root worked, where /path/to/root contains include/boost.
In other words, --with-boost=/path/to/root/include or --with-boost=/path/to/root/include/boost are both wrong.
I also set --with-boost-libdir=/path/to/root/lib64
Related
I have managed to successfully launch the most recent RStudio AWS EC2 instance (louisaslett.com, RStudio-1.1383_R-3.4.2…ubuntu-16.04-LTS-64). R operates mostly as expected in this instance, and I can install and open a number of packages. However I get an error if I try to install either of the rgdal of gdalUtils packages.
Below is the console output when I attempt to install rgdal. The output for the gdalUtils install is too long to include here, but both include the text "error: upgrade GDAL to 1.11.4 or later" which I suspect is the problem, but have no idea how to correct.
Any thoughts or advice would be greatly appreciated.
Cheers
> install.packages("rgdal")
Installing package into ‘/home/rstudio/R/x86_64-pc-linux-gnu-library/3.4’
(as ‘lib’ is unspecified)
trying URL 'https://cran.rstudio.com/src/contrib/rgdal_1.3-3.tar.gz'
Content type 'application/x-gzip' length 1670656 bytes (1.6 MB)
==================================================
downloaded 1.6 MB
* installing *source* package ‘rgdal’ ...
** package ‘rgdal’ successfully unpacked and MD5 sums checked
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
configure: CC: gcc -std=gnu99
configure: CXX: g++
configure: rgdal: 1.3-3
checking for /usr/bin/svnversion... yes
configure: svn revision: 759
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... yes
configure: C++11 support available
checking for gdal-config... /usr/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 1.11.3
checking GDAL version >= 1.11.4... no
configure: error: upgrade GDAL to 1.11.4 or later
ERROR: configuration failed for package ‘rgdal’
* removing ‘/home/rstudio/R/x86_64-pc-linux-gnu-library/3.4/rgdal’
Warning in install.packages :
installation of package ‘rgdal’ had non-zero exit status
The downloaded source packages are in
‘/tmp/RtmpGUxbcA/downloaded_packages’
I have since run into the same issue running Rstudio on the google cloud. In both cases a solution was relatively simple - install a recent but older rgdal package from cran (https://cran.r-project.org/src/contrib/Archive/rgdal/) which wasnt dependent on the most recent gdal libraries, and therefore installed without throwing the error about upgrading GDAL.
I need a subset of heasoft libraries for my data reduction pipeline, which I want to release as a conda package.
I have recipes which work fine under Linux, but I have problems in OSX when I build the heasoft package.
I do this:
download the needed libraries from the proper source as a tar file in recipe directory;
set path keyword in meta.yaml with the recipe directory;
in build.sh, I cd into the proper directory, which is BUILD_DIR as for any heasoft package.
Now, after exporting all the needed variables (CC and others), I do launch ./configure, and start seeing behaviours I can't deal with.
These are the first lines for the configure:
francesco:heasoft-osx(master)*$ conda build .
Attempting to finalize metadata for heasoft
INFO:conda_build.metadata:Attempting to finalize metadata for heasoft
BUILD START: ['heasoft-6.24-h9b869f0_1.tar.bz2']
Copying /Users/francesco/ascisoft-recipes/heasoft-osx to /Users/francesco/anaconda3/conda-bld/heasoft_1525868116683/work
source tree in: /Users/francesco/anaconda3/conda-bld/heasoft_1525868116683/work
/Users/francesco/anaconda3/conda-bld/heasoft_1525868116683/work/heasoft-6.24/BUILD_DIR
configure: WARNING: /usr/bin/perl and /usr/local/Cellar/llvm/5.0.0/bin/clang may not work well together!
rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
configure: WARNING: no header file found for arc4random
configure: WARNING: Cannot find idn library
configure: WARNING: Compilation of Fortran wrappers and PGSBOX disabled
configure: WARNING: CFITSIO disabled
configure: WARNING: PGPLOT disabled
configure: WARNING: Compilation of WCS utilities disabled
If, instead, with the downloaded tar file, I make the usual steps for compiling, I get fair outputs
francesco:BUILD_DIR$ ./configure --with-components="heacore heatools"
checking build system type... x86_64-apple-darwin17.5.0
checking host system type... x86_64-apple-darwin17.5.0
checking target system type... x86_64-apple-darwin17.5.0
Will force readline build on Darwin if available
Found component heacore
Found heacore/BUILD_DIR/hd_config_info
Found component heatools
...
checking build system type... x86_64-apple-darwin17.5.0
checking host system type... x86_64-apple-darwin17.5.0
checking target system type... x86_64-apple-darwin17.5.0
checking for strip... strip
checking for ar... ar
checking for ranlib... ranlib
checking for gmake... no
checking for make... make
checking whether make is GNU make... yes
and so on.
I would stop here, but the building process goes on and I have even more annoying behaviour, such as
ignoring file /[...]/x86_64-apple-darwin17.5.0/lib/libape_2.9.dylib, file was built for x86_64 which is not the architecture being linked (i386)
Is it something related to my system settings coupling with conda-build?
If needed, I can provide my recipe of course.
When running the configure script for Octave, I do:
./configure CFLAGS="-I/customlibs/pcre/gnu/8.40/include -L/customlibs/pcre/gnu/8.40/lib/" LD_LIBRARY_PATH="/customlibs/pcre/gnu/8.40/lib"
I have also tried:
./configure CFLAGS="-I/customlibs/pcre/gnu/8.40/include" LDFLAGS="-L/customlibs/pcre/gnu/8.40/lib/" LD_LIBRARY_PATH="/customlibs/pcre/gnu/8.40/lib"
Both of these produce the same failure:
checking pcre.h usability... yes
checking pcre.h presence... no
configure: WARNING: pcre.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: pcre.h: proceeding with the compiler's result
checking for pcre.h... yes
checking pcre/pcre.h usability... no
checking pcre/pcre.h presence... no
checking for pcre/pcre.h... no
checking whether pcre.h defines the macros we need... no
configure: error: to build Octave, you must have the PCRE library and header files installed
I'm lost as to how it can find pcre.h but fails to do anything else with it. Am I doing something wrong on my configure line or is pcre broken? If it's my configure line, how do I link against pcre correctly?
For reference, here's the pcre path:
ls /customlibs/pcre/gnu/8.40/
bin
include
lib
share
I was struggling with that for a while as well, but the solution was actually very simple. just use CPPFLAGS rather than CFLAGS for include files:
./configure CPPFLAGS="-I/customlibs/pcre/gnu/8.40/include" LDFLAGS="-L/customlibs/pcre/gnu/8.40/lib/"
There's also no need for LD_LIBRARY_PATH upon configuring.
I am trying to run a haskell file from command prompt. I get the following error :
Failed to load interface for `System.Console.Readline'
Perhaps you meant System.Console.Haskeline (from haskeline-0.7.2.3)
Locations searched:
System\Console\Readline.hs
System\Console\Readline.lhs
System\Console\Readline.hsig
System\Console\Readline.lhsig
I thought readline came as part of cabal when you installed the full version of haskell? (which I have done) Does anyone have any idea how I can fix this?
EDIT: I tried >cabal update, followed by >cabal install readline, and I now get this:
Resolving dependencies...
Configuring readline-1.0.3.0...
Failed to install readline-1.0.3.0
Build log ( C:\Users\Dan\AppData\Roaming\cabal\logs\readline-1.0.3.0.log ):
Configuring readline-1.0.3.0...
bash.exe: warning: could not find /tmp, please create!
checking for gcc... C:\PROGRA~1\HASKEL~1\802E01~1.1\mingw\bin\gcc.exe
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether C:\PROGRA~1\HASKEL~1\802E01~1.1\mingw\bin\gcc.exe accepts -g... yes
checking for C:\PROGRA~1\HASKEL~1\802E01~1.1\mingw\bin\gcc.exe option to accept ISO C89... none needed
checking for GNUreadline.framework... checking for readline... no
checking for tputs in -lncurses... no
checking for tputs in -ltermcap... no
checking for tputs in -lcurses... no
checking for rl_readline_version... no
configure: error: readline not found, so this package cannot be built
See `config.log' for more details.
cabal: Leaving directory 'C:\Users\Dan\AppData\Local\Temp\cabal-tmp-884\readline-1.0.3.0'
cabal: Error: some packages failed to install:
readline-1.0.3.0 failed during the configure step. The exception was:
ExitFailure 1
I got the libpuzzle source here: http://www.pureftpd.org/project/libpuzzle/download.
I read I need MinGW to compile any C programs on windows, so I got that alot with C, C++ and mins options. Using mins I was followed: http://wiki.openttd.org/Compiling_on_MinGW
I downloaded the .tar.gz and unpacked it, executed the ./configure command and got:
libgd2 development files are not found
Makes sense given in the readme:
In order to load images, the library relies on the GD2 library.
You need to install gdlib2 and its development headers before compiling
libpuzzle.
The GD2 library is available as a pre-built package for most operating systems.
Debian and Ubuntu users should install the "libgd2-dev" or the "libgd2-xpm-dev"
package.
Gentoo users should install "media-libs/gd".
OpenBSD, NetBSD and DragonflyBSD users should install the "gd" package.
MacPorts users should install the "gd2" package.
X11 support is not required for the Puzzle library.
Once GD2 has been installed, configure the Puzzle library as usual:
My problem at this time is finding a libgd2-dev or like file to compile. I found this: http://mldonkey.sourceforge.net/Windows and downloaded http://www.boutell.com/gd/http/gd-2.0.33.tar.gz and it installed fine. Running gdlib-config outputs typical man. However, libpuzzle still says I need the "libgd2 development files", so I assume the gd I downloaded was "libgd" but just "gd" or the file I had didn't have development files. Where can I found what I need?
Here is mingw output:
Brian#2500K ~/libpuzzle-0.11
$ gdlib-config
Print information on GD library's version, configuration, and use.
Usage: gdlib-config [options]
Options:
--libdir # directory where GD library is installed
--includedir # directory where GD library headers are installed
--version # complete GD library version string
--majorversion # GD library major version number
--minorversion # GD library minor version number
--revision # GD library revision version number
--ldflags # options required for linking against GD library
--libs # libs required for linking against GD library
--cflags # options required for compiling GD library apps
--includes # same as --cflags
--features # lists optional features compiled into gd, separated
# by spaces. Currently (as of 2.0.26) the optional
# features are GD_PNG, GD_JPEG, GD_XPM, and
# GD_FREETYPE. When these features are reported by
# --features, it is safe to include calls to the
# related functions in your code.
--all # print a summary of all GD library configure options
Brian#2500K ~/libpuzzle-0.11
$ gdlib-config --includedir
/usr/local/include
Brian#2500K ~/libpuzzle-0.11
$ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether ln -s works... no, using cp -p
checking whether make sets $(MAKE)... (cached) yes
checking for gdlib-config... /usr/local/bin/gdlib-config
checking for gdImageCreateFromGd2 in -lgd... no
configure: error: libgd2 development files not found
Edit: Started a bounty. I am looking for either compile the libpuzzle for me so it works on WAMP (skipping the complicated middle stuff). Or help on getting each requirement needed so that I can compile it. My end goal is having libpuzzle run on wamp
Edit 2: Just an update, it seems libgd2 has problems with mingw. Even if I was to get libgd2 to finally work then I still need phpize for mingw as well, which also doesn't work for mingw. It seems it's not possible to use libpuzzle for windows
It sounds like the program is just not finding the headers for libgd. If you look at that tarbar, it's a source tarball that includes the headers. When you compiled and installed it, it installed the library and the headers somewhere. You need to figure out where.
Run ./configure --help
There should be an option like --with-gd=, that option lets you tell it the path where libgd is installed. Specify the path where it is installed, and it should work.
Encountered the same error when compiled GD2 myself.
Using old precompiled version from GnuWin32 solved the problem:
http://sourceforge.net/projects/gnuwin32/files/gd/2.0.33-1/