undefined reference errors after running cmake - c++

I've tried to essentially build the PhysFS library with Cmake, what I used was Code::Blocks mingw makefiles. I can import in my project, I can technically declare the PhysFS_init() function (although that gives me too few arguments error) yet when I add an argument it tells me PHYSFS_init is an undefined reference.
That sounds so silly to me, how can you recognize it when it has no argument, but pretend it doesn't exist when I add an argument? I've run CMake twice, but I'm simply getting this:
[...]\src\main.cpp|20|undefined reference to `PHYSFS_init'|
The code, if necessary (just a bit, the rest is irrelevant):
#include <SFML/Window.hpp>
#include <SFML/System.hpp>
#include <iostream>
#include "Globals.h"
#include "GameStates.h"
#include "GameWindow.h"
#include "GameMenu.h"
#include <physfs.h>
int main(int argc, char** argv)
{
///<|===================| Classes & Declarations |===================|>
sf::Event ev;
sf::RenderWindow winMain ( sf::VideoMode( WindowWidth, WindowHeight, 32 ), WindowTitle );
sf::Image Icon;
GameStates gameState;
GameMenu TitleMenu;
MenuButton buttons[4];
PHYSFS_init(NULL);
Why is this happening? What do I have to do to be able to use PhysFS in my project? I've built the library with CMake, I included the library I need, and I tried to initialize PhysFS which gave me an error which makes me feel like the way C++ compiles program is plain silly.

This is a general explanation of how C++ libraries work:
PHYSFS probably consists of header files and a static/dynamic library. The header file is where all the functions/classes of the library are declared, but not defined. Thus, when you include the header file into your project, your compiler can now know that the functions you call in the library exist, and exactly what type of parameters they take etc.
So to use a library, you must include its header files, which means you must add its include directory to the project/cmakelists.txt.
#some similar path to this
include_directories( /path/to/PHYSFS/include)
Now, when you actually link the executable into a binary, these functions must be "resolved" so that the linker knows where they actually are, so that they can be called. This is called "linking" with the library.
So to use a library you must link its library files.
In cmake this is done as follows:
add_executable(myexe myexe.cpp)
#Add library directory paths here
link_directories( /path/to/PHYSFSlibs/)
#libPHYS.a or libPHYS.so if using gcc convention, libPHYS.lib if MSVC convention
#cmake allows us to use the name of the library, instead of the filename to be portable.
target_link_libraries(myexe PHYSFS)
I am not particularly familiar with PHYSFS, but if you compiled it as a library, you should have one of these files to link to.
undefined reference to `PHYSFS_init
This is a problem with "linking" and usually means you failed to link the library, or the library is missing the implementation of this function. Linking the library should fix this.
EDIT
I misread your question, and assumed you were using cmake with your project and linking to PHYSFS.
First you must separately build PHYSFS, which will produce a library file (.a,.so or .lib) depending on the platform/IDE, then you must link that library file in your C::B linker options.
To do this:
Go to Project->Build options. Click Linker Settings.
Image (from here):
Add the library.

Related

How to handle library's function files (not header files) in autotools?

