I've got an existing project written in C++ from my predecessor. He used CodeBlocks as an IDE.
I never used this IDE and hardly programmed any C++. He used the tinyxml library, so I added it to the project.
When I try to build it, the build log says something like this:
g++.exe -Wall -fexceptions -DBOOST_THREAD_USE_LIB=1 -D_WIN32_WINNT=0x0501
-Wall -IC:\somepath\boost_1_74_0 -Iinclude -Isrc -IZ:\tinyxml
-c C:\project\AsyncSerial.cpp -o obj\Debug\AsyncSerial.o
Question:
Where is -Isrc -IZ:\tinyxml defined? I don't have any Z:-drive and want to define my own path to the library.
I searched inside the settings and project setup, but didn't find anything like that.
Edit: same goes for:
g++.exe -LC:\somepath\boost_1_74_0\stage\lib -o bin\Debug\project.exe obj\Debug\AsyncSerial.o obj\Debug\main.o obj\Debug\tinyxml\tinystr.o obj\Debug\tinyxml\tinyxml.o obj\Debug\tinyxml\tinyxmlerror.o obj\Debug\tinyxml\tinyxmlparser.o -lws2_32 C:\Programme\boost\boost_1_48_0\stage\lib\libboost_filesystem-mgw46-mt-s-1_48.a C:\Programme\boost\boost_1_48_0\stage\lib\libboost_system-mgw46-mt-s-1_48.a C:\Programme\boost\boost_1_48_0\stage\lib\libboost_date_time-mgw46-mt-sd-1_48.a C:\Programme\boost\boost_1_48_0\stage\lib\libboost_program_options-mgw46-mt-sd-1_48.a C:\Programme\boost\boost_1_48_0\stage\lib\libboost_thread-mgw46-mt-1_48.dll.a C:\Programme\boost\boost_1_48_0\stage\lib\libboost_regex-mgw46-1_48.dll.a
Where does -lws2_32 value come from? I installed boost to the path specified in -L. My boost path was set in global variables and it's the only global variable that is shown.
Edit2:
for information: my path to boost is a relative path in the project folder, and definitely not in program files.
Added pictures of my settings:
Look for the include search directory configuration in
menue "Project"
entry "Build options ..."
tab "Search directories"
subtab "Compiler"
Linker search path nearby in subtab "Linker".
Config of libs to link in tab (not subtab) "Linker settings".
My CodeBlocks is 16.01, but that should not be too different whatever you use.
Quote of OP comment (to make this answer complete):
I found it, they where defined in the Debug/Release Linker settings.
Here "it" refers to the reason/location of the linker paths which did not match the config screenshots in the question.
Related
I am familiar with very simple g++ commands that compile and link programs, however when working with GTK+ I found the tutorial indicate that I should use pkg-config --cflags gtk+-2.0
Now when I type in pkg-config --cflags gtk+-2.0 to the terminal I get a list of libraries and files like this...
-pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/harfbuzz
So my question is, what does the -I mean in front of a directory? For example -I/usr/include/libpng12
The -I flag is used to add directories to the list of directories to search for finding files in #include <> statements.
In your case, when a file is included by using #include, /usr/include/libpng12 will be one of the directories in which the pre-processor will search for the file.
Please read the manual. All command line options are present there :-)
-I set the search path for libraries.
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
-I is simply adding to the paths to be searched for header files. Note that these are searched before system paths.
You can find pretty much all the options for gcc/g++ here. In this case, you want the Directory Search options specifically; see here. From that page:
-Idir
Add the directory dir to the head of the list of directories to be
searched for header files. This can be used to override a system
header file, substituting your own version, since these directories
are searched before the system header file directories. However, you
should not use this option to add directories that contain
vendor-supplied system header files (use -isystem for that).
If you use more than one -I option, the directories are scanned in
left-to-right order; the standard system directories come after. If a
standard system include directory, or a directory specified with
-isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal
position in the system include chain. This is to ensure that GCC's
procedure to fix buggy system headers and the ordering for the
include_next directive are not inadvertently changed. If you really
need to change the search order for system directories, use the
-nostdinc and/or -isystem options.
As the answers from #R Sahu #Klaus and #Yuushi explain, the -I dir tells the compiler where to look for the #include header.h file.
When the program is compiled, it will be linked. You will probably also need to tell the linker where to find the programs that support the functions in the #included headers. This is done with the -llibrary flag. That is a lower case l not a one (1).
The pkg-config command references a set of files and will supply the compiler flags --cflags and link flags --ldflags if you supply the package name.
Put the returned -Includes before the source name(s) and the -l's after in your compile command request.
For other than casual, one-off programs, you should use make. The cflag and ldflag info can be put in variables in the Makefile and referenced throughout your make script.
You can get a complete list of packages configured to pkg-config on your Ubuntu system with locate *.pc
When compiling with MinGW, I have to copy over certain dll files from the MinGW bin directory before the exe will run (Even when using "-static" and/or "-static-libstdc++".)
How do I change that? Is there a special build of MinGW that I have to use? Ultimately I want to be able to run the program with nothing but the exe in the directory (and no windows environment variables set.) These File's are:
libstdc++-6.dll
libgcc_s_seh-1.dll
libwinpthread-1.dll
And here is the complete list of step's I fallow:
Open Up Code::Blocks
Select "File->New->Project->Console"
Fill out the project settings for project "Hello World"
Right click Project->Build Options...->Hello World (Root target)->Other Options
Enter "-static" (or "-static-libstdc++") under the already set "-fexceptions"
CTRL-F9 : Build Project (Without executing)
Navigate to, in Windows Explorer, and run the built "Hello World.exe" file.
Click "OK" when a message pop's up saying "Error: libstdc++-6.dll is missing from your computer."
Copy "libstdc++-6.dll" from the /MinGW/bin/ directory, into the "Hello World.exe" directory.
Run "Hello World.exe"
Click "OK" for the message saying "Error: libgcc_s_seh-1.dll is missing from your computer."
Copy "libgcc_s_seh-1.dll" into the "Hello World.exe" directory.
Repeat and end up copying "libwinpthread-1.dll" over aswell.
View the message
Hello World!
Edit:
My command line is:
g++.exe -Wall -fexceptions -static -static-libgcc -static-libstdc++ -g -static-libgcc -static-libstdc++ -L. -c "C:\Users\______\Desktop\Hello World\main.cpp" -o obj\Debug\main.o
g++.exe -o "bin\Debug\Hello World.exe" obj\Debug\main.o
With all the dll files mentioned above required. And, just to be safe, the code is:
// main.cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
Your commands are wrong !
Go to the directory where your main.cpp file is, and try the following.
g++.exe -Wall -c -g main.cpp -o obj\Debug\main.o
g++.exe -static -static-libgcc -static-libstdc++ -o "bin\Debug\Hello World.exe" obj\Debug\main.o
then you'll no longer need to copy the DLLs (for your Hello World program).
Other notes:
The MinGW installation instructions recommends setting
c:\minGW;c:\MinGW\bin;
to the PATH environment variable.
Normally the
-static -static-libgcc -static-libstdc++
linker options should work (try all 3 of them at once). But not for libwinpthread-1.dll.
Also, try to clean before recompiling.
There's no "-static-something" command.
Only standard libraries libgcc and libstdc++ can be set to static linking.
For other libraries, you first switch to static linking with "-static" and then list the libraries to include with separate commands, i.e. "-lpthread".
Cmake users should try adding:
set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstdc++ -lwsock32 -lws2_32 ${CMAKE_CXX_STANDARD_LIBRARIES}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive")
-static-libgcc may be a bad idea if exceptions are used. link options documentation states that
There are several situations in which an application should use the
shared libgcc instead of the static version. The most common of these
is when the application wishes to throw and catch exceptions across
different shared libraries. In that case, each of the libraries as
well as the application itself should use the shared libgcc.
The comments to the answer above contain the full solution, so I would like to merely add the CodeBlocks perspective. I verified it on Windows7 x64 with CodeBlocks16 and MinGW-W64 8.1.0 ''i686-posix-dwarf''.
This solves the OPs question
Create new project and name it "Hello World"
accept all defaults in the wizard
select Project/BuildOptions/ and select "Hello World". Out edits will be valid for both Debug and Release
add the following at "Other linker option" in the "Linker" Tab
-static
-static-libgcc
-static-strc++
-lwinpthread
On the Toolbar select "Debug" and press Build (the yellow gear icon)
Press the green run icon and confirm that the build was ok
Testing
open a terminal window and go to the HelloWorld\bin\debug folder
start hello world there.
Confirm it works without asking for any DLLs.
You could also start it from an explorer window and confirm that it also does not ask for DLLs.
Note: On my Win7x64 system when starting the HelloWorld.exe from the explorer adding the "-lwinpthread" line causes CodeBlocks to ignore the setting in "Projects/Properties/Tab_BuildTargets/ "Pause when execution ends". So the "Hello World" output is hardly visible because the window immediately closes after execution (mabye someone knows why)
Note that if you do not have the winpthread.dll not found problem of the OP then you likely do not use a MinGW-W64 compiler with a 'posix' thread model. Both Code blocks MinGW-W64-bundled install packages use such versions. For CB20.03 the relevant downloads from MinGW-W64 download page would be
32bit: 8.1.0 ''i686-posix-dwarf''
64bit: 8.1.0 ''x86_64-posix-seh''
For example if I set setup compilers with Codeblocks direcly and chose the 32-bit compiler package ''i686-win32-dwarf'', only the first 2 DLLs would go missing. In that case the fix is to set the linker options only to
-static-libgcc
-static-strc++
I am using Windows 7, Code::Blocks and MinGW. I have little to no experience when it comes to compiling/building anything, especially when Code::Blocks doesn't use makefiles.
I downloaded SDL2-devel-2.0.0-mingw.tar.gz (SDL Development Libraries) from http://www.libsdl.org/tmp/download-2.0.php, and I'd like to create a standalone executable using SDL2 libraries, but so far I've always had to bundle the SDL2.dll file with the executable to make it work.
I've heard that I can not static-link dynamic libraries, so my only option seems to be doing something with the source files using the file SDL2-2.0.0.tar.gz (Source Code) from the link I mentioned above. However, I do not know what I should do with those.
What I managed to try with the source files is importing the Visual Studio project to Code::Blocks and building it, but it tells me "sdl-config No such file or directory" (I do not know what triggered that). I'm also not sure if building merely gives me an executable, with which I do not know what I can do to link it to my own executable.
A fool proof idiot's step by step guide would be the best bet to solve this case.
EDIT:
I managed to compile the SDL libraries with the guide Jonas provided, and got a libSDL2.a file.
At first I only added the path of libSDL2.a to "Link libraries:" -section of Code::Blocks, but I got a bunch of errors such as "SDL_Init() not declared in this scope".
In addition to the libSDL2.a path, I also added the path of SDL2-2.0.0\include to the Compiler's search directory as well as the path of SDL2-2.0.0\build.libs to the Linker's search directory. I also wrote this to my test file: #include "SDL.h". My test file now looks like this:
#include "SDL.h"
int main( int argc, char* args[] ) {
//Start SDL
SDL_Init( SDL_INIT_EVERYTHING );
//Quit SDL
SDL_Quit();
return 0;
}
It appears it did fix the declaration problem, but now Code::Blocks opened a SDL_mmjoystick.c file and gave me even more errors: "undefined reference to 'waveInClose#4'", "undefined reference to 'waveOutClose#4'", "undefined reference to 'joyGetNumDevs#0'" and tons of other ones.
Here's a screenshot of what's happening, note the different color of #include texts, I'm not sure why that happens: http://gyazo.com/00656a9c1e57a2bd0db1414fa7d68ced.png
I am not sure how to correctly take this library into use. Any help in this case, or should I make another question for it?
EDIT:
I added -lSDL2 to the linker options and deleted the other parameters. Now it builds fine:
mingw32-g++.exe -Wall -fexceptions -g -IC:\Users\User\Desktop\SDL2-2.0.0\include -c "C:\Users\User\Desktop\CppProjects\SDL project\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe -Wall -fexceptions -g -IC:\Users\User\Desktop\SDL2-2.0.0\include -c "C:\Users\User\Desktop\CppProjects\SDL project\thetestfile.cpp" -o obj\Debug\thetestfile.o
mingw32-g++.exe -LC:\Users\User\Desktop\SDL2-2.0.0\build\.libs -o "bin\Debug\SDL project.exe" obj\Debug\main.o obj\Debug\thetestfile.o -lSDL2 ..\..\SDL2-2.0.0\build\.libs\libSDL2.a C:\Users\User\Desktop\SDL2-2.0.0\build\.libs\libSDL2.a -mwindows
Output size is 945.80 KB
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings (0 minutes, 1 seconds)
But when I try to run it, it says my computer lacks SDL2.dll, while the whole point was to static-link.
So currently I have the path to build/.libs in my Link libraries -settings, -lSDL2 in the Other linker options, and for search directories I have the path to SDL2-2.0.0/include for the compiler and SDL2-2.0.0/build/.libs for the linker.
In the build/.libs directory I can also see libSDL2.a, libSDL2.dll.a, libSDL2.la and libSDL2.lai files, which I don't know what they are.
It's not necessary to recompile the library,
SDL2 is given with static-link library named "libSDL2.a"
on the folder "SDL2-2.0.0\i686-w64-mingw32\lib\".
Just be sure to add these options to the linker :
"-lmingw32 -lSDL2main -lSDL2 -mwindows -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -static-libgcc"
on Code:Blocks at "Project / Build Options... / Linket settings / Other linker options"
These options allow you to link with what SDL2.dll was using.
You can retreive them on the file "SDL2-2.0.0\i686-w64-mingw32\bin\sdl2-config"
The magical trick is to delete or rename the file "libSDL2.dll.a"
on the folder "SDL2-2.0.0\i686-w64-mingw32\lib\".
I added a "-" before to keep it in case I need it.
I don't know why this librairy overcomes the other and a clue would be appreciated.
I tried with Code::Blocks 12.11 MinGW32 and it worked.
If you run with some projects that use dynamic-link
and some other which use static-link, you will have to
keep your librairies in two different folders knowing that
"libSDL2main.a" will be in those two.
Sorry for my writing, I'm not used to write in english.
Mike
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 want to add a dynamic configuration path (generated from pkg-config) to my project. (this is basically for third-party dependencies like boost, so workspace includes is not appropiate, and filesystem include neither because that would be hardcoded and every developer would have to change that manually)
i am on project properties->c++ general->paths and symbols->includes tab->add...->add directory path->variables but i can only select among existing variables, how do i create a new variable dynamically generated from a command line program? like pkg-config --cflags boost-1.43?
this is easy to do in netbeans; you just add the pkg-config commandline with the backquotes in the build additional options and it resolves the build include and even in theory it should update the indexer (although truth be said, last time the indexer was correctly updating from pkg-config was on netbeans 6.8, it has been broken on 6.9 and 6.9.1)
i read this StackOverflow post but i still not sure how it helps this specific case
i read somewhere that you can use $(shell pkg-config...) to generate environment variables but not sure where to place the command
if there is no easy out of the box solution i'll try the script in this blog post
btw, i'm using eclipse helios -cdt 7
thanks!
Pkg-config support is finally coming to CDT and will be finished on August.
http://code.google.com/p/pkg-config-support-for-eclipse-cdt/
you can use $(shell pkg-config --cflags your_libs) in:
Project properties->C/C++ Build->Settings->"Tools Settings" tab->**C Compiler**->Miscellaneous->Other Flags
and
you can use
$(shell pkg-config **--libs** your_libs)
in
Project properties->C/C++ Build->Settings->"Tools Settings" tab->**C Linker**->Miscellaneous->Other Flags
if the linker doesn't link, make sure (for example in the build console window) that the pkg-config flags appear after the objects to link.
you can do this in properties->C/C++ Build->Settings->"Tools Settings" tab->C Linker->Command line pattern moving ${FLAGS} to the end :
from this (for example) :
${COMMAND} **${FLAGS}** ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} **${INPUTS}**
to this :
${COMMAND} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} **${INPUTS} ${FLAGS}**
In eclipse 4.3.2 at least, it looks as though it's possible to simply add
`pkg-config --libs <mylibname>`
in
Project->Properties->C/C++ Build->Settings->GCC {C|C++} Linker->Miscellaneous->Linker Flags
similarly
`pkg-config --cflags <mylibname>`
in
Project->Properties->C/C++ Build->Settings->GCC {C|C++} Compiler->Miscellaneous->Other Flags
what i found so far is that you can do
project-> properties-> c++ build-> build variables
add a new variable of string type.
Call it whatever you like:
UNITTEST_CPP_CXXFLAGS
then set as its value:
$(shell pkg-config --cflags unittest-cpp)
the go to project properties-> c++ general -> path and symbols,
includes.
Select languages c++, otherwise it defaults to assembly source file.
Click add.
On the add directory path, click variables... (because we want to add the variable we have just created)
type the name of the variable (UNITTEST_CPP_CXXFLAGS), press enter and ok
when you rebuild the result of the shell command is replaced in a -I option (for the gnu gcc toolchain at least), in general pkg-config output might include one or more -I so this won't work. Lets go to c++ build->settings->tool settings->gcc c++ compiler->miscellaneous. In there, add ${UNITTEST_CPP_CXXFLAGS} to the other flags.
now the include will be added, but there is no hope of getting the indexer to browse those include!
Use this link at eclipse help/install new spftware. It installs pkg-config. https://raw.githubusercontent.com/TuononenP/pkg-config.p2/master/site.xml
I did find this link in this webpage. https://groups.google.com/forum/#!topic/pkg-config-support-for-eclipse-cdt/HNblZRTKBQQ