====== Всё, что связано с C/C++ ======

  * [[habrahabr>250199|Что каждый программист должен знать про оптимизации компилятора]]
  * [[habrahabr>263939|Как мы провели пару дней, работая над ускорением Perl]]
  * [[habrahabr>267345|Блок-схема для выбора STL-алгоритма]]
  * [[habrahabr>267771|Нет ничего проще, чем вызвать функцию]] -- как же всё-таки осуществляется передача управления при возбуждении исключения?


===== C++ compiler / environment ======

  * [[http://cygwin.com/|CygWin]]: download ''[[http://cygwin.com/setup.exe|setup.exe]]'' and choose all you need. Don't forget to install ''bash'', ''make'' and ''gcc''.
  * [[http://www.mingw.org/|MinGW]]: download the latest installer from [[https://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/|here]] and select ''C Compiler'' and ''Developer Toolkit'' for installation.
  * [[http://www.openwatcom.org/|Watcom]]
    * Missed some STL functionality, e.g. ''std::stringstream'' classes (see [[http://bugzilla.openwatcom.org/show_bug.cgi?id=779|bug#779]])
  * [[http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express|Visual C++ 2010 Express]]
    * [[torrents>2827340|Visual C++ 1.52c compiler]]
  * [[http://www.vtk.org/Wiki/CMake|CMake wiki]]

  * [[http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf|Short gdb manual]]
  * [[http://vim.wikia.com/wiki/All_tips_for_C_family_programming|All vim tips for C family programming]]
  * [[https://debugging.works/blog/analyzing-linux-coredump/|How to analyze a core dump on Linux]]


===== Questions answered ======

=== I have got a warning ''dpkg-shlibdeps: warning: symbol XXX used by libfoo.so.0 found in none of the libraries.'' ===

<note tip>
That means that the library ''libfoo.so.0'' uses the symbol ''XXX'', but this symbol was not found in dependencies for this library. It looks like there is a dependency chain //A -> B -> C//, where //A// (''libfoo'') uses symbols from //C//. In this case introducing a new direct dependency //A -> C// will fix the warning.
</note>


=== How to check that dynamic library was compiled with ''[[wp>Position-independent code|-fPIC]]'' ===

<note tip>
If ''readelf'' from ''binutils'' package outputs ''TEXTREL'' section, then some code was compiled without ''-fPIC'':
<code>
$ readelf -d libtest.so | grep TEXTREL
 0x00000016 (TEXTREL)                    0x0
</code>

Run ''eu-findtextrel'' from ''elfutils'' to see the violating symbols and pipe to ''scanelf'' from ''pax-utils'' to find library containing that symbol:

<code>
$ eu-findtextrel libtest.so | sort -u | perl -ne 'while (<>) { while (/the function \x27(\w+)\x27/g) { print "$1\n"} }' | while read i; do scanelf -l -A -s $i | grep $i; done
</code>

References:
  * [[stackoverflow>1340402|How can I tell, with something like objdump, if an object file has been built with -fPIC?]]
  * [[https://lists.debian.org/debian-devel/2014/12/msg00359.html|Find out what symbols in dynamic library have not been compiled with -fPIC]]
  * [[http://unix.stackexchange.com/questions/103744/find-where-is-a-shared-library-symbol-defined-on-a-live-system-list-all-symbol|]]
</note>


=== Linking with ''%%-Wl,--as-needed%%'' flags causes unresolved symbols ===

<note question>
When compiling the following test program:
<code cpp>
#ifdef __cplusplus
extern "C"
#endif
char pnm_readpnminit();
int main()
{
	return pnm_readpnminit();
}
</code>
the following error is produced:
<code console>
# g++ -o conftest -g -Wl,--as-needed conftest_orig.cpp -lnetpbm -lm
/usr/lib64/libnetpbm.so: undefined reference to `log'
/usr/lib64/libnetpbm.so: undefined reference to `pow'
collect2: ld returned 1 exit status
</code>
</note>
<note tip>
  * With ''%%-Wl,--as-needed%%'' the linker will ignore all libraries, from which no symbols are used by current module. ''-lm'' was ignored and that caused the mentioned error message.
  * It also means that libnetpbm.so was incorrectly linked as it should depend on ''libm''. However it does not.
  * If ''libnetpbm.so'' is correctly linked, ''%%-Wl,--as-needed%%'' will not break the test anymore (and one don't need to pass ''-lm'').

See also [[debian>ToolChain/DSOLinking|DSO Linking]].
</note>


=== I would like to have two target binaries for my project: dynamically linked and statically linked. How can I do it? ===

<note tip>
Currently here are two subsystems, that can automate static linking process:
  * [[http://www.gnu.org/software/libtool/manual/|libool]]
  * [[http://pkg-config.freedesktop.org/wiki/|pkg-config]]

pkg-config is much superior to libtool, since libtool includes all the libraries on dynamic links as well, which creates unwanted shared library dependencies and causes other problems. pkg-config has some intelligence, i.e. if you request two libs at once it will nuke duplicate flags and order the ''-l'' flags properly. Also, it can gripe about missing dependencies or conflicting libraries. Note that pkg-config merges at query-time: if ''gtk+.pc'' file contains ''CFLAGS'' that are specific to that library, ''pkg-config --cflags gtk+'' also outputs ''CFLAGS'' for all dependencies of ''gtk+''.

See also:
  * [[stackoverflow>3932742#4178935|Static library auto-discovery and linking]]
  * [[http://www.mail-archive.com/libtool@gnu.org/msg01592.html|Libtool and Pkg-Config]]
  * [[http://lists.debian.org/debian-devel/2010/11/msg00429.html|Static linking: pkgconfig vs libtool]]
  * [[http://www.trilithium.com/johan/2005/06/static-libstdc/|Linking libstdc++ statically]]:
    <code console>
ln -s `g++ -print-file-name=libstdc++.a`
g++ -static-libgcc -L. -o example example.cpp
</code>
</note>


=== When I install MinGW I got the error(s) '' Get package: XXX download failed'' ===

<note question>
Installation reports errors like following:
<code>
C:\MinGW\bin\mingw-get.exe: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/openssl-1.0.0-1-msys-1.0.13-bin.tar.lzma?download: download failed
C:\MinGW\bin\mingw-get.exe: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/libiconv-1.13.1-1-mingw32-dll-2.tar.lzma?download: download failed
</code>
</note>
<note tip>
Try to re-run the installation for failed packages again:
<code>
mingw-get.exe install libiconv
mingw-get.exe install msys-openssl
</code>
</note>


=== What compiler option needs to be checked for CygWin / MinGW compiler? ===

<note tip>
For CygWin use ''__CYGWIN__'' and and mingw use ''__MINGW32__''.

So the conditional check for any other Win32 compiler will be:

<code cpp>
#if defined(_WIN32) && !defined(__CYGWIN__) && !defined(__MINGW32__)
#include <windows.h>
#endif
</code>
</note>


=== Cygwin/MinGW linker adds ordinals after the DLL export symbols. How to remove them, as I get ''java.lang.UnsatisfiedLinkError''? ===

<note question>

<code console>
$ g++ -shared cpp_wrap.o -o libmy_java.so
$ nm libcrfpp_java.so | grep CRFPPJNI_VERSION
64303a43 T _Java_org_chasen_crfpp_CRFPPJNI_VERSION_1get@8
</code>
What should I do to remove ''@n'' (e.g. get ''_Java_org_chasen_crfpp_CRFPPJNI_VERSION_1get'')?
</note>
<note tip>
From [[http://www.willus.com/mingw/yongweiwu_stdcall.html|here]]:

^ Calling Convention 	^ Internal 		^ MSVC DLL (w/ DEF) 	^ MSVC DLL (dllexport) 	^ DMC DLL 		^ MinGW DLL 	^ BCC DLL	^
| ''%%__stdcall%%''		| _function@n 	| function 				| _function@n 			| _function@n 	| function@n 	| function	|
| ''%%__cdecl%%'' 		| _function 	| function 				| function 				| function 		| function 		| _function	|

so you need to use ''__cdecl'' instead of ''__stdcall'' in function declaration:

<code cpp>
#ifdef __MINGW32__
#define JNICALL __cdecl
#endif
</code>

On the other hand, the [[http://sourceware.org/binutils/docs/ld/Options.html#Options|options]] ''-Wl,--add-stdcall-alias'' and ''-Wl,--kill-at'' [[http://www.inonit.com/cygwin/jni/helloWorld/c.html|should work]] [[http://www.swig.org/tutorial.html|just fine]], but [[http://forums.codeblocks.org/index.php?topic=4351.0|they don't]] in some cases.
</note>


=== ''jni_md.h'' refers the ''%%__int64%%'' type, which is unknwon for GCC compiler ===

<note tip>
Use the workaround use the following:
<code cpp>
#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
typedef long long __int64;
#endif

#include <jni.h>
</code>
or use ''%%gcc -D__int64="long long" ...%%'' (check [[http://maba.wordpress.com/2004/07/28/generating-dll-files-for-jni-under-windowscygwingcc/|Generating .dll files for JNI under Windows/Cygwin/GCC]] and [[http://rabbit-hole.blogspot.com/2007/03/building-w32-jni-dlls-with-gcc.html|Building w32 JNI DLLs with gcc]])
</note>


=== How to dump all preprocessor definitions? ===

<note tip>
Use ''%%g++ -dD -E -I... source.cpp%%''.
</note>


=== How to define verbosity in Makefile (control the messages to be displayed) ? ===

<note tip>
From [[stackoverflowa>9318570/267197|Controlling verbosity of make]]:

<code make|Makefile>
V = 0
CC_0 := @echo -t "Compiling $<..."; $(CC)
CC_1 := $(CC)
CC = $(CC_$(V))

%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@
</code>

Afterwards ''make V=0 ...'' will do the job.
</note>


=== How to enable STL support for ''gdb'' ''print'' command? ===

<note tip>
From [[http://sourceware.org/gdb/wiki/STLSupport|here]]:

  * Checkout Python scripts to ''~/.gdb/libstdcxx_printers'': ''cd ~/.gdb && svn co http://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python libstdcxx_printers''
  * Add to your ''~/.gdbinit'':
    <code>
python
import sys, os
sys.path.insert(0, os.path.expanduser('~/.gdb/libstdcxx_printers'))
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers(None)
end
</code>

</note>


{{tag>C++ cpp gdb vim}}