After having downloaded the development library for SDL2 and attempting to link it with the -lSDL2 command in gcc, I am told that the library can not be found. Is there a specific directory i should place the framework in ? Or can I specify the directory in the command line so it knows where to link it from?
You use the -l (lower-case L) to tell the linker to link with a specific library.
You use the -L option to tell the linker about which folders to search for libraries.
So if you have install SDL2 in a non-standard location, use the -L option to specify where the library is installed, just like you use the -I (capital i) to specify where headers are for the preprocessor to find them.
If you have not placed it within one of the standard paths where to search for libraries, you should set and export a correctly defined LD_LIBRARY_PATH/LIBRARY_PATH variable.
This discussion contains enough information.
Related
With mingw-w64 version 4.9.1, installed with the MSYS2 installer, I'm building a DLL and linking it to ws2_32.dll using the -lws2_32 option. But mingw-w64 can't find ws2_32.dll under that name:
*** Warning: linker path does not have real file for library -lws2_32.
If I go into C:\Windows\system32 and copy ws2_32.dll to libws2_32.dll, then mingw-w64 can find it. This seems like a bad hack, however. I tried -l:ws2_32 since I read that the ":" has special meaning, but that made no difference.
How can I tell mingw-w64 to link to a Windows DLL whose name does not begin with lib?
Have you tried fore-going the -l option?
Just
gcc -LC:\Windows\system32 herpmytargetcodederp.c ws2_32.dll
Items fed into gcc are either object files or libraries. The -l option is just a common way of linking in commonly used things a little easier. The old farts were terse. -lm instead of typing out -L/path/to/lib libmath.o
Include the path for the linker to find it with -L and call it by name.
you do not link to the DLL itself, but to the library that defines the dll exports (libws2_32.a), check in your MingW (\lib) directory if libws2_32.a exists.
Is there anyone that can give me a simple run down of how to install the GSL library so that it'll work with XCode (5.1) on a Mac (Mavericks, 10.9)? I keep getting this error:
Undefined symbols for architecture x86_64:
"_gsl_matrix_add", referenced from:
_myProject in main.o
I initially installed GSL 1.16 in /Library/gsl-1.16
I did the whole ./configure, make, and make install
THINGS I HAVE TRIED TO FIX THIS:
1) Going to "Build Settings" in XCode and adding "/Library/gsl-1.16"
to both the library and header search paths
2) Creating a symbolic link from the ...usr/include path (... being the SDK (MacOSX 10.9) location XCode is using) to the Library path.
3) Adding "-lgsl" to the "Arguments passed on Launch" section of my project's scheme
4) Adding "-Wall -I/Library/include" to the "Arguments passed on Launch" section of my project's scheme
Nothing has worked. Xcode reports that it can find the headers, but it can't reference the methods associated with the header files. Truly interesting. I have no idea, I've done everything I can think of and Google.
From your description it is difficult to locate whether you set the build settings correctly. I installed GSL using macports and not sure how it would be like if installed directly from source. But I believe you need to figure out where the make install installs the GSL library and header to, since typically they are installed into different paths, which are not the path you run make install.
And since typically make install will install headers to /usr/local/include and libraries to /usr/local/lib, I guess it is possible that you set the wrong path to the libraries. Assume you figured out that your GSL library is in /usr/local/lib (and typically they should), you just need to do one of the two things (not both):
Change Library search path to /usr/local/lib. (and header search path to /usr/local/include as you did)
Change compiler arguments to -Wall -I/usr/local/include -L/usr/local/lib. (last two arguments start with capital i and capital L).
Here is the procedure how I install GSL using macports and set up it in Xcode to run a matrix addition:
Install macports if you haven't done it. Refer to https://www.macports.org/install.php .
In terminal, type sudo port install gsl and have several cups of coffee.
By default, macports installs librarys to /opt/local/lib and headers to /opt/local/include. So after you create a C++ project in Xcode, go to build settings, add the three settings below:
Library search paths: /opt/local/lib
Header search paths: /opt/local/include
Other linker flags: -lgsl (depending on what you want to do, you may also need to add -lgsl -lgslcblas and other flags.)
Now it is up and running. Include <gsl/gsl_matrix.h> and gsl_matrix is ready to use.
I need to use a C library to access and older file format used by a legacy application. The library I installed was libdbf. (Did ./configure && make && make install). It was installed under /usr/local/lib:
libdbf.0.0.1.dylib
libdbf.0.dylib
libdbf.a
libdbf.dylib
libdbf.la
I'm loosely familiar with C syntax and have done some very trivial things in C and C++, but don't know how to include the library.
How can I include this library in my project? Sorry for the noobie question.
When you compile your project use -ldbf
The -l means link, and the dbf is the name of the library (you don't need to include the lib part of the name).
Edit:
I haven't used Qt, but it looks like you can add
unix:LIBS += -ldbf
To your .pro file. Sources 1, 2
By default, gcc will look in /usr/local/include for the headers and in /usr/local/lib for the library. In case it you need to make it explicit, you can also add:
-I/usr/local/include -L/usr/local/lib
If you'd like to compile your project with symbols exported by the library you have to add -I /usr/local/include, assuming that the headers were properly installed. For linking you'll need to add -L /usr/local/lib -ldbf. You can also pass the path to the library explicitly, so instead of -L /usr/local/lib -ldbf add /usr/local/libdbf.0.dylib.
See GCC's linking options.
I have a collection of dynamic libraries that I want to link to in /usr/local/lib, how can I do this using gcc without setting my LD_LIBRARY_PATH (i have heard it is bad to do this fora number of reasons).
I have spent an hour looking at this on the internet, and fiddling with command line arguments, the only way I got it to work was using the -static -I/usr/local/lib/ flag, but this converts dynamic libraries to static libraries, and the compiler throws up some warnings.
Thanks for your help
Add /usr/local/lib to the loader configuration in /etc/ld.so.conf and run ldconfig.
You can set the system wide search directories for ldd (the dynamic linker) in /etc/ld.so.conf. In many distributions (well, mine) there is a /etc/ld.so.conf.d/ directory, from which the /etc/ld.so.conf includes all *.conf files. You can add the directory directly in ld.so.conf or add a .conf file in the directory.
Of course, you'll need root access to do this.
Oh, yeah: as Ignacio says, run ldconfig after changing these config files.
I'm sure this question has been asked many times, but I can't figure this out. Bear with me.
So when you download a library, you get a bunch of .c and .h files, plus a lot of other stuff. Now say you want to write a program using this library.
I copy all the .h files into my project directory. It just doesn't compile.
Great, so then I get the library as a bunch of .dll's, and i copy the dlls into my project directory. Still doesn't compile.
How does this work?
What do you do, like right after creating the folder for your project? What parts of the library package do you copy/paste into the folder? How do you make it so that it can compile? Go through the steps with me please.
Where to put the .h files?
Where to put the .dll files?
How to compile?
Thanks.
(the library I'm trying to get working is libpng, I'm in windows with MinGW, and i'm looking to compile from command-line like usual.)
(from what i gather, you put the .h files in directory A and the .dll files in directory B and you can use -l and -L compiler options to tell the compiler where to find them, is this correct?)
Here's a brief guide to what happens when you compile and build a basic C project:
The first stage compiles all your source files - this takes the source files you've written and translates them into what are called object files. At this stage the compiler needs to know the declaration of all functions you use in your code, even in external libraries, so you need to use #include to include the header files of whatever libraries you use. This also means that you need to tell the compiler the location of those header files. With GCC you can use the -I command line to feed in directories to be searched for header files.
The next stage is to link all the object files together into one executable. At this stage the linker needs to resolve the calls to external libraries. This means you need the library in object form. Most libraries will give you instructions on how to generate this or might supply it ready built. Under Linux the library file is often a .a or .so file, though it might just be a .o. Again you can feed the location of the library's object file to GCC with the -L option.
Thus your command line would look like this:
gcc myProg.c -I/path/to/libpng/include -L/path/to/libpng/lib -lpng -o myProg.exe
(Note that when using the -l command line GCC automatically adds lib to the start of the library, so -lpng causes libpng.a to be linked in.)
Hope that helps.
Doing it under windows (supposing you user Visual Studio)
After unpacking add the library include directories to your projects' settings (Project -> Properties -> C/C++ -> Additional Include Directories)
Do the same thing for the Libraries Directory (Project -> Properties -> Linker -> Additional Library Directories)
Specify the name of the library in your Linker Input: Project -> Properties -> Linker -> Input -> Additional Dependencies
After this hopefully should compile.
I don't recommend adding the directories above to the Global settings in Visual Studio (Tools -> Options -> Project and Solutions) since it will create and environment where something compiles on your computer and does NOT compile on another one.
Now, the hard way, doing it for a Makefile based build system:
Unpack your stuff
Specify the include directory under the -I g++ flag
Specify the Library directory under the -L g++ flag
Specify the libraries to use like: -llibrary name (for example: -lxml2 for libxml2.so)
Specify the static libraries like: library name.a
at the end you should have a command which is ugly and looks like:
g++ -I/work/my_library/include -L/work/my_library/lib -lmylib my_static.a -o appname_exe MYFILE.CPP
(the line above is not really tested just a general idea)
I recommend go, grab a template makefile from somewhere and add in all your stuff.
You must link against a .lib or something equivalent i.e. add the ".lib" to the libraries read by the linker. At least that's how it works under Linux... haven't done Windows so a long while.
The ".lib" contains symbols to data/functions inside the .dll shared library.
It depends on the library. For examples, some libraries contain precompiled binaries (e.g. dlls) and others you need to compile them yourself. You'd better see the library's documentation.
Basically, to compile you should:
(1) have the library's include (.h) file location in the compiler's include path,
(2) have the library stubs (.lib) location in the linker's library path, and have the linker reference the relevant library file.
In order to run the program you need to have the shared libraries (dlls) where the loader can see them, for example in your system32 directory.
There are two kinds of libraries: static and dynamic (or shared.)
Static libraries come in an object format and you link them directly into your application.
Shared or dynamic libraries reside in a seperate file (.dll or .so) which must be present at the time your application is run. They also come with object files you must link against your application, but in this case they contain nothing more than stubs that find and call the runtime binary (the .dll or the .so).
In either case, you must have some header files containing the signatures (declarations) of the library functions, else your code won't compile.
Some 'libraries' are header-only and you need do nothing more than include them. Some consist of header and source files. In that case you should compile and link the sources against your application just as you would do with a source file you wrote.
When you compile, assuming you have the libs and the headers in the same folder as the sources you are compiling, you need to add to your compile line -L . -I . -lpng. -L tells the linker where to look for the library, -I tells the compiler where to look for the headers and -lpng tells the linker to link with the png library.
[Edit]
Normal projects would have some sort of hierarchy where the headers are in an /include folder and the 3rd party libs are in a /libs folder. In this case, you'd put -I ./include and -L ./libs instead of -I . and -L.
[Edit2] Most projects make use of makefile in order to compile from the command line. You can only compile manually for a small number of files, it gets quite hectic after that
Also,
you may want to look over Dynamic Loading support in various languages and on various
platforms.
This support is very handy in cases when you want to use a library optionally and you don't want your program to fail in case that library is not available.