I'm trying to install a custom c++ library - Milia http://guaix.fis.ucm.es/projects/milia/wiki
When I run ./configure I get the error
configure: error: Package requirements (gsl) were not met:
No package 'gsl' found
I have GSL installed in the /usr/local directory and it works fine. Not exactly sure why it can't find gsl.
Any ideas?
Based on your comment, the solution of your problem is here (just follow the steps of the updated answer that is written inside the question and adapt the flags to the GSL flags).
PS: if you only want to make Milia work and not fix the fact the dpkg can't find your gsl installation, then you can just update GSL_CFLAGS and GSL_LIBS environment variables. If defined, Milia will use them instead of asking dpkg for the gsl path
Extract from configure file
GSL_CFLAGS C compiler flags for GSL, overriding pkg-config
GSL_LIBS linker flags for GSL, overriding pkg-config
After that, just relax and let Milia show you how dark energy impacts distances and ages in FRWL metric! :)
Related
I'm pretty new to C++ and I'm having a hard time trying to install external libraries. I want to get started with GUI programming and I have searched all over, but I cannot find a way to add wxWidgets to Code::Blocks. I've tried a few different guides and Stack Overflow responses but none of them have actually worked.
I'm using this 'Hello World!' test program to see if it works, every time I try to run it I just get this error: fatal error: wx/wxprec.h: No such file or directory. I can't seem to figure out how to tell Code::Blocks where the library is.
The most recent resource I have tried is this one, I followed it step by step, but still I got this error.
What linker/compiler settings do I need to use in Code::Blocks? What lib files do I need to add and where do I add them to? Do I need to build the .zip file? How do I do this?
Please could I get a step by step guide on exactly how to add wxWidgets (or indeed any external library) to Code::Blocks as well as some information on why certain things are required?
Here's what I tried
Following the steps in the link above, this is what I have in my build options:
I tried adding this in my global compiler settings...
I still have this error...
CodeBlocks seems to have some special wxWidgets integration, but it didn't always work for me, so I prefer to set up the project manually.
CB ships an outdated compiler. While it may work, updating it is a good idea.
Get rid of the MinGW version shipped with CB, or at least remove it from the PATH.
Install MSYS2. Use it to install a new GCC and GDB, as described in the link.
Configure CB to use MSYS2's GCC and GDB, by specifying the paths to them in the CB config (they're installed to C:\msys64\mingw64\bin).
wxWidgets seem to ship prebuilt libraries for MinGW, but since we're using MSYS2, we might as well use the version provided by MSYS2.
Use MSYS2 to install wxWidgets: pacman -S mingw-w64-x86_64-wxWidgets3.2-msw.
MSYS2 seems to ship several different versions of wxWidgets: 3.0, 3.1, 3.2, and each of them in two variants: -msw and -gtk. 3.2-msw looks like a reasonable choice to me, but I haven't used this library before.
wxWidgets doesn't seem to use the standard way of telling you what compiler flags to use (which would be pkg-config, or at least a CMake file). Instead they ship their own script to determine the flags, called wx-config.
Run wx-config --cflags to get the compiler flags, and run wx-config --libs to get the linker flags. Paste them into the project settings (compiler settings and linker settings respectively). Edit the project settings, not the global compiler settings.
Trying to compile some Fortran code using gfortran 9.x.x on my CentOS 7.xx machine. Have a particular version of the code that requires linking to LAPACK and BLAS (specifcially, liblapack.a, and librefblas.a). Have LAPACK (and all the -devel libs), and BLAS (same about -devel libs) installed (both available in the CentOS base repo).
While I (and therefore the linker) can find liblapack.a (its in /usr/lib64), no trace of librefblas.a (which causes the linker to complain bitterly, and the compilation to crash and burn).
In fact, I tried installing both BLAS and OpenBLAS on the same machine, but that didn't help -- librefblas.a still nowhere to be found.
The first thing to try is to use the regular libblas. Either change your Makefile to to use libblas instead of librefblas or make a symlink. Then check if you have any unresolved reference. Or do the same for OpenBLAS and point your makefile to libopenblas. Note that OpenBLAS also includes LAPACK.
Background: BLAS and LAPACK are publicly available interfaces. There is a reference implementation available, but also many alternative optimized or machine-specific ones. It should not matter which one you use so it seems unnecessary to specifically require the reference one. Normally, your Linux distribution libblas is the reference one anyway. It is probably just a quirk of your Makefile.
no trace of librefblas.a
The CentOS 7 lapack-3.4.2-8.el7 package build doesn't create or install the file librefblas.a .
I.e. no available package providing /usr/lib64/librefblas.a .
The package blas-static provides one file only : /usr/lib64/libblas.a
Build librefblas.a :
tar xvf lapack-3.4.2-clean.tgz
https://src.fedoraproject.org/repo/p....4.2-clean.tgz
cd lapack-3.4.2/
cp make.inc.example make.inc
make blaslib
... And librefblas.a will be created.
do this in the package folder:
sudo ln -s $HOME/lapack-3.9.0/librefblas.a /usr/local/lib/librefblas.a
solved
Every now and then I want to compile something from source with mingw (on windows). I open msys, type ./configure, and it says
checking for...xxxxxx
There I have the first questions:
Where does mingw check?
What does it check for? .dll, .a, .o.,... what ever?
Occassionally there is an error like
configure: error: Package requirements <ogg >= 1.3> were not met:
No package 'ogg' found.
Well then I google and find "you can output the default lookup directories" so okay, I type gcc -print-search-dirs and see a list of directories, for example C:/mingw/lib, C:/mingw/lib/gcc, ...
Those folders contain .a-files. And guess what, some of them also contain libogg.a. So why is it complaining? Perhaps the version number? No, I downloaded the newest source and compiled it, and put the .a file into the directories. Same error. It drives me crazy! Please give some advice what to do.
Traditionally and typically, when a ./configure script checks for a library that the
package you are configuring needs to link against, it checks at least for the presence and usability of the library itself and also
for the header file(s) of the library, without which the compiler cannot use the
library's API. (I say typically, because what any given ./configure check
actually does is programmed by the package maintainer. It has nothing to do with your compiler).
Checking for the presence and usability of libfoobar normally does not mean that the ./configure check searches the filesystem for libfoobar.dll, libfoobar.a, or whatever. It means that the ./configure check simply attempts to compile and link a specimen program against libfoobar using the commands that are appropriate for doing so, when libfoobar is installed.
Often too (and increasingly), a ./configure check for a library libfoobar invokes the
pkg-config tool to attempt to
retrieve the correct compiler and linker flags for use with libfoobar. For this attempt to succeed, a pkg-config meta-data
file associated with the library package, foobar.pc, must be found in a standard
place in the filesystem, e.g. /usr/lib/pkgconfig, /usr/share/pkgconfig
For the library, plus its headers, plus its pkg-config meta-data (if any)
all to be available for ./configure it is necessary to install the development package
of libfoobar, as opposed to the basic package. The development package
usually has the same name as the basic package with the addition of a -dev
or -devel component, e.g. libfoobar-dev
If a ./configure check fails with an error of the form:
No package 'foobar' found.
it means that the check attempted to retrieve pkg-config meta-data for
foobar and none was found. That will usually be because the development
package libfoobar-dev is not installed, even if libfoobar is.
I am trying to compile a modelling program in Cygwin using either a gfortran or g95 compiler. I have installed both compilers, but when I go to configure the program, it checks for the compilers and does not find then (error: Fortran compiler cannot create executables). I am new to Cygwin-- I suspect it is something with how/where I installed the compilers...Any ideas?
Thank you,
L.
For me, it's more helpful to have executable code to go through the process, so I'm going to put some in. This is addressing your concern,
I suspect it is something with how/where I installed the compilers...
because the installation from apt-cyg should be helpful in letting the system know where to look for the compilers. I'm also addressing a possible linkage issue.
bballdave025#MY-MACHINE /cygdrive/c/bballdave025
$ apt-cyg install gcc-fortran libgfortran5
If you don't have apt-cyg yet, follow these instructions from another answer.
# Get to where your setup executable lives.
# This is what you used to install Cygwin the first time.
# Note that mine is for the 64-bit version, and that
# I keep mine in C:\cygwin64. Your path might be
# different. You also might need to re-download
# The setup executable from Cygwin.
$ cd /path/to/setup_install/setup_x86-64.exe -q -P wget
$ wget https://raw.githubusercontent.com/transcode-open/apt-cyg/master/apt-cyg
$ chmod +x apt-cyg
$ mv apt-cyg /usr/local/bin
The libgfortran5 (or a more recent version, if available when you search) might be necessary. Here's why I think this might be the case.
bballdave025#MY-MACHINE /cygdrive/c/bballdave025
$ man gcc | grep -A 3 "[ ]*[-]l[ ]\{0,2\}library$"
-llibrary
-l library
Search the library named library when linking. (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.)
(Note that I haven't included some parts of the result that aren't useful and can be fixed by prefixing the command with MANWIDTH=160, cf here.)
There is a little more detail and a little different result from the answer to a question about the lib prefix on files:
You can name a library whatever you want, but if you want gcc's -l flag to find the right one, you need to name it the way that link describes. For example, gcc -o myapp myapp.c -lm, [w]ill compile myapp.c, link the resulting object with libm.a, and output an executable called myapp. These days, there might be a more complicated search path involving dynamic library names, etc., but you should get the basic idea from this example. [In addition, you can look at this section f]rom the gcc man page:
-l library ...
... surrounds library with lib and .a and searches several directories.
The basic reason for all of that info is this: it is very possible that, in order to link with the gfortran library, you need to have installed a package named something like libgfortran. I don't know for sure how this works, especially with the Cygwin man page being slightly different, but it's worth a try. The likely extra thing you would need in this case is something like
apt-cyg install libgfortran
or
apt-cyg install libgfortran5
Here's some helpful info on how I found what to install. When I had a similar problem, I went to the Cygwin package search, but I only got three entries with three versions of netcdf-fortran
(archived). I wanted gfortran, so I kept looking
I found a great gfortran answer in this SO answer. With that answer, I went back to the Complete Cygwin Package List, armed with my trusty Ctrl + F, since I knew there were packages different from what came back from the search. The complete list had
cygwin64-gcc-fortran GCC for Cygwin 64bit toolchain (Fortran)`
gcc-fortran GNU Compiler Collection (Fortran)
and entries for libgfortran.
Hopefully some of this information will be helpful, or at least educational.
This problem is common for beginners with autotools. It can be:
missing libraries; this can be missing libraries for your project or compiler/system libraries, like libgfortran or similar for g95.
autotools can not detect your compiler;
dynamic libraries problem; runtime path to the dynamic libraries not set. See LD_LIBRARY_PATH for linux environment.
cross-compiling problem, I do not know much about cygwin but that can be an issue. I am not expert of cross-compiling either. It can also be another situation that I am not aware of.
I ran into the 1st and 3rd situations.
Approaches of solutions.
make sure you can manually compile and run a simple hello world program. Install the missing libraries if necessary. Also make sure that you can link your hello world program against the same libraries used by your modelling program, this last statement could lead you to the 3rd situation.
add the path to your compiler to the PATH variable or similar variable in cygwin. Or explicitly give the full path to your compiler to configure.
add the path to your libraries to the runtime libraries path LD_LIBRARY_PATH for linux environment or similar variable in cygwin. In one of my cases, the problem was that the test program that autotools uses to test the compiler could not run. It was successfully compiled but could not run. I installed all the libraries that my project uses in a path that was not included in library path. What happened was that the path to those libraries were set in the configure.ac or makefile.am so that the compiling was OK. But the running of the test program included in configure could not find them. This is a problem mostly for dynamically linked libraries. Adding the path to my .so to the LD_LIBRARY_PATH solved the problem.
well, I can not really help. The only solution that I can suggest is to install a linux system (dual boot or virtual machine) if you know how to do it, because I will not be there to help.
The following link can also help.
I want to use openssl library in my NaCl module. Luckily it is ported already as in https://code.google.com/p/naclports/. However, its kind of pity but I don't know how to add the library to the toolchain. I did as instructed in the Readme file:
...nacl_sdk/pepper_33/naclports/src$ python build_tools/naclports.py install openssl
Already installed 'openssl' [x86_64/newlib]
And then I tried to compile this simple C code, and the compiler complaint some errors which are because of linking problem with openssl/evp.h.
This is my Makefile: link. Please let me know how to make it run.
NaCl actually consists of several different toolchains. naclports will build and install a given library to just one of them at time. The libraries and headers get installed directly into the toolchain so there is no need to -L or -I on the command line.
In this case you have built and installed the x86_64 newlib version of openssl. This means that you should be able to build the x86_64 newlib version of your app (add TOOLCHAIN=newlib NACL_ARCH=x86_64 to your make call).
To build all the other versions of openssh you can use the "make_all.sh" script at the top level of naclports (e.g. ./make_all.sh openssl).
Build naclports. Look in naclports/README.rst for instructions.