So recently I've been trying out autotools to build a C++ Library. Originally I was just working on pure custom classes, which is quite easy to just #include and then compile with g++. But when I want to write some custom functions for the library, I've learnt that it's a bad practice to write functions within header file, but rather I should declare it in header then wrote it in a separate .cpp file. Which later I've tried and successfully compiled with g++ ./lib/**/*.cpp src/main.cpp.
So basically my project structure is that codes are put under src/, headers are under include/ and functions are put under lib/. And following is my src/Makefile.am
AUTOMAKE_OPTIONS = subdir-objects foreign
bin_PROGRAMS = main
include_HEADERS = -I../include/**/*.hpp
main_SOURCES = -I../lib/**/*.cpp main.cpp
And for the endpoints' directory (under lib/) I have something like following
main_SOURCES = stdout.cpp
But it gave me error that no program named main, so I figured maybe all those function files has to be compiled first, so I changed them into
noinst_PROGRAMS = stdout
stdout_SOURCES = stdout.cpp
But then they gave me the following error
/usr/sbin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status
I know that the error meant that there's no main() written in the file, but since it's a library function file, it doesn't meant to have a main(), it's meant to be called by other file (like main.cpp). And to here I'm stuck.
I've tried to find documentation online, but it seems that most of them are targeted at C programs instead of C++, which I'm not sure if those steps are compatible. And I remember C++ libraries are compiled into .so or .o file while most tutorials seems to be using .la files.
MWE
src/main.cpp
#include"../include/conn/bash/stdout.hpp"
#include<string>
#include<iostream>
int main() {
std::string o=d::conn::bash::exec("ls");
std::cout << o << std::endl;
return 0;
}
include/conn/bash/stdout.hpp
#ifndef __CONN_BASH_O__
#define __CONN_BASH_O__
#include<string>
namespace d { namespace conn { namespace bash {
std::string exec(const char*);
}}}
#endif
lib/conn/bash/stdout.cpp
#include"../../../include/conn/bash/stdout.hpp"
#include <cstdio>
#include <iostream>
#include <memory>
#include <stdexcept>
#include <string>
#include <array>
std::string d::conn::bash::exec(const char* cmd) {
std::array<char, 128> buffer;
std::string result;
std::unique_ptr<FILE, decltype(&pclose)> pipe(popen(cmd, "r"), pclose);
if (!pipe) {
throw std::runtime_error("popen() failed!");
}
while (fgets(buffer.data(), buffer.size(), pipe.get()) != nullptr) {
result += buffer.data();
}
return result;
}
// https://stackoverflow.com/a/478960/8460574
Compiled and tested with g++ ./lib/**/*.cpp src/main.cpp
I've tried to find documentation online, but it seems that most of
them are targeted at C programs instead of C++,
"Most of them" suggests that you are searching out tutorials. Documentation would be the Automake manual, which you would be well advised to read. It covers these topics and many more that you will want to know about as you continue with the Autotools, and with Automake in particular. At minimum, you should know how to find the manual so as to consult it at need. Tutorials and guides can be helpful, but they should be regarded as supplements to the manual, not primary sources.
which I'm not sure if
those steps are compatible.
They mostly are. The main thing to be aware of is that command-line options for the C compiler are specified via a CFLAGS primary (see below), whereas those for the C++ compiler are specified via a CXXFLAGS primary.
And I remember C++ libraries are compiled
into .so or .o file while most tutorials seems to be using .la files.
You seem to be confused. The formats associated with those extensions are not language-specific, and .o does not designate a library at all.
.o is the conventional extension for the object file arising from compiling a single source file. These can be linked into an executable, or they can be gathered together into a library, but they are not libraries themselves.
Conventional UNIX library extensions are .a for static libraries and .so for shared libraries. This applies to any language that can be used to build general-purpose link libraries, including C, C++, Fortran, and a variety of others.
The .la extension is something else. It designates a libtool library. Libtool is another of the autotools, focused on abstracting system-specific details of building and using libraries. This is again language independent. Building a libtool library will cause either a corresponding static library, a corresponding shared library, or both to be built and installed, depending the options specified in the Autotooling and / or on the configure command line.
You should use libtool if you are building shared libraries with the Autotools. You may also use it if you are building only static libraries (.a), but it is a bit simpler in that case to leave libtool out of the picture.
As for the specific question posed, you write:
And for the endpoints' directory (under lib/) I have something like
following
main_SOURCES = stdout.cpp
But it gave me error that no program named main,
Always present the actual text of the error message (as text), rather than a paraphrase. If you have to ask a question about it here, then there is a significant risk that your understanding of the message is incomplete or wrong, and therefore that your paraphrase is misleading.
In this case, I am relatively confident that Automake's complaint was that there is no target named "main". The line you've given specifies a source list for such a target, but Automake does not find that target defined in that Makefile.am file. The difference between "program" and "target" is a bit subtle, but significant.
Supposing that you are trying to build a convenience library -- that is, one that groups functions for compile-time use in building other targets, but is not intended to be installed as a standalone library* -- you could get it with something like:
noinst_LIBRARIES = libendpoints.a
That consists of thee main pieces:
LIBRARIES is the "primary", specifying what kind of definition is being given. In this case, it is the definition of a list of static library targets included in the project.
libendpoints.a specifies the name of a (static library) target. This is an external name: the build will generate a file by this name in the build tree. Do make a habit of using standard naming conventions for this, such as I demonstrate.
noinst specifies where the built target will be installed by make install. This particular value is a special one indicating that the target will not be installed at all. If you wanted it installed in the configured libdir then you would instead say lib.
The properties of that target must be given by other definitions, based on a munged form of its name. For instance, its source list might look like this:
libendpoints_a_SOURCES = stdout.cpp
That again consists of three pieces:
SOURCES is again the primary. In this case, it says that the definition provides a source list for some target.
libendpoints_a identifies the target whose source list is being given. It is a munged form of the target name, with characters that cannot appear in variable names replaced by '_' characters.
stdout.cpp is the (single-element) source list.
To use that, the main program's properties would also need to specify that the library should be linked. That would mean something along these lines in the Makefile.am in which the main program target is defined:
main_LDADD = lib/endpoints/libendpoints.a
That is again a three-part definition, whose interpretation I leave as an exercise.
*And if you wanted a static library that does get installed to the system then you would swap out the "noinst" for a prefix that identifies the installation location, such as "lib". And there is a slightly different form for libtool-mediated libraries, including shared libaries.
If you're just defining a convenience target for you library, you should be able to do so by declaring it as noinst_LIBRARIES = libmine.a and then declaring it as a stdout_LIBADD.
But most likely, if you don't want this as an installed library, you just want to list the sources directly in a single, non-recursive Makefile.am file, see https://autotools.io/automake/nonrecursive.html
If you do want your library to be installable, then you want to use libtool: https://autotools.io/libtool/index.html

