I am currently trying to write a small program using FMOD audio libraries but am having trouble understanding how to link them.
I have a small program that looks as follows
#include "/home/me/fmod_test/api/lowlevel/inc/fmod.h"
#include "/home/me/fmod_test/api/lowlevel/inc/fmod.hpp"
#include "/home/me/fmod_test/api/lowlevel/inc/fmod_errors.h"
#include <iostream>
using namespace std;
int main()
{
FMOD::System *system;
FMOD::Sound *sound1;
FMOD::System_Create(&system); // create an instance of the game engine
}
But when I attempt to compile using
g++ -L/home/me/fmod_test/api/lowlevel/lib/x86_64 -lfmod -lfmodL test.cpp -o test
I get an error like this
In function `FMOD::System_Create(FMOD::System**)':
test.cpp:(.text._ZN4FMOD13System_CreateEPPNS_6SystemE[_ZN4FMOD13System_CreateEPPNS_6SystemE]+0x14): undefined reference to `FMOD_System_Create'
I have included screenshots to show that these libraries and headers do actually exist in my system
Interestingly enough, if I comment out the System_Create call the FMOD::System and Sound initializations still work fine.
Am I linking incorrectly, I cant figure out why this wouldnt be working (and yes I am on x86_64 architecture as per the output of uname -a)
g++ -L/home/me/fmod_test/api/lowlevel/lib/x86_64 -lfmod -lfmodL test.cpp -o test
This command line is backwards. As explained in this answer, libraries must follow sources and object files on command line (the answer says that the order doesn't matter for shared libraries, but that part of the answer is wrong (for at least some linkers)). Try:
g++ -L/home/me/fmod_test/api/lowlevel/lib/x86_64 test.cpp -o test -lfmod -lfmodL
Related
I want to compile a C++ program with a twitter library, on Linux.
I'm current using twitcurl as the twitter API library and installed g++ and all the necessary files and packages that are listed on the official website: http://code.google.com/p/twitcurl/wiki/WikiHowToUseTwitcurlLibrary
However, when I compile my program using this command g++ twitterClient.cpp -ltwitcurl, I get this error: cannot find -ltwitcurl
I also used CodeBlocks IDE to compile it but got this error: undefined reference to twitCurl::~twitCurl()
`
My code only contains a few lines:
#include <iostream>
#include "Twitter/Twitter.hpp"
using namespace std ;
int main ()
{
Twitter t ;
return 0 ;
}
I've already spent a lot of time on this but am unable to solve the problem. What should I do in order to compile the program on the command-line and CodeBlocks?
$ g++ twitterClient.cpp -ltwitcurl
cannot find -ltwitcurl
This means your compiler doesn't find the libtwitcurl.so.1. in its library directories.
First, make sure you correctly build the twitcurl library and obtained the libtwitcurl.so.1. file with something like this :
svn co http://twitcurl.googlecode.com/svn/trunk/libtwitcurl
cd libtwitcurl/
make
Secondly, make sure you put the file (or a symlink) in one of your compiler's library path :
cp libtwitcurl.so.1.0 /usr/lib/
You can check g++ library paths using the following command :
g++ --print-search-dirs | grep libraries
(/usr/lib/ is usually at the end.)
If you don't want/can't put the file in your compiler's library path, you can also tell it where to find libtwitcurl.so.1. by adding -L/path/to/twitcurl/ in the g++ options, but it is not needed if the file is already in one of the compiler's library path.
You need to specify path to twitter lib:
g++ twitterClient.cpp -L/path/to/lib/dir -ltwitcurl
Alright, I realize that this might seem like a duplicate, but I've tried most variations and attempts via' searched posts, and I'm still coming up with nothing. Here's the issue: I am working with an open-source C library called libxls that is used for reading .xls files (aptly named project.. :) ). The code I'm using is straight off their website, essentially just a beginning toy example to make sure I can access the libraries:Link to their website with the source
#include <stdio.h>
#include "libxls/xls.h"
int main(){
xlsWorkBook* pWB;
pWB = xls_open("Book1.xls", "iso-8859-15//TRANSLIT");
return 0;
}
That's it. Now, the syntax of that is fine. I know for a fact through the nm command that xls_open is indeed available as a function in the .a library, so that's not a problem. in my directory I have the following files (pardon the redundant naming, I was just trying to force it to work real quick):
Book1.xls
libxlsreader.a
libxlsReader.c
libxlsreader.so
Although I don't THINK I need the .so file here since I've tried dynamically linking to where that lives, figured it wasn't a bad plan to try. Alright, so, on the include line, I keep getting the common:
libxlsreader.c:3:37: fatal erro: libxls/xls.h: No such file or directory
Ok fine, so I probably linked in the library wrong, take a look at my compile line arguments:
gcc -o libxlsWrapper libxlsReader.c -L /usr/local/lib/ -lxlsreader -lpthread
huh, well.. that certainly LOOKS right, /usr/local/lib/ is where the library created itself with all of it's .so files, and the .a one in my PWD. Now, I'm a java developer by trade, so I might be missing something blaringly obvious, but for the life of me I can't determine what it is. it certainly seems ok to me.
I'm using GCC (ubuntu/Linaro 4.7.3-lubunutul) 4.7.3 on Linux Mint 15 KDE 32-bit.
If you'd like to reproduce the library for your own testing or problem solving, it can be obtained from
I don't recommend recreating it on windows, I tried for a couple hours yesterday and gave up, so just do the regular ./configure -> make -> make install and that should produce the appropriate libraries for you.
Thanks!
-Will
edit #1: here are some of the other linking attempts I've tried, all with the identical result.
gcc -o libxlsWrapper libxlsReader.c -L. -lxlsreader -I.
gcc -o libxlsWrapper libxlsReader.c -L. -lxlsreader -lpthread
gcc -o libxlsWrapper libxlsReader.c -L. -lxlsreader.so
I also tried a bunch with g++ instead of gcc (throwing darts, I know), same result.
Please do a find your_folder -type f -iname xls.h and then use a gcc -I /the_path to include the path for xls.h. Because the problem you have is that gcc could not locate the header file xls.h.
I'm a novice at C++. Be patient if this is incoherent. I'm called upon to build a large system on linux that was originally built on OS X, where it works fine. The original authors are no longer with the company. The build system makes use of autotools, but there are also some hand made Makefiles which walk through the system calling the auto-made Makefiles. I've managed to get all of the c++ code compiled. The build system also uses libtools, and shared libraries are produced and deposited in /usr/local/lib.
So now I'd like to use these libraries. I've written a short program that simply instantiates an object of class ds_dictionary and calls one of its methods. Here it is:
#include <iostream>
#include <DSUtils/DSUtils.h>
int main (int argc, char * const argv[]) {
int32_t integer_data=123;
char key_alice_integer[] = "alice_integer";
ds_dictionary my_dict;
my_dict.add_int(key_alice_integer, integer_data);
return 0;
}
I compile this with
g++ -lDSUtils -o main my_test_code.cpp
With the result:
//usr/local/lib/libDSUtils.so: undefined reference to `ds_breakdown_from_time_interval'
//usr/local/lib/libDSUtils.so: undefined reference to `ds_date_breakdown_with_string'
//usr/local/lib/libDSUtils.so: undefined reference to `ds_seconds_duration_of_interval'
... (about 25 lines like these)
collect2: ld returned 1 exit status
Let's look inside the library:
garyp#VM:/usr/local/lib$ nm libDSUtils.so | grep ds_breakdown_from_time
U ds_breakdown_from_time_interval
The "U" in the line above ... does that mean that the library wasn't built correctly?
Am I calling g++ correctly?
Do I have to put something in the code to tell it that I'm using functions found in that library?
What are possible errors? Where should I start poking around?
EDIT:
Aha. The library DSUtils is built from several c++ sources. There is one c program in the source, and it contains all of the problem functions. The Makefile system doesn't deal at all with that one c file. That c program compiles. Ideally I suppose I'd figure out how to modify the Makefile to compile that file and add it to the library, but I'm not to the point where I can figure out how to do that.
Can I add the .o file to the existing library? How? Create a library with one file? etc?
EDIT_2: I simply did
g++ -o main -lDSUtils main.o my_new_objectfile.o
and the thing compiles, links, and runs without error. Should that work? After fixing a logic bug, it does work.
This
U ds_breakdown_from_time_interval
tells me that ds_breakdown_from_time_interval will be resolved by another library during runtime. So I am guessing you need to link to the library that defines ds_breakdown_from_time_interval.
I have this program which uses Boost::Asio for sockets. I pretty much altered some code from the Boost examples. The program compiles and runs just like it should on Windows in VS. However, when I compile the program on Linux and run it, I get a Segmentation fault.
I posted the code here
The command I use to compile it is this:
c++ -I/appl/htopopt/Linux_x86_64/NTL-5.4.2/include
-I/appl/htopopt/Linux_x86_64/boost_1_43_0/include
mpqs.cpp mpqs_polynomial.cpp mpqs_host.cpp -o mpqs_host
-L/appl/htopopt/Linux_x86_64/NTL-5.4.2/lib -lntl
-L/appl/htopopt/Linux_x86_64/gmp-4.2.1/lib -lgmp -lm
-L/appl/htopopt/Linux_x86_64/boost_1_43_0/lib -lboost_system
-lboost_thread -static -lpthread
By commenting out code, I have found out that I get the Segmentation fault due to the following line:
boost::asio::io_service io_service;
Can anyone provide any assistance, as to what may be the problem (and the solution)?
Thanks!
Edit: I tried changing the program to a minimal example, using no other libraries or headers, just boost/asio.hpp:
#define DEBUG 0
#include <boost/asio.hpp>
int main(int argc, char* argv[]) {
boost::asio::io_service io_service;
return 0;
}
I also removed other library inclusions and linking on compilation, however this minimal example still gives me a segmentation fault.
From the GCC online documentation of the -static option:
On systems that support dynamic linking, this prevents linking with the shared libraries.
Boost can support static-only linkage but only if it was configured that way when the OS Package maintainer built it. Are you absolutely certain you should be using this flag? If not, try recompiling without the flag and see if that doesn't take care of the problem.
I am pretty new to Ubuntu, but I can't seem to get this to work. It works fine on my school computers and I don't know what I am not doing. I have checked usr/include and time.h is there just fine. Here is the code:
#include <iostream>
#include <time.h>
using namespace std;
int main()
{
timespec time1, time2;
int temp;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1);
//do stuff here
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time2);
return 0;
}
I am using CodeBlocks as my IDE to build and run as well. Any help would be great, thank you.
Add -lrt to the end of g++ command line. This links in the librt.so "Real Time" shared library.
example:
c++ -Wall filefork.cpp -lrt -O2
For gcc version 4.6.1, -lrt must be after filefork.cpp otherwise you get a link error.
Some older gcc version doesn't care about the position.
Since glibc version 2.17, the library linking -lrt is no longer required.
The clock_* are now part of the main C library. You can see the change history of glibc 2.17 where this change was done explains the reason for this change:
+* The `clock_*' suite of functions (declared in <time.h>) is now available
+ directly in the main C library. Previously it was necessary to link with
+ -lrt to use these functions. This change has the effect that a
+ single-threaded program that uses a function such as `clock_gettime' (and
+ is not linked with -lrt) will no longer implicitly load the pthreads
+ library at runtime and so will not suffer the overheads associated with
+ multi-thread support in other code such as the C++ runtime library.
If you decide to upgrade glibc, then you can check the compatibility tracker of glibc if you are concerned whether there would be any issues using the newer glibc.
To check the glibc version installed on the system, run the command:
ldd --version
(Of course, if you are using old glibc (<2.17) then you will still need -lrt.)
I encountered the same error. My linker command did have the rt library included -lrt which is correct and it was working for a while. After re-installing Kubuntu it stopped working.
A separate forum thread suggested the -lrt needed to come after the project object files.
Moving the -lrt to the end of the command fixed this problem for me although I don't know the details of why.