I am working with the windows.h functions and everything works fine so far.
But when I try to use functions which require me to link external libraries something goes wrong.
In this case I am trying to use CreateFont(). I already know that I must link libwinmm.a and libgdi32.a and I've done that:
See this screenshot
But when I try to build the project i get following error messages:
g++ "-LD:\\Programme\\Eclipse\\lib" -o GameTest.exe "src\\choosemealmain.o" "src\\mealchooser.o" "-lD:\\Programme\\Eclipse\\lib\\libwinmm.a" "-lD:\\Programme\\Eclipse\\lib\\libgdi32.a"
d:/programme/eclipse/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lD:\Programme\Eclipse\lib\libwinmm.a
d:/programme/eclipse/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lD:\Programme\Eclipse\lib\libgdi32.a
collect2.exe: error: ld returned 1 exit status
I made sure to doublecheck whether the mentioned libraries are actually to be found in the mentioned path and they are.
I would be glad for any kind of help!
You are wrongly using quotes with -l flag. The -l flag also automatically adds the lib prefix and the .a extension. Your command line should be:
g++ -LD:\Programme\Eclipse\lib -o GameTest.exe "src\choosemealmain.o" "src\mealchooser.o" -lwinmm -lgdi32
Related
I'm new to programming c++ with g++ and have big problems to get wsdlpull-library to work. The version is 1.24.
I followed the installation steps from http://wsdlpull.sourceforge.net/.:
./configure --prefix=/home/jesse/Dropbox/Programmering/C++/test --disable-opt --enable-examples
make
make install
I then copied print.cpp file from the example to the "prefix"-directory. The next step would be "add the $(prefix)/include in your include path and add $(prefix)/libs and -lwsdl -lschema -lxmlpull to your LDFLAGS". The first problem is that there's no folder "libs" but "lib" and the include-folder has another folder inside named wsdlpull. Therefore I instead entered the following command:
g++ -I include/wsdlpull -L lib -lwsdl -lschema -lxmlpull -o print print.cpp
This resulted in the following error:
/usr/bin/ld: cannot find -lwsdl
/usr/bin/ld: cannot find -lschema
/usr/bin/ld: cannot find -lxmlpull
collect2: error: ld returned 1 exit status
I have no idea what this means, why does it look in /usr/bin/ld when I point to "lib"?
When you use -L lib, it means that, lib dir is available in pwd where you are doing make. Check whether you have said lib is really available or not.
To make things simple, you can give the absolute path of the lib folder.
i.e -L<path to lib>/lib. This would help the make to see the lib without any confusions.
Next, you might want to explicitly specify whether libwsdl is a static or shared library. Although this is optional.
Or, the best solution is to place the libraries in system libs location i.e /lib or /usr/lib or /use/local/lib and run ldconfig such that the linker/loader knows where the newly added libraries exists. In such case, you can simple issue -lwsdl without specifying the -L flag.
For more info, please refer ldconfig.
OS: Windows 7
I have the source, as well as all the library files I'm using in one directory, on my desktop. I'm running the shell by using msys.bat, which was created when I installed MinGW. I've tried to run the following (and many others):
g++ -I. -L. -o opengltest.exe opengltest.cpp -lglew32 -lglew32s -lglew32.dll
I recieve the following error:
c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -lglew32.dll
collect2: ld returned 1 exit status
This also happens when I use the -L switch and the entire C:/Users/... path, but I get the same error. Again, glew32.dll is in the same directory that the .cpp is in, which is the same directory I'm working in within the shell. I've tried multiple solutions from multiple posts, and it still seems like I'm missing something. I thought using the -L. was a straightforward way to tell MinGW to look in the working directory, but apparently it doesn't work that way.
Do not link against both the dynamic and static linking version of glew in the same application. This makes no sense. Also do no link against glew32.dll, this makes equally little sense.
Most importantly, do not use the DLL version of glew with g++ at all - it will not work (see one of my previous answers to understand why). Instead, #define GLEW_STATIC (better if you use -DGLEW_STATIC as a compiler switch) and only link to glew32s.
I have a very basic C++ project in code blocks that makes use of glfw.so and two other libraries that are compiled to .so files from another project, libHorde3D.so and libHorde3DUtils.so. The latter are placed in the project root folder, while glfw is somewhere in my /usr/lib (I think).
I have added the project folder to the linker and compiler search paths in code blocks. I have added the libHorde3D.so and libHorde3DUtils.so as well as glfw.so to the Link Libraries in the Linker Settings tab. I thought that this would be enough based on the previous similar questions here on stackoverflow.
However when I press build:
ld cannot find -lHorde3D.so
ld cannot find -lHorde3DUtils.so
ld cannot find -lglfw.so
My system is Arch Linux 64 and I am using GCC.
I also tried bopying libHorde3D.so and libHorde3DUtils.so in /usr/lib and /usr/lib64 with no success.
P.S. All search paths are copied across the Debug and Release target.
Say, if the library name is libmylibrary.so, then linker option to link against that library would look like -lmylibrary. Note that lib prefix and .so suffix are not there — they are added automatically by the linker. In your case it seems like you specified the wrong name. Try removing .so from it, that should solve the problem.
Here is a simple demonstration of how to trigger the failure by making a similar mistake:
$ echo 'int main() { return 0; }' > test.c
$ gcc -o test ./test.c -lc
$ gcc -o test ./test.c -lc.so
/usr/bin/ld: cannot find -lc.so
collect2: ld returned 1 exit status
$
The first command succeeds and the second one (with incorrect library name) fails.
You must not pass ".so". The linker options are
-lHorde3D -lHorde3DUtils -lglfw
This way the linker will search for "libHorde3D.so" etc. in the library path(s).
I am using Ubuntu and my IDE is Aptana 3.0
I am getting the following error when trying to build. The library libfcgi.a is located in /usr/local/lib/.
In the Library C++ Linker section of the project properties, I added /usr/local/lib/ to the search path and the file /usr/local/lib/libfcgi.a.
Why can I still not build?
**** Build of configuration Debug for project rtb ****
make all
Building target: rtb
Invoking: GCC C++ Linker
g++ -L/usr/local/lib -o"rtb" ./src/rtb.o -l/usr/local/lib/libfcgi.a
/usr/bin/ld: cannot find -l/usr/local/lib/libfcgi.a
collect2: ld returned 1 exit status
make: *** [rtb] Error 1
I think this may be what you want;
g++ -L/usr/local/lib -o "rtb" ./src/rtb.o -lfcgi
-l<value> will automatically look in all folders listed with -L for a library named lib<value>.a or lib<value>.so, all you need is the '-lfcgi'.
Try "-lfcgi" instead
g++ -L/usr/local/lib -o"rtb" ./src/rtb.o -lfcgi
Your linker flag is wrong it needs to be -lfcgi and not the whole path with the "lib" prefix and the .a suffix.
You can change it by hand, or in Apatana. To do so you don't have to give him the full qualified path to your lib two times. ( You already gave him the search path, remember? ). Usually you define additional libraries just like this:
cfgi and your IDE does the rest to add it to the linker flags!
You should do
g++ -o "rtb" ./src/rtb.o -lfcgi
In the unlikely case that /usr/local/lib/ is not in your search path, you can either add that path in the command line like
g++ -L/usr/local/lib -o "rtb" ./src/rtb.o -lfcgi
or put it in the environment variable LIBRARY_PATH before calling your compile command, e.g. with bash:
if [ -z "$LIBRARY_PATH" ];
then export LIBRARY_PATH=/usr/local/lib;
else export LIBRARY_PATH="$LIBRARY_PATH":/usr/local/lib;
fi
If you insist in giving the explicit file name, omit the -l:
g++ -L/usr/local/lib -o "rtb" ./src/rtb.o /usr/local/lib/libfcgi.a
However I'd advise against that because it's inflexible. If the issue is that there's another, incompatible version of the library installed, it's better to make sure that the correct one comes first in the search path (or even better, make sure that the wrong one isn't in the search path at all ― maybe even by removing it from the system).
That's for the help all....really appreciate it.
Here is the solution. I had to use -lfcgi++ and I added the
g++ -L/usr/local/include/ -lfcgi++ -o"rtb" ./src/rtb.o
The above was the output from aptanta console. I tried -lfcgi and did not work. Google search lead to using -lfcgi++.
I need to use libcurl in a piece of software I am writing on my ubuntu machine. I am using Eclipse to write and compile all of the software. When I put the libcurl files in the same folder as the .cpp file, and include the curl.h file in the header, When I attempt to compile the program, It comes up with these errors:
Building target: sms
Invoking: GCC C++ Linker
g++ -o"sms" ./src/sms.o
./src/sms.o: In function `main':
/home/geekman/workspace/sms/Debug/../src/sms.cpp:38: undefined reference to `curl_easy_init'
/home/geekman/workspace/sms/Debug/../src/sms.cpp:42: undefined reference to `curl_easy_setopt'
/home/geekman/workspace/sms/Debug/../src/sms.cpp:44: undefined reference to `curl_easy_setopt'
/home/geekman/workspace/sms/Debug/../src/sms.cpp:46: undefined reference to `curl_easy_perform'
/home/geekman/workspace/sms/Debug/../src/sms.cpp:47: undefined reference to `curl_easy_cleanup'
collect2: ld returned 1 exit status
make: *** [sms] Error 1
I took the contents of the include folder from libcurl, and placed them in the same folder as the .cpp file. then in the header of the .cpp file, I typed:
#include <curl/curl.h>
I also tried:
#include "curl/curl.h"
Any ideas on the problem? Thanks.
Your header file inclusions are just fine; your problem is occurring at the linking step. In order to link against libcurl, you need to add the -lcurl command line option, assuming it's installed in a standard directory:
g++ -o sms ./src/sms.o -lcurl
If it's not installed in a standard directory, you also need to add the -L/path/to/libcurl, e.g. something like:
# Assuming that /home/geekman/workspace/libcurl is where libcurl.a is located
g++ -o sms ./src/sms.o -L/home/geekman/workspace/libcurl -lcurl
Also note that the -lcurl option has to appear after the list of object files you're linking, otherwise it won't link properly.
You can try to use curl-config --libs.
An alternate answer (the first one is excellent). Consider using the output returned by "pkg-config --libs libcurl" as an argument to your compiler.
For example,
CPPFLAGS=`pkg-config --libs libcurl`
g++ $CPPFLAGS myfile.o
Pkg-config is a standard way for open source libraries to communicate to you how to link against them / #include their files.
Anyone who is using ecplise CDT then you need to do following. First on terminal enter
curl-config --libs
On my machine, the result is
-L/usr/lib/i386-linux-gnu -lcurl
then do according to this screenshot and you will be able to compile. btw don't forget to add header files in your code
So you enter library folder path without -L and library name without -l because they will be automatically added by linker.
You have to link the library to your program. With gcc (and most other compilers) you can specify the libraries to link with -lname_wo_lib, e.g. -lcurl
Also see GNU GCC Manual - Options for Linking for a detailed explanation of the options Adam Rosenfield said. For standard search directories, see An Introduction to GCC - for the GNU Compilers gcc and g++ - Setting Search Paths.
In addition to the first answer, I had to link the curlpp library too. So to compile the main.cpp file which included the curlpp I had to do:
g++ main.cpp -lcurl -lcurlpp
Using only one of the two links would return different errors regarding different links. It is important to remind that this only worked because I had installed all the necessary libraries in the standard include folders