I'm a bit of an AIX newbie. I'm trying to compile a program using gcc's stack protector feature. I installed gcc on server using pware's GCC package and I can compile a sample program like:
#include <stdio.h>
int main(int argc,char **argv)
{
printf("hello world\n");
return 0;
}
When I turn on stack-protector though, I get:
g++ -fstack-protector-all main.cpp
collect2: library libssp_nonshared not found
I've been hunting on google for a solution to this and it seems like my libc needs to have some stuff built into that mine doesn't. Is there a package out there that includes a libc with the stack protection builtin?
g++ -v returns
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../stage/gcc-4.2.4/configure --disable-shared --enable-threads=posix --prefix=/opt/pware --with-long-double-128 --with-mpfr=/opt/pware --with-gmp=/opt/pware
Thread model: aix
gcc version 4.2.4
I can not find libssp_nonshared.a on the system -- is there an additional package I need to install or should it have come with the gcc package?
This has nothing to do with libc: your GCC installation is missing libssp_nonshared.a library.
What does your "gcc --version" say? It may have been configured with --disable-libssp option (in which case you can't use the stack protection instrumentation).
Update:
I just looked in gcc-4.3.0/configure:
powerpc-*-aix*)
noconfigdirs="$noconfigdirs gprof target-libgloss target-libssp ${libgcj}"
;;
I am about 99% sure this means that libssp (and therefore -fstack-protector) is not available for your platform. Sorry :-(
Related
I have compiled mpich 3.2 with gcc 4.8.3 on centos. Everything seems to be fine. Then I wrote a simple test program,
#include "mpi.h"
int main(int argc,char **argv)
{}
and use the mpic++ to compile. Then errors return,
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strncmp'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memset'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strlen'
What exactly goes wrong? I'm so confused that the error seems to be related with intel compilers, but I use gcc to compile mpich by the command,
./configure --prefix=/home/setups/mpich-3.2/build/ CC=gcc CXX=gcc F77=gfortran FC=gfortran
I have added /home/setups/mpich-3.2/build/bin to PATH and /home/setups/mpich-3.2/build/lib to LD_LIBRARY_PATH
mpicc -v shows：
mpicc for MPICH version 3.2
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/setups/gcc-4.8.3/build/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/setups/gcc-4.8.3/build --with-gmp=/home/setups/gmp-6.1.2/build --with-mpfr=/home/setups/mpfr-3.1.5/build --with-mpc=/home/setups/mpc-1.0.3/build --disable-multilib
Thread model: posix
gcc version 4.8.3 (GCC)
You might find your solution at the open-mpi.org site and their faq for building MPI. For example, item 17.
A common mistake when building Open MPI with the Intel compiler suite
is to accidentally specify the Intel C compiler as the C++ compiler.
Specifically, recent versions of the Intel compiler renamed the C++
compiler "icpc" (it used to be "icc", the same as the C compiler).
Users accustomed to the old name tend to specify "icc" as the C++
compiler, which will then cause a failure late in the Open MPI build
process because a C++ code will be compiled with the C compiler. Bad
Things then happen. The solution is to be sure to specify that the C++
compiler is "icpc", not "icc". For example:
https://www.open-mpi.org/faq/?category=building
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
This strongly suggests an Intel compiler was used to build mpich.
That can happen is gcc/g++/gfortran is not in your PATH or if your environment points to the Intel compiler (e.g. CC=icc or CXX=icpc or FC=ifort).
How can I force the gcc linker to link against a given version (soname) of a shared library on the system?
I need this to enforce that the version of openssl that is #include'ed matches the version that is linked, on any system, even if multiple versions of openssl are installed. To find the ABI version, my configure script first compiles and runs a program that extracts the SONAME from the headers:
#include <openssl/opensslv.h>
#include <stdio.h>
int main () {
printf(SHLIB_VERSION_NUMBER);
return 0;
}
The SHLIB_VERSION_NUMBER contains the so version string, e.g. 0.9.8 or 1.0.2k or 1.1.0. But how do I tell gcc to link against this version of libssl or libcrypto rather than just any -lssl?
I tried "in situ" linking, so that instead of linking with gcc main.c -lcrypto we use:
gcc main.c libcrypto.so.1.1.0
However it seems the linker libcrypto.so.1.1.0 cannot be found:
gcc: error: libcrypto.so.1.1.0: No such file or directory
I guess the system only searches in the standard locations when using the -l flag. Is there a better way to make my software link against libcrypto.so.1.1.0?
To select the correct version of the openssl shared libraries use:
gcc main.c -l:libssl.so.1.0.0 -l:libcrypto.so.1.0.0
The key to answering this question is "how do I control ld so that is links the correct version of a shared library?".
The correct way to pass a linker flag (a command line parameter to ld) using the gnu compilers (gcc, g++, gdc, etc...) is to use the normal ld parameter prefixed with "-l". For example -lssl or -L/usr/local/lib.
Edit: As per How to specify the library version to use at link time? you can read the manual for ld with:man ld.
I've written the following groundbreaking application:
#include <boost/program_options.hpp>
int main(int argc, char** argv)
{
boost::program_options::options_description generic_options("foo");
return 0;
}
I am trying to build this on Debian Stretch, on which the default compiler is GCC 5.3.1-5, and the installed version of Boost is 1.58.0.
However, for reasons which I will not go into here (which would be apparent had this not been a MCVE), I need to compile and link the binary using g++-4.9, not g++-5.3. Compiling works fine, but when I try to link, this is what happens:
/usr/bin/g++-4.9 -Wall -std=c++11 CMakeFiles/tester3.dir/src/altmain2.cpp.o -o bin/tester3 -rdynamic -lboost_log -lboost_system -lboost_program_options
CMakeFiles/tester3.dir/src/altmain2.cpp.o: In function `main':
altmain2.cpp:(.text+0x61): undefined reference to `boost::program_options::options_description::options_description(std::string const&, unsigned int, unsigned int)'
Is this due to some ABI incompatibility between gcc 4 and 5?
If so, is there any way to get around it other than building my own version of Boost?
If not, what could cause this?
Is this due to some ABI incompatibility between gcc 4 and 5?
Looks like it is. By default GCC 5 uses a new ABI for several important standard library classes, including std::basic_string template (and thus also std::string). Unfortunately it would be impossible to make std::string fully conform to C++11 and later without breaking the ABI.
libstdc++ implements dual ABI, so that binaries compiled with older versions of GCC will link (and work correctly) with the new library. See this post by Jason Merrill (the maintainer of GCC's C++ front end) for details.
If so, is there any way to get around it other than building my own
version of Boost?
Probably not. Boost depends on the new implementation of std::string and does not provide backward compatibility (unlike libstdc++). This problem is mentioned in Debian bugtracker.
I'm trying to cross compile programs (currently avconv from libav) for a Nokia N9 phone using arm-linux-gnueabi-gcc from Linux Mint's 64-bit repository. The compiler's libc version is 2.15 and the phone has libc-2.10.1. They have an incompatibility in the math library, which gives me a segfault when I compile and run the avconv program from libav.
I'd need to compile and link against the older libc version, but I haven't managed to get the --sysroot option to work.
I made a small test program to avoid repeatedly configuring and compiling libav.
arm-linux-gnueabi-gcc --sysroot=/opt/CrossCompilation/NokiaN9/ -o output.sysroot hello.c
arm-linux-gnueabi-gcc -o output.nosysroot hello.c
Both commands create an identical output file. This is what hello.c looks like:
#include <stdio.h>
#include <math.h>
int main() {
printf("Hello, World! Sin = %f\n", sin(0.6451));
}
The strangest part is that gcc completely ignores the --sysroot option. If I pass a nonexisting directory to sysroot, it still produces exactly the same output binary:
arm-linux-gnueabi-gcc --sysroot=/foo/bar -o output.foobar hello.c
It doesn't even complain about any errors. What's the problem?
since I wasted a few days messing with this before reading the comments, I'm going to post artless noise's comments as an answer:
"Run the compiler with arm-linux-gnueabi-gcc -v and look at the value of --with-sysroot; this is the directory the compiler was built with. If you have this directory present on your machine (maybe with a different compiler), then the --sysroot may not work[; and if you do not see --with-sysroot and instead see --with-libs, it] means your gcc is compiled without --sysroot support."
I'm trying to compile an application that utilizes cstdint. Since Apple deprecated the gcc, I wanted to try compiling it with clang, but i get the error:
fatal error: 'cstdint' file not found
I know that the gcc 4.6.2 version has the option for -std=c++0x, to include the library, but since the os x version is 4.2 that's not much of an option here. Any suggestions on how I can move forward? I have tried to install 4.6.2, but ran into a variety of issues when compiling some of the needed libraries before building gcc.
Presumably, you have the source code to this application, so you can modify the headers to include the correct cstdint header, as Clang 3.0 (which Lion's tools come with) does have the header.
Quick Solution
The header is under the tr1 directory, so you will want to do either of these includes:
#include <tr1/cstdint>
Or
#include <stdint.h> // which will use the C99 header
Longer, boring explanation
After doing some additional reading since I remember you can do this without the tr1 directory:
By default, you are going to be including C++ headers from /usr/include/c++/4.2.1, which are the GNU GCC headers. /usr/include/c++/4.2.1/tr1 includes the TR1 header files, like cstdint.
The alternative method is to compile using the Clang++ frontend and passing the -stdlib=libc++ flag, which will use the headers from /usr/include/c++/v1, which are Clang's C++ header implementations. It has cstdint.
Example:
// file called example.cxx
#include <tr1/cstdint>
int main() {
// whatever...
}
Compile this with:
g++ example.cxx
or
clang++ example.cxx
And it will do what you want.
If you don't want to use the tr1 version (which is roughly the same, if not exactly):
// file called example.cxx
#include <cstdint>
int main() {
// stuff
}
This is compiled like this:
clang++ -stdlib=libc++ example.cxx
Though if you use -stdlib=libc++, it means you're linking to Clang's C++ library libc++, rather than GCC's libstdc++.