Linking SDL2/SD2_image statically with CMake

I'm trying to add SDL2 as a library to my project. I want to link it statically. I'm new to c++.
1 - Why does the SDL website recommend linking dynamically whenever possible?
I understand the benefits of dynamic libs. However, assuming users will have all the libraries you need already installed and ready to go in their system is a pretty big assumption IMO.
The only case where linking dynamically sounds like a good idea to me is where you are using well know libraries that ship with the OS/platform.
https://wiki.libsdl.org/Installation
2 - Linking dynamically seems to automatically find the intrinsic dependencies of (SDL2 and SDL2_image). Linking statically does not. Why is this the case? Here's my FindSDL2_image.cmake file
find_path(SDL2_IMAGE_INCLUDE_DIR SDL_image.h)
include_directories(${SDL2_IMAGE_INCLUDE_DIR})
# PREFER STATIC LIBRARIES ########
# cmake respects the order of extensions when looking for libraries
SET(CMAKE_FIND_LIBRARY_SUFFIXES .lib .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
# ------------------- ########
find_library(SDL2_IMAGE_LIBRARY NAMES SDL2_image PATH_SUFFIXES lib ${VC_LIB_PATH_SUFFIX})
set(SDL2_IMAGE ${SDL2_IMAGE_LIBRARY})
This links sdl2_image statically. It doesn't link properly because Undefined symbols:
"_png_set_strip_16", referenced from:
_IMG_LoadPNG_RW in libSDL2_image.a(IMG_png.o)
"_png_set_write_fn", referenced from:
_IMG_SavePNG_RW_libpng in libSDL2_image.a(IMG_png.o)
"_png_write_png", referenced from:
_IMG_SavePNG_RW_libpng in libSDL2_image.a(IMG_png.o)
If I remove the section ### PREFER STATIC LIBRARIES ## on the cmake file. It links dynamically and everything works as expected. Why when linking dynamically the intrinsic dependencies are resolved but not when linking statically?
----UPDATE----
I was able to link sdl2_image statically by including its dependencies explicitly
find_library(PNGLIB png)
find_library(JPEG jpeg)
find_library(TIFF tiff)
find_library(WEBP webp)
find_library(LZ z)
target_link_libraries(smb ${SDL2} ${PNGLIB} ${JPEG} ${TIFF} ${WEBP} ${SDL2_IMAGE} ${LZ})
However, this will not scale well for me.
Figuring out what these dependencies took a bit of guesswork and googling. Ideally, I'd like CMAKE to pull these in automatically.
it looks like there are several questions, I'll try my best to answer the question step by step:
Why does the SDL website recommend linking dynamically whenever
possible
One of the reason to link you application dynamically against a library is to decouple the application from the library (it is called shared library / .so in this case). You could update your library without the necessity of recompiling your application code. E.g. in case you have finished your project, and your client have your application running, I suppose, it is not likely that you want to recompile your application code, once there is a bug fix of the underlying library you are using.
On the other side, by linking your application statically, you're binding your application with that library (.lib or .a form). Means every changes in the library will cause you to recompile your code. Sometime this is wished, e.g. you have provide your client a warranty of your application, usually you want to be sure that no future problem with your library would cause your application to be crashed.
I have a short example code to understand this better:
CMakeLists.txt:
cmake_minimum_required (VERSION 3.0)
project(linkageLibrary)
set(STATIC_LIB lib_static)
set(SHARE_LIB lib_share)
set(STATIC_OTHER_LIB lib_otherstatic)
set(SHARE_OTHER_LIB lib_othershare)
add_library(${STATIC_LIB} STATIC ${STATIC_LIB}.cpp)
add_library(${SHARE_LIB} SHARED ${SHARE_LIB}.cpp)
# not yet in usage...
add_library(${STATIC_OTHER_LIB} STATIC ${STATIC_OTHER_LIB}.cpp)
add_library(${SHARE_OTHER_LIB} SHARED ${SHARE_OTHER_LIB}.cpp)
add_executable(${CMAKE_PROJECT_NAME} main.cpp)
target_include_directories(${CMAKE_PROJECT_NAME} PUBLIC ${${CMAKE_PROJECT_NAME}_SOURCE_DIR})
target_link_libraries(${CMAKE_PROJECT_NAME} ${STATIC_LIB} ${SHARE_LIB})
file(WRITE ${CMAKE_BINARY_DIR}/exchangeShareLibrary.sh "
echo \"before exchange the static library\"
${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME} &&
mv ${CMAKE_BINARY_DIR}/lib${SHARE_LIB}.so ${CMAKE_BINARY_DIR}/lib${SHARE_LIB}.so.bk &&
cp ${CMAKE_BINARY_DIR}/lib${SHARE_OTHER_LIB}.so ${CMAKE_BINARY_DIR}/lib${SHARE_LIB}.so &&
echo \"after the shared library has been changed\" &&
${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}")
file(WRITE ${CMAKE_BINARY_DIR}/exchangeStaticLibrary.sh "
echo \"before exchange the static library\"
${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME} &&
mv ${CMAKE_BINARY_DIR}/lib${STATIC_LIB}.a ${CMAKE_BINARY_DIR}/lib${STATIC_LIB}a.bk &&
cp ${CMAKE_BINARY_DIR}/lib${STATIC_OTHER_LIB}.a ${CMAKE_BINARY_DIR}/lib${STATIC_LIB}.a &&
echo \"after the static library has been changed\" &&
${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}")
main.cpp:
#include <iostream>
#include "lib.hpp"
using namespace std;
int main() {
printStaticLib();
printShareLib();
return 0;
}
lib.hpp:
#pragma ONCE
void printStaticLib();
void printShareLib();
lib_static.cpp:
#include <iostream>
#include "lib.hpp"
using namespace std;
void printStaticLib() {
cout << "linkage of lib_static" << endl;
}
lib_share.cpp:
#include <iostream>
#include "lib.hpp"
using namespace std;
void printShareLib() {
cout << "linkage of lib_share" << endl;
}
lib_otherstatic.cpp:
#include <iostream>
#include "lib.hpp"
using namespace std;
void printStaticLib() {
cout << "linkage of the other lib_static with other text" << endl;
}
lib_othershare.cpp:
#include <iostream>
#include "lib.hpp"
using namespace std;
void printShareLib() {
cout << "linkage of the other lib_share with other text" << endl;
}
if you run the generated scripts, you'll notice the printShareLib() will output differently after the .so get exchange, but not the printStaticLib(). (Try to make again without clean-up, if you now execute ./linkageLibrary, you'll get this time also other output for the printStaticLib(). Can you guess why?)
to your second issue:
2 - Linking dynamically seems to automatically find the intrinsic dependencies of (SDL2 and SDL2_image). Linking statically does not. Why is this the case?
without knowing your system setup, I guess the .a static library couldn't be found by your build system. Try to find where it is, and eventually put find_library(SDL2_IMAGE_LIBRARY NAMES SDL2_image HINTS ${_YOUR_SDL2_INSTALLATION_PATH})link
now back to your question, why SDL2 suggested to be linked dynamically, well it is the decision of the library developer, as you could read in his README
Please also refer this blog of how using SDL2 with CMake
A Static library is merely a collection of compiled object files. It does not have any additional information about its dependent libraries. You can use the ar -t &ltstatic_lib&gt command to view the contents of a static library. So if you need to link your executable to a static library, you have to provide the names and paths of all its dependent libraries.
For example: Consider two static libs, A and B and assume that A depends on B. Then if want your exe C to link to A, then your link statement should contain both A and B. Then only all the symbols will defined properly.Linker: C ===> A and B
A dynamic library is different and more intelligent than a static. It is of ELF format and it's headers have information about its dependent shared libraries. This can be viewed by issuing the ldd &ltdynamic_lib&gt command on it. Also dynamic loader knows at runtime to pick the dependent libraries from the standard locations. If it can't find, it will give an error. In your case, you will find the information about the dependent libraries of your dynamic library in your ldd output and presumably, all those libraries will be in a standard location. That is the reason you are not finding an error, when you are trying to dynamically link.
Here are some useful links to know more about this,
https://renenyffenegger.ch/notes/development/dynamic-loader
https://amir.rachum.com/blog/2016/09/17/shared-libraries/
When you do a find_package in CMake will search for a Findxxx.cmake file in some CMAKE-defined paths.
The command has two modes by which it searches for packages: “Module” mode and “Config” mode. Module mode is available when the command is invoked with the above reduced signature. CMake searches for a file called Find.cmake in the CMAKE_MODULE_PATH followed by the CMake installation.
(https://cmake.org/cmake/help/latest/command/find_package.html)
So you have to define your own FindSDL2.cmake which will tell where is the library. (https://cmake.org/cmake/help/v3.17/manual/cmake-developer.7.html)
And you need to say to find_package to search for your own FindSDL2.cmake. You can pass a path to find_package to perform this.
If you make CMake use your file, the variables ${SDL2_INCLUDE_DIRS} and ${SDL2_LIBRARIES} you will be the one you have defined in your file.
A couple of possibilities here ..
The easiest explanation is that you have a dynamic libpng.so.x installed somewhere where your dynamic linker can find it (/usr/lib, /usr/local/lib, etc), but don't have a static libpng.a. The answer in that case would be to install a static libpng.a and see if cmake's magic can resolve it.
The next easiest explanation is that there is no libpng.* on your system and there is some dynamic late binding going on. This can happen if, for instance, the software that you are building is also building libpng.* in which case the late binding will allow you to successfully dynamically link your application to it, even though libpng actually has not yet been installed in /usr/lib or /usr/local/lib or wherever the software you are building will eventually put it. This is sort of a chicken-and-egg situation. You can figure this out by issuing "ldd foo" where "foo" is the name of your application. The output will be a grocery list of all the things the dynamic linker needs to fetch for your executable, libpng should be in the list and there should be a resolved path listed for it, if not it's possible that your application may start but subsequently crash if for instance png_write_png() is at some point invoked. How to workaround this would be to install the libpng.* libraries that your application is expecting, prior to building.
Hope this helps a bit :)

C++ include libraries

Ok, so it's been a while, and i'm having problems with #includes
So I'm doing
#include "someheader.h"
but it's giving me
fatal error: someheader.h: No such file or directory
It's a system wide library I guess you could say.
I'm running arch linux and I installed the library from the repo, and I think the .h files are in /usr/include.
I could just copy all the header files into the folder my code is in but that would be a hack.
What is the "right" way to do this?
Edit: I wasn't correct by saying the .h files were in /usr/include, what I meant was that the library folder was in there
So, Emile Cormier's answer worked to a certain extent.
The problem now is that there are some include in the header file and it seems from the methods I'm trying to access that those includes are not happening
it's giving my the error
undefined reference to Namespace::Class::method()
Edit:
Ok so the final answer is:
#include <library_name/someheader.h>
And compile with
g++ code.cpp -llibrary_name
Sometimes, header files for a library are installed in /usr/include/library_name, so you have to include like this:
#include <library_name/someheader.h>
Use your file manager (or console commands) to locate the header file on your system and see if you should prefix the header's filename with a directory name.
The undefined reference error you're getting is a linker error. You're getting this error because you're not linking in libsynaptics along with your program, thus the linker cannot find the "implementation" of the libsynaptics functions you're using.
If you're compiling from the command-line with GCC, you must add the -lsynaptics option to link in the libsynaptics library. If you're using an IDE, you must find the place where you can specify libraries to link to and add synaptics. If you're using a makefile, you have to modify your list of linker flags so that it adds -lsynaptics.
Also the -L <path_to_library> flag for the search path needs to be added, so the linker can find the library, unless it's installed in one of the standard linker search paths.
See this tutorial on linking to libraries with GCC.
You'd use #include <someheader.h> for header files in system locations.
#include "someheader.h" would try to include the file someheader.h in the directory of your .c file.
In addition to including the header file, you also need to link in the library, which is done with the -l argument:
g++ -Wall youprogram.cpp -lname_of_library
Not doing so is the reason for the "undefined reference .. " linker errors.
The quick fix is to do use:
#include <someheader.h>
assuming that someheader.h is in the standard include locations (to find it use the command locate someheader.h in a shell. If it is in /usr/include it is in a standard location. If it is in a subdirectory of /usr/include you only need to add the part of the directory up to /usr/include in the #include directive (e.g. #include <fancy_lib/someheader.h>)
However, this is only half of the story. You also will need to set up your build system in a way that locates the given library and adds its include path (the path under which it's header files are stored) to the compiler command (for gcc that is -I/path/to/header). That way you can also build with different versions by configuring them in your build system. If the library is not header-only you will also have to add it to the linker dependencies. How this is achieved in your build system is best found out by consulting its documentation.

Problems including jsonCpp headers

I'm trying to implement the jsoncpp libraries in my C++ code, I wrote a simple piece of code just to try it out, and it's not even compiling.
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#ifndef json_included
#define json_included
#include "jsoncpp\include\json\json.h"
#endif
//#include "json\jsonC\json.h"
int main(int argc, char **argv)
{
std::string example = "{\"array\":[\"item1\", \"item2\"], \"not an array\":\"asdf\"}";
Json::Value value;
Json::Reader reader;
bool parsed = reader.parse(example, value, false);
std::cout << parsed;
return 0;
}
The errors i'm getting are:
undefined reference to `Json::Reader::parse(std::string const&, Json::Value&, bool)'
undefined reference to `Json::Reader::Reader()'
undefined reference to `Json::Value::~Value()'
undefined reference to `Json::Value::Value(Json::ValueType)'
I'm a bit new to C++, is there something I'm missing in the include statement? Or does jsonCpp need something extra?
Thank you for your time!
Your code is compiling, but it is not linking. You forgot to provide the JSON shared library files to your linker (or, on newer versions, to add the amalgamated jsoncpp.cpp to your project).
Without knowing more about your development environment, it's hard to give you more specific instructions.
BTW, you're writing C++; use C++ headers like cstdio, not stdio.h, please. You also failed to include C++ string and got lucky that it "worked" through some JSON header including it for you.
"Undefined reference" sounds like a linker problem. Does jsoncpp come with a library that you need to link to, such as a .so, .a, .lib or .dll file?
According to the jsoncpp README, the library must first be built using scons. Presumably this will then output a library file such as a .so, .a, .lib or .dll file. You must then follow your compiler's rule for linking against such a library (e.g. add it to the end of the command line when compiling, or add it to the "additional libraries" field in the project config in your IDE).
In my case (using CodeBlocks IDE on Ubuntu) the problem was that I needed to add the json.cpp file (generated with python amalgamate.py from within the jsoncpp project) to my build targets.
In other words, I added a -c jsoncpp.cpp option to my g++ compile statement.
You need to link to the json libraries, e.g. using -ljson_linux-gcc-4.4.3_libmt
You can find the exact library name by looking in the library directory, e.g. /usr/lib
If you're using Visual Studio, add the .lib file to Project Properties, Linker, Input, Additional Dependencies and specify the path in Project Properties, Linker, General, Additional Library Directories
Two potential issues:
There is a bug in some versions of the jsoncpp library code where amalgated needs to become amalgamation for the linking to work correctly.
As the other answers suggested, #include
After you compile jsoncpp you can find the libraries in the folder libs/ . For convenience you can put it in /usr/lib and then link it at run time by passing -llibjson_linux-gcc-4.4.3_libmt as an argument to g++.
I have renamed libjson_linux-gcc-4.4.3_libmt.so to libjson.so and can link it by specifying -ljson.

How do I install a c++ library so I can use it?

I have this library called BASS which is an audio library which I'm going to use to record with the microphone. I have all the files needed to use it, but I don't know how to install the library. I tried taking the example files and putting them in the same directory as the bass.h file. But I got a bunch of errors saying there are function calls that doesn't exist.
So my question is, how do I install it to be able to use it?
Installing a C++ library means specifying to interested software (eg. a compiler) the location of two kinds of files: headers (typical extensions *.h or .hpp) and compiled objects (.dll or *.lib for instance).
The headers will contain the declarations exposed to the developer by the library authors, and your program will #include them in its source code, the dll will contain the compiled code which will be or linked together and used by your program, and they will be found by the linker (or loaded dynamically, but this is another step).
So you need to
Put the header files in a location which your compiler is aware of (typically IDE allows to set so-called include directories, otherwise you specify a flag like -I<path-to-headers> when invoking the compiler)
Put the dll files in a location which your linker is aware of (surely your IDE will allow that, otherwise you speficy a flag like -L<path-to-libraries> -l<name-of-libraries>
Last but not least, since I see that BASS library is a commercial product, probably they will have made available some installation instructions?
Run this command in a terminal or console.
cpp -v
Notice at the end of the output, you'll see a line like this:
#include<...> search starts here:
There will be a list of directories below that line.
Move the package folder to one of those directories.
Then try importing the module with <>.
See the code below code and don not forget to put bass.dll in the directory of your exe file and include the file bass.lib with your project and don not forget also to include the path to bass.h and bass.lib in the default include and lib path of your project.
#include <iostream>
#include "bass.h"
using namespace std;
int main(int argc, const char **argv)
{
if (!BASS_Init(-1, 44100, 0, NULL ,NULL))
{
cout<<"Can't initialize device";
return -1;
}
int stream = BASS_StreamCreateFile(false, "D:\\mypro\\Trans_Langs\\germ\\quran_amma\\Translations\\Sound_aya\\Sora1\\Hafs\\basfar\\a7.mp3", 0L, 0L, 0);
if (stream != 0)
{
// play the stream channel
BASS_ChannelPlay(stream, false);
}
else
{
// error creating the stream
cout<<"Stream error: {0}", BASS_ErrorGetCode();
}
getchar();
BASS_StreamFree(stream);
// free BASS
BASS_Free();
return 0;
}
If there are files named configure, Makefile or install you can try running them in that order. After that, any program that wants to link with this library must use a command like this:
c++ <your_program.cpp> -l<library_name> -L<path_where_library_is_installed>
The library path is usually the original library folder itself, unless you explicitly change it or the library itself puts its files in global locations like /usr/local or something like that.