I am trying to use opencv in a project, and am running into problems 'installing' it. I have extracted the opencv files and have created a small test program:
#include "opencv2/highgui/highgui.hpp"
#include <iostream>
int main(int argc, char **argv){
cv::Mat im=cv::imread((argc==2)? argv[1]: "testing.jpg",1);
if (im.empty()){
std::cout << "Cannot open image." << std::endl;
} else {
cv::imshow("image",im);
cv::waitKey(0);
}
return 0;
}
To compile the program I have used the command below:
g++ -I"../../PortableGit/opt/opencv/build/include/" -L"../../PortableGit/opt/opencv/build/x64/vc15/lib" main.cpp -lopencv_core -lopencv_highgui -o main
I get the errors below:
In file included from ../../PortableGit/opt/opencv/build/include/opencv2/core.hpp:3293:0,
from ../../PortableGit/opt/opencv/build/include/opencv2/highgui.hpp:46,
from ../../PortableGit/opt/opencv/build/include/opencv2/highgui/highgui.hpp:48,
from main.cpp:1:
../../PortableGit/opt/opencv/build/include/opencv2/core/utility.hpp:714:14: error: 'recursive_mutex' in namespace 'std' does not name
a type
typedef std::recursive_mutex Mutex;
^~~~~~~~~~~~~~~
../../PortableGit/opt/opencv/build/include/opencv2/core/utility.hpp:715:25: error: 'Mutex' is not a member of 'cv'
typedef std::lock_guard<cv::Mutex> AutoLock;
^~
../../PortableGit/opt/opencv/build/include/opencv2/core/utility.hpp:715:25: error: 'Mutex' is not a member of 'cv'
../../PortableGit/opt/opencv/build/include/opencv2/core/utility.hpp:715:34: error: template argument 1 is invalid
typedef std::lock_guard<cv::Mutex> AutoLock;
I believe that it has something to do with mingw binaries no longer being included with opencv. I am missing the opencv/build/x86/mingw directory.
My questions are:
How do I 'install' opencv and use it without also installing some sort of IDE and/or CMake? (I prefer to use vim and the command line.)
Once installed, what command do I use to compile and link a program with opencv?
Any help is appreciated.
Edit:
This appears to be a problem with GCC's implementation of threads on windows. Using mingw-w64 instead of mingw fixed the std::recursive_mutex issue, but now the linker cannot find the proper files.
/i686-w64-mingw32/bin/ld.exe: cannot find -lopencv_core
/i686-w64-mingw32/bin/ld.exe: cannot find -lopencv_highgui
After quite a bit of trying things out, this is what I got to work. Oddly, following the LINUX guide to install opencv worked better than the WINDOWS guide, even though I have a windows computer.
Guide to Installing OpenCV on Windows Without VS
Heads-up: This is a multi-step process, 3 separate tools are required. Be prepared for this to take a while.
Part 1: Get everything ready
Download MinGW-w64.
On the downloads page, click on the "MinGW-w64-builds" option. Do not click on the "win-builds" option.
The reason MinGW-w64 has to be used is because it is a newer version of the MinGW compiler suit that has been improved for windows. This means that it supports the posix thread system, where as the standard MinGW compiler only supports the win32 thread system. OpenCV relies on the posix thread system, necessitating the MinGW-w64 compiler.
Extract the MinGW-w64 zip folder to a directory. In my case its PortableGit/opt/MinGW-w64
At this point, you can add the MingGW-w64/mingw32/bin folder to your path. (Assuming that this won't cause any conflicts.) If you do so, you will not have to constantly specify the g++ executable directory to run it. This is up to your discretion.
Download an opencv release.
Do not download the package for windows, click the button that says "sources"
Extract the opencv sources zip folder to a directory. In my case its PortableGit/opt/opencv-4.3.0
Also download the opencv_contrib source files directly from the repository.
Extract that folder and place it inside the top level opencv folder: PortableGit/opt/opencv-4.3.0/opencv_contrib in my case.
Download CMake.
I downloaded the zip folder, but you can download the installer if you wish.
Extract the CMake zip folder if you downloaded that, or run the installer. I put my CMake folder here: PortableGit/opt/cmake-3.17.1-win32-x86
At this point, you can add the cmake-3.17.1-win32-x86/bin folder to your path. (Assuming that this won't cause any conflicts.) If you do so, you will not have to constantly specify the cmake executable directory to run it. This is up to your discretion.
Part 2: Build OpenCV
Navigate to the opencv directory and create a build folder and cd into it.
mkdir build && cd build
Run the following export commands.
export CC=/PortableGit/MinGW-w64/mingw32/bin/gcc.exe
export CXX=/PortableGit/MinGW-w64/mingw32/bin/g++.exe
This is to make sure the next cmake command uses the proper compilers.
Run the following cmake command from within that folder:
PortableGit/opt/cmake-3.17.1-win32-x86/cmake.exe -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release -DOPENCV_VS_VERSIONINFO_SKIP=1 -DOPENCV_EXTRA_MODULES_PATH="/PortableGit/opt/opencv-4.3.0/opencv_contrib/modules/" ..
The -G flag specifies that we are creating build files for the MinGW compiler
The -DCMAKE_BUILD_TYPE=Release specifies that we are building the release version of opencv and not the debug version.
The DOPENCV_EXTRA_MODULES_PATH needs to be set to the modules folder inside the opencv_contrib folder. For me it was PortableGit/opt/opencv-4.3.0/opencv_contrib/modules
The DOPENCV_VS_VERSIONINFO_SKIP specifies to not include version info. If not set, the compiler will throw an error complaining about not having version files. (Shown below for reference.)
gcc: error: long: No such file or directory
mingw32-make[2]: *** [modules\core\CMakeFiles\opencv_core.dir\build.make:1341:
modules/core/CMakeFiles/opencv_core.dir/vs_version.rc.obj] Error 1
If successful, the cmake command will finish like this:
Now run this command, again from the build folder: /PortableGit/opt/MinGW-w64/mingw32/bin/mingw32-make.exe -j7
mingw32-make.exe is the windows equivalent of the Linux make command.
The -j7 option run the process with a maximum of 7 threads.
This will take a while! It took my laptop ~20 minutes to complete
If the make command ends in an error, make sure to reset your build directory before continuing any troubleshooting. This is done through this series of commands
rm -rf build
mkdir build
cd build
Part 3: Using OpenCV
To use the opencv library that you just compiled in a project of your own, compile the project with these flags from your projects main directory.
Remember that your compiler now has to be set to the mingw-w64 compiler for opencv support.
I added indentation and newlines for readability, but when entering this in the terminal do not include the newlines or indents.
The number at the end of the linker options may change depending on the version of opencv you downloaded. I downloaded opencv-4.3.0, making my number 430, but yours may be different.
PortableGit/opt/MinGW-w64/bin/g++.exe
-I../../PortableGit/opt/opencv-4.3.0/include/
-I../../PortableGit/opt/opencv-4.3.0/build/
-I../../PortableGit/opt/opencv-4.3.0/modules/core/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/calib3d/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/dnn/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/features2d/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/flann/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/gapi/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/highgui/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/imgcodecs/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/imgproc/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/ml/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/objdetect/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/photo/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/stitching/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/ts/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/video/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/videoio/include/
-I../../PortableGit/opt/opencv-4.3.0/modules/world/include/
-L../../PortableGit/opt/opencv-4.3.0/build/lib/
*.hpp
*.cpp
-lopencv_calib3d430
-lopencv_core430
-lopencv_dnn430
-lopencv_features2d430
-lopencv_flann430
-lopencv_highgui430
-lopencv_imgcodecs430
-lopencv_imgproc430
-lopencv_ml430
-lopencv_objdetect430
-lopencv_photo430
-lopencv_stitching430
-lopencv_video430
-lopencv_videoio430
-o
main
Or you could download VS. Up to you. Hope this helps.
Correction for JackCamichael's answer
those 2 commands won't work in Windows
export CC=/PortableGit/MinGW-w64/mingw32/bin/gcc.exe
export CXX=/PortableGit/MinGW-w64/mingw32/bin/g++.exe
This should be
setx -m CC C:\msys64\mingw64\bin\gcc.exe
setx -m CXX C:\msys64\mingw64\bin\g++.exe
C:\msys64\mingw64\bin is mingw64 path on my machine
I'm trying to use libfluid to code my own OpenFlow controller. But first I want to build the sample controller to understand how that works.
I got the following error when compiling the sample controller:(this is the error I got when I try make msg_controller)
c++ msg/MsgController.cc -lfluid_msg -lfluid_base -I. -O3 -std=c++0x -o msg_controller
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libfluid_base.so: undefined reference to `event_base_del_virtual'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/libfluid_base.so: undefined reference to `event_base_add_virtual'
collect2: error: ld returned 1 exit status
Makefile:10: recipe for target 'msg_controller' failed
make: *** [msg_controller] Error 1
Before building sample controller, I follow the steps to build libfluid_base and libfluid_msg. When building these two library I got the following prompt which I think might be helpful to solve my problem
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
during execution
add LIBDIR to the 'LD_RUN_PATH' environment variable
during linking
use the '-Wl,-rpath -Wl,LIBDIR' linker flag
have your system administrator add LIBDIR to '/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
Is the undefined reference error because the library not linking correctly?
Do I need to make some change to the c++ command?
I tried the command grep -rn "event_base_del" /usr/lib and also grep -rn "event_base_add" /usr/lib
The output for event_base_del is below (the same for event_base_add)
Binary file /usr/lib/libfluid_base.a matches
Binary file /usr/lib/libfluid_base.so.0.0.0 matches
Binary file /usr/lib/x86_64-linux-gnu/libevent.a matches
Binary file /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6.0.2 matches
Binary file /usr/lib/x86_64-linux-gnu/libevent_core.a matches
Binary file /usr/lib/x86_64-linux-gnu/libevent_core-2.1.so.6.0.2 matches
Is this means it is linking correctly? since libfluid_base.so is just a link to libfluid_base.so.0.0.0
lrwxrwxrwx 1 root root 22 Oct 8 09:36 libfluid_base.so -> libfluid_base.so.0.0.0
So how can I fix this?
After I tried using -levent_core or -levnet to have the example code link against libevent. The error continue exist, it's probably because the version of libevent I'm using right now is not compatible with the current version of libfluid.By the way I'm using Ubuntu18.04.
I will try build it on ubuntu16.04 with older version of libevent see if it works.
event_base_del_virtual comes from libevent library. Link it with -levent_core.
I'm having some trouble building the csv library libcsv.
I'm using Windows XP, MinGW compiler and MSYS command shell.
It configures ok (./configure) but when I go to build it I get the below error. I realise it has to do with autoconf (it requires 2.65 or above) So what do I do here. Do I download autoconf and have it in a separate directory marked c:\autoconf and have an environmental variable pointing to it? Or,, does it go in the MSYS folder.
I have downloaded the binaries for autoconf and I just get a bunch of files. The binary files are in a SHARE folder and a 'bin' folder. Do I put their contents into the MsYS share and bin folders? Looking around the web I'm also seeing references to putting the autoconf binaries into my MinGW/bin folder. I'm really not sure what to do here?
Can anyone help? Thank you.
xxxx#XXXX-2FEF09FD39 ~
$ cd C:\libcsv-3.0.3
xxxx#XXXX-2FEF09FD39 /c/libcsv-3.0.3
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /c/libcsv-3.0.3/missing --run autoconf
/bin/m4: unrecognized option `--gnu'
Try `/bin/m4 --help' for more information.
autom4te: /bin/m4 failed with exit status: 1
make: *** [configure] Error 1
xxxx#XXXX-2FEF09FD39 /c/libcsv-3.0.3
$
I'm trying to compile my program and it returns this error :
usr/bin/ld: cannot find -l<nameOfTheLibrary>
in my makefile I use the command g++ and link to my library which is a symbolic link to my library located on an other directory.
Is there an option to add to make it work please?
To figure out what the linker is looking for, run it in verbose mode.
For example, I encountered this issue while trying to compile MySQL with ZLIB support. I was receiving an error like this during compilation:
/usr/bin/ld: cannot find -lzlib
I did some Googl'ing and kept coming across different issues of the same kind where people would say to make sure the .so file actually exists and if it doesn't, then create a symlink to the versioned file, for example, zlib.so.1.2.8. But, when I checked, zlib.so DID exist. So, I thought, surely that couldn't be the problem.
I came across another post on the Internets that suggested to run make with LD_DEBUG=all:
LD_DEBUG=all make
Although I got a TON of debugging output, it wasn't actually helpful. It added more confusion than anything else. So, I was about to give up.
Then, I had an epiphany. I thought to actually check the help text for the ld command:
ld --help
From that, I figured out how to run ld in verbose mode (imagine that):
ld -lzlib --verbose
This is the output I got:
==================================================
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.a failed
attempt to open /usr/local/lib64/libzlib.so failed
attempt to open /usr/local/lib64/libzlib.a failed
attempt to open /lib64/libzlib.so failed
attempt to open /lib64/libzlib.a failed
attempt to open /usr/lib64/libzlib.so failed
attempt to open /usr/lib64/libzlib.a failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.a failed
attempt to open /usr/local/lib/libzlib.so failed
attempt to open /usr/local/lib/libzlib.a failed
attempt to open /lib/libzlib.so failed
attempt to open /lib/libzlib.a failed
attempt to open /usr/lib/libzlib.so failed
attempt to open /usr/lib/libzlib.a failed
/usr/bin/ld.bfd.real: cannot find -lzlib
Ding, ding, ding...
So, to finally fix it so I could compile MySQL with my own version of ZLIB (rather than the bundled version):
sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so
Voila!
If your library name is say libxyz.so and it is located on path say:
/home/user/myDir
then to link it to your program:
g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog
There does not seem to be any answer which addresses the very common beginner problem of failing to install the required library in the first place.
On Debianish platforms, if libfoo is missing, you can frequently install it with something like
apt-get install libfoo-dev
The -dev version of the package is required for development work, even trivial development work such as compiling source code to link to the library.
The package name will sometimes require some decorations (libfoo0-dev? foo-dev without the lib prefix? etc), or you can simply use your distro's package search to find out precisely which packages provide a particular file.
(If there is more than one, you will need to find out what their differences are. Picking the coolest or the most popular is a common shortcut, but not an acceptable procedure for any serious development work.)
For other architectures (most notably RPM) similar procedures apply, though the details will be different.
Compile Time
When g++ says cannot find -l<nameOfTheLibrary>, it means that g++ looked for the file lib{nameOfTheLibrary}.so, but it couldn't find it in the shared library search path, which by default points to /usr/lib and /usr/local/lib and somewhere else maybe.
To resolve this problem, you should either provide the library file (lib{nameOfTheLibrary}.so) in those search paths or use -L command option. -L{path} tells the g++ (actually ld) to find library files in path {path} in addition to default paths.
Example: Assuming you have a library at /home/taylor/libswift.so, and you want to link your app to this library. In this case you should supply the g++ with the following options:
g++ main.cpp -o main -L/home/taylor -lswift
Note 1: -l option gets the library name without lib and .so at its beginning and end.
Note 2: In some cases, the library file name is followed by its version, for instance libswift.so.1.2. In these cases, g++ also cannot find the library file. A simple workaround to fix this is creating a symbolic link to libswift.so.1.2 called libswift.so.
Runtime
When you link your app to a shared library, it's required that library stays available whenever you run the app. In runtime your app (actually dynamic linker) looks for its libraries in LD_LIBRARY_PATH. It's an environment variable which stores a list of paths.
Example: In case of our libswift.so example, dynamic linker cannot find libswift.so in LD_LIBRARY_PATH (which points to default search paths). To fix the problem you should append that variable with the path libswift.so is in.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor
During compilation with g++ via make define LIBRARY_PATH if it may not be appropriate to change the Makefile with the -Loption. I had put my extra library in /opt/lib so I did:
$ export LIBRARY_PATH=/opt/lib/
and then ran make for successful compilation and linking.
To run the program with a shared library define:
$ export LD_LIBRARY_PATH=/opt/lib/
before executing the program.
First, you need to know the naming rule of lxxx:
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lltdl
/usr/bin/ld: cannot find -lXtst
lc means libc.so, lltdl means libltdl.so, lXtst means libXts.so.
So, it is lib + lib-name + .so
Once we know the name, we can use locate to find the path of this lxxx.so file.
$ locate libiconv.so
/home/user/anaconda3/lib/libiconv.so # <-- right here
/home/user/anaconda3/lib/libiconv.so.2
/home/user/anaconda3/lib/libiconv.so.2.5.1
/home/user/anaconda3/lib/preloadable_libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2.5.1
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/preloadable_libiconv.so
If you cannot find it, you need to install it by yum (I use CentOS). Usually you have this file, but it does not link to right place.
Link it to the right place, usually it is /lib64 or /usr/lib64
$ sudo ln -s /home/user/anaconda3/lib/libiconv.so /usr/lib64/
Done!
ref: https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html
When you compile your program you must supply the path to the library; in g++ use the -L option:
g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar
I had this problem with compiling LXC on a fresh VM with Centos 7.8. I tried all the above and failed. Some suggested removing the -static flag from the compiler configuration but I didn't want to change anything.
The only thing that helped was to install glibc-static and retry. Hope that helps someone.
Check the location of your library, for example lxxx.so:
locate lxxx.so
If it is not in the /usr/lib folder, type this:
sudo cp yourpath/lxxx.so /usr/lib
Done.
Apart from the answers already given, it may also be the case that the *.so file exists but is not named properly. Or it may be the case that *.so file exists but it is owned by another user / root.
Issue 1: Improper name
If you are linking the file as -l<nameOfLibrary>
then library file name MUST be of the form lib<nameOfLibrary>
If you only have <nameOfLibrary>.so file, rename it!
Issue 2: Wrong owner
To verify that this is not the problem - do
ls -l /path/to/.so/file
If the file is owned by root or another user, you need to do
sudo chown yourUserName:yourUserName /path/to/.so/file
Here is Ubuntu information of my laptop.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
I use locate to find the .so files for boost_filesystem and boost_system
locate libboost_filesystem
locate libboost_system
Then link .so files to /usr/lib and rename to .so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 /usr/lib/libboost_filesystem.so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 /usr/lib/libboost_system.so
Done! R package velocyto.R was successfully installed!
This error may also be brought about if the symbolic link is to a dynamic library, .so, but for legacy reasons -static appears among the link flags. If so, try removing it.
The library I was trying to link to turned out to have a non-standard name (i.e. wasn't prefixed with 'lib'), so they recommended using a command like this to compile it -
gcc test.c -Iinclude lib/cspice.a -lm
I encountered the same error message.
I built the cmocka as a so and tried to link it to my executable.
But ld always complains below:
/usr/bin/ld: cannot find -lcmocka
It turns out that there are 3 files generated after cmocka is built:
libcmocka.so
libcmocka.so.0
libcmocka.so.0.7.0
1 and 2 are symbol links and only 3 is the real file.
I only copied the 1 to my library folder, where ld failed to find the 3.
After I copied all 3, ld works.
I want to use FADE on my computer. So, I have to use the libaws++, which is a C++ library that allows to communicate with Amazon Web Services.
OK, Here is my problem:
The website of libaws++ is unavailable. I used Google to search "libaws++" and only found libaws. I didn't know whether libaws is libaws++. They both used to communicate with Amazon Web Services. So I download libaws from sourceforge.
Here is the process I install libaws:
tar libaws-0.9.2.tar.gz
cd libaws-0.9.2
cp ~/libaws_patch_for_fade.patch libaws_patch_for_fade.patch (cp the patch to libaws-0.9.2)
patch -p2 -i libaws_patch_for_fade.patch
mkdir libawsbuild
cd libawsbuild
cmake ..
make
And error occors:
[ 28%] Building CXX object src/CMakeFiles/aws.dir/api/connectionpool.cpp.o
In file included from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/aws.h: 26:0,
from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/connec tionpool.h:22,
from /home/lx/Nutstore/cloud/libaws-0.9.2/src/api/connectionpoo l.cpp:16:
/home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/sqsresponse.h:124:9: error: a€?uint64_ta€? does not name a type
In file included from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/aws.h: 29:0,
from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/connec tionpool.h:22,
from /home/lx/Nutstore/cloud/libaws-0.9.2/src/api/connectionpoo
/home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/sqsresponse.h:124:9: error: a€?uint64_ta€? does not name a type
In file included from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/aws.h: 29:0,
from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/connec tionpool.h:22,
from /home/lx/Nutstore/cloud/libaws-0.9.2/src/api/connectionpoo l.cpp:16:
/home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/sdbresponse.h:105:20: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
.....
make[2]: *** [src/CMakeFiles/aws.dir/api/connectionpool.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/aws.dir/all] Error 2
make: *** [all] Error 2
I searched on Google and stackoverflow and didn't get any useful information.
Add #include <stdint.h> to the top of those header files.
uint64_t is a standard type and should work just fine.
(Unless of course you are on some weird platform that doesn't support 64-bit integers...)
Just got this compiled with the gnu compiler 4.9.x. With newer versions of the compiler, there are more steps needed to compile libaws.
Here's what I had to do:
1) Add the following line to the header files in libaws-0.9.2/include/libaws/*.h, after all of the other include statements:
#include <stdint.h>
2) Add the following line to libaws-0.9.2/include/libaws/aws.h, after all of the other include statements:
#include <getopt.h>
3) If you're using a recent version of the Gnu C++ compiler, you'll need to modify the CMAKE files to add some flags to the compiler, so that the older C++ syntax used in libaws doesn't throw compiler errors.
Add this line to CMakeCompiler.txt, after all of the other CMAKE_CXX_FLAGS commands, around line 82 (which should be a blank line):
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fpermissive -Wignored-qualifiers")
FYI: If you're using the Gnu C compiler, you may need a similar line for the C sections, at the end of the other CMAKE commands. Something like this at the end of the file might work, but I haven't tried it:
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fpermissive -Wignored-qualifiers")
Once those are done, here are the steps to compile:
cd libaws-0.9.2
mkdir libawsbuild
cd libawsbuild
cmake ..
make
When this is successful, you also may need to copy config.h from libawsbuild/include to libaws-0.9.2/include/libaws in order for the compiler to find config.h in the place it expects, when you compile whatever code you're writing to actually use libaws. (Although that may just have been the way my personal makefile was configured. Don't quote me on that.)