I have recently installed GCC 4.9.2 (port name gcc49) through MacPorts. I am quite happy with its new features such as colorized diagnostics and C++1y/C++14 support improvements, etc.
However, since I started to compile code using GCC 4.9.2, I realized that it is not generating debug symbol directory *.dSYM and gdb says "no debugging symbols found" when I try to debug a program I compiled with -g flag.
Is this a MacPorts specific bug or is there a problem with GCC 4.9?
Thanks
It is not a MacPorts specific issue. MacPorts doesn't really do much to customize the gcc ports.
If you want to create a dSYM bundle and strip your executable, you should just do something like:
gcc-mp-4.9 -g3 -c example.c
gcc-mp-4.9 example.o -o example
dsymutil --out example.dSYM example
strip -S -x example
As a side note, if you want C++11/C++14 support, I suggest you use the clang-3.5 port as that will allow you to use libc++ from the system instead of libstdc++ from MacPorts (and allow you to use system and MacPorts C++ libraries rather than just the STL). Also, lldb is really the preferred debugger for OS X these days.
Related
I'm using mingw-w64 (gcc 7.3.0) and when I compile any C++ program using the following command:
g++ file.cpp -fsanitize=undefined
I get the following error:
...mingw32/bin/ld.exe: cannot find -lubsan
I'm able to successfully compile and run my programs if I remove the -fsanitize=undefined flag, though. After some research I found out that this means the library ubsan (Undefined Behavior Sanitizer) is missing, but I couldn't find anything about the library. How do I fix this?
This is well known issue with mingw see for instance this msys github issue. No proper solution known but there are several WAs.
Install WSL, ubuntu over WSL and you will have ubsan inside it
Build GCC under Windows from source enabling sanitizers build. They are present in GCC sources they are just not here in mingw.
Use -fsanitize=undefined -fsanitize-undefined-trap-on-error to just not use libubsan rich logging capabilities but get it trap on undefined instruction.
Hope one of this helps.
I cannot include the hkdf.h from the crypto++ library into my code.
It says cryptopp/hkdf.h not found. Although I can import other parts from the same library into my code, such as cryptopp/sha.h
I am using the g++ with the -std=c++11 and the -lcryptopp flags
I looked into the docs and it suggested the -lcryptopp flag which I am using. This should not be an issue, am I missing something ?
Edit 1:
Compile command :
g++ -std=c++11 mycode.cpp -lcryptopp
Edit 2:
How do I check the version of my crypto++ library ?
Download command was:
sudo apt-get install libcrypto++-dev
My OS is Ubuntu 16.04
Compile command :
g++ -std=c++11 mycode.cpp -lcryptopp
This does not answer your question. It is just a heads up...
Be careful with g++ -std=c++11 mycode.cpp -lcryptopp. The library and your program have to be built using mostly the same options. I don't believe Debian uses -std=c++11, so you should not use it.
The "use mostly the same options" rule applies to all distros and all C++ libraries; and not just Crypto++ on Debian. You will encounter similar problems if you do the same with the PCRE library on Fedora.
You can check the flags Debian is using to build the library at Debian Package Auto-Building | Crypto++. The flags Debian uses are:
-DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 \
-fstack-protector-strong -Wformat -Werror=format-security \
-DCRYPTOPP_NO_UNALIGNED_DATA_ACCESS -DNDEBUG -fPIC -DPIC
For your purposes the important flags are -g -O2 -DNDEBUG -fPIC. Those flags are the ones you should use with your program. -DCRYPTOPP_NO_UNALIGNED_DATA_ACCESS is applied in the file config.h so you don't need to pass it on the command line. (Unaligned access was removed recently because it caused too many problems, so you don't even have to worry about -DCRYPTOPP_NO_UNALIGNED_DATA_ACCESS in the future).
You can use -std=c++11 if you like. However, you have to download and build the library yourself from sources to ensure the same flags are used by the library and your program.
If you build the library yourself then see GNUmakefile | Building the Library on the Crypto++ wiki.
If you build the library yourself then do yourself a favor and remove the distro provided version of the library. Something like sudo apt-get remove --purge libcrypto++ libcrypto++-dev libcrypto++-dbg. Otherwise you will inadvertently be mixing and matching them.
Cannot include the hkdf.h from the crypto++ library into my code.
It says cryptopp/hkdf.h not found.
HKDF was added at Crypto++ 5.6.3. Older versions of the library do not have it, like one supplied on Ubuntu 14 or CentOS 5.
It is a header-only implementation using the file hkdf.h. You can download it and drop it in the Crypto++ installation directory. Maybe something like the following for Crypto++ 5.6.3:
# Crypto++ 5.6.3
wget https://raw.githubusercontent.com/weidai11/cryptopp/217cb1f983c6/hkdf.h
sudo cp hkdf.h /usr/include/cryptopp/
The key derivation functions interface changed at Crypto++ 7.0. More correctly, at Crypto++ 7.0, we added a base class to use as the interface (previously there was none). The base class is KeyDerivationFunction, and it allowed us to improve self tests for the key derivation function classes. So maybe something like the following for Crypto++ 7.0:
# Crypto++ 7.0
wget https://raw.githubusercontent.com/weidai11/cryptopp/c8d8caf70074/hkdf.h
sudo cp hkdf.h /usr/include/cryptopp/
To summarize:
Crypto++ 5.6.3: you only need the file that supplies HKDF
Crypto++ 7.0: you need the files that supply both KeyDerivationFunction and HKDF.
Put another way, if you try to use Crypto++ 7.0 HKDF with Crypto++ 5.6.2, then it will never compile because KeyDerivationFunction is missing from the library.
This should not be an issue, am I missing something ?
I think your problem is probably dependent on your distro (or whomever is supplying Crypto++). We could say more if you provided details of the distribution and the library version they supply.
To hazard a guess... Debian and Fedora stay up to date with the Crypto++ releases. Or they have for the last several years. So you are probably not using Debian 8, Ubuntu 17, Fedora 22 or their respective variants.
However, you may be using Debian 7 or earlier, Ubuntu 12 or earlier, or Fedora 21 or earlier. In this case I believe you are using Crypto++ 5.6.2.
I believe Gentoo, the BSDs and some others are behind on the release curve. As far as I know, some distros are still providing Crypto++ 5.6.2.
Recently I have noticed that GCC does not generate object (*.o) files when compiling with '-c'. It does not issue any errors or warnings. I have run it with '-verbose' but it shows nothing out of the ordinary.
Running under Windows:
gcc -Wall -c source_file.c
I have also tried compiling with '-verbose' to display detailed information
gcc -Wall -verbose -c source_file.c
It should produce 'source_file.o' but it doesn't. Any idea what's going on?
The issue has been resolved. Reinstalling GCC (mingw) fixed the problem. It is possible the problem came about because I tried to install the 64-bit version of GCC (Mingw-w64) to top of the 32-bit version...
I am trying to install PARI/GP and in the configuration step I get:
$ ./Configure
[...]
Looking for the compilers ...
...cc is /usr/bin/cc
...gcc is /usr/local/bin/gcc
GNU compiler version 4.8.0 20120705 (experimental) (GCC)
###
### C compiler does not work. PARI/GP requires an ANSI C compiler! Aborting.
###
### Compiler was: /usr/local/bin/gcc
$ gcc --version
gcc (GCC) 4.8.0 20120705 (experimental)
This is strange because the documentation says:
"Only ANSI C and C++ compilers are supported. Choosing the GNU compiler
gcc/g++ enables the inlining of kernel routines (about 20% speedup; if you
use g++, it is a good idea to include the -fpermissive flag). If you choose
not to use gcc, the C++ version of Pari will be a little faster because of
general inlining, but can be used in library mode only with C++ programs.
We strongly recommand using gcc all the way through."
I have also tried with g++ with the same result.
I am trying to compile on a linux x86_64.
Any ideas?
Thanks in advance,
M;
The config/get_cc script in PARI's top level tried to compile a test program
and failed.
Look for the line
$CC $CFLAGS $extraflag -o $exe ansi.c 2>/dev/null && $RUNTEST $exe
and remove the 2>/dev/null. Configure should now print out explicit error
messages from the compiler. They should provide a hint.
I had the same problem. Here is the solution for Linux Mint 17.1 64-bit:
sudo apt-get install gcc libc6-dev libgmp-dev
This command also installs the GMP library (recommended for PARI/GP).
Thanks to K.B. for the hint on how to see the problem.
When linking my project in the release mode I am getting the following warning:
myProject-libs/release/libboost_regex-mt-s-1.50.0.a(cpp_regex_traits.o): duplicate section `.data$_ZZN5boost16cpp_regex_traitsIcE21get_catalog_name_instEvE6s_name[boost::cpp_regex_traits<char>::get_catalog_name_inst()::s_name]' has different size
I suspect that the cause could be that the boost library is compiled with different options than I use for my project, but I don't know how to find the difference (boost didn't output these options during the build).
In order to compile the boost for win32 on Ubuntu 12.04 I used this procedure:
tar jxf boost_1_50_0.tar.bz2
cd boost_1_50_0
./bootstrap.sh
echo "using gcc : 4.6 : i686-w64-mingw32-g++ : <rc>i686-w64-mingw32-windres <archiver>i686-w64-mingw32-ar ;" > user-config.jam
./bjam toolset=gcc target-os=windows --address-model=32 variant=release threading=multi threadapi=win32 link=static runtime-link=static --prefix=/opt/boost_1_50_0-release-static-windows-32 --user-config=user-config.jam -j 10 --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged install
In order to compile files in my project I use something like
i686-w64-mingw32-g++ -march=corei7 -mfpmath=sse -m32 -Wall -fmessage-length=0 -I"/opt/boost_1_50_0-release-static-windows-32/include" -std=c++0x -O3 -g0 -DNDEBUG -I"myProject/src/cpp" -c -o myProject/build/release/src/cpp/myproject.o myproject/src/cpp/myproject.cpp
The tests I have indicate that the regexps run fine but still I would like to resolve the warning.
EDIT
I found that additional options to the boost compiler can be added using a cxxflags= argument of bjam.
Example:
bjam cxxflags='-fPIC' ....
Maybe making sure to pass the same arguments as I do to the project could resolve the problem (particularly the arguments related to optimizations as suggested in the linked question).
Your compilers were compiled with different options :) Compiling the library on Linux and the program on Windows result in a situation where there is an identically named .data segment, but they aren't the same size. That could theoretically be interesting, inasmuch as a data segment is writable, but in practice, it shouldn't matter. Unless there is evidence to suggest this causes a problem of which I'm not aware, you can safely suppress that warning; I don't know how you'd make it go away, though.
I recently encountered this problem (i.e. linker warning "duplicate section has different size") when trying to compile boost for Windows using mingw.
The issue I had was that I compiled my application with -std=c++14 but when compiling boost I didn't specifically provide a dialect flag (which defaulted to -std=c++98 for g++ 5.3.0). Adding the dialect flag -std=c++14 when compiling boost solved the problem for me. See this answer for an explaination on how to set cxxflags when compiling boost.
I believe my solution might have worked for you (your application was compiled with -std=c++0x but boost was not provided any dialect flag). Although I am 6 years too late, I'll leave my answer here for others who happen to stumble-upon this issue.