I'm having an issue compiling NodeJS 4.2.3 (any version that requires c++ 4.8 and above) I've done the following:
Compiled gcc4.8 (because gcc is 4.4 by default on CentOS 6
Set the CXX option to point to the updated compiler
Added the MPC, GMP and MPFR libraries via the LD_LIBRARY_PATH,
But I'm still getting the following error:
gtest-test-part.cc:(.text.startup._GLOBAL__sub_I__ZN7testing14TestPartResult14ExtractSummaryEPKc+0xa):
undefined reference to std::ios_base::Init::Init()'
gtest-test-part.cc:(.text.startup._GLOBAL__sub_I__ZN7testing14TestPartResult14ExtractSummaryEPKc+0x1a):
undefined reference tostd::ios_base::Init::~Init()' collect2: error:
ld returned 1 exit status
So, I see the following gcc undefined reference to `std::ios_base::Init::Init()', but I'm not sure how to get that added, if it is at all possible, or if I'm supposed to add the library to the LD_LIBRARY_PATH? I also saw this, but I don't have root (legacy systems not part of our cloud) so I can't apply all the advice given.
What is the correct way to get nodejs to compile with gcc4.8 compiled via source?
Sigh, I made this a lot more complicated than need be.
The binaries are freely available for download, and I suppose I could have compiled on another machine and then just downloaded them from there but I was unconsciously concerned about linking problems (or even problems referencing the kernel?), but it seems to be working fine. I usually think of getting binaries from RPMs that require root. This does not appear to have needed to be the case.
Related
I'm having a problem at the link stage of compiling an application that links to several user built libraries.
These libraries link to the system Eigen 3 install, and all libraries were built using the same compiler and flags (gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)) This is on a RHEL 7.3 system (large cluster that uses module system to load/unload compilers).
What's strange is I built many other applications that linked to these same libraries that link to Eigen. All compile and link fine. This one application (not my code, but depends on same libs), is compiling fine but then spewing errors like this:
/usr/include/eigen3/Eigen/src/Core/arch/SSE/PacketMath.h:114: undefined reference to `_mm_set1_pd'
/nas/longleaf/home/deleeke/dogwood/sfw/ibamr/ibamr-master-scorep/ibtk/lib/libIBTK3d.a(libIBTK3d_a-LEInteractor.o): In function `double __vector Eigen::internal::pset1<double __vector>(Eigen::internal::unpacket_traits<double __vector>::type const&)':
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h:64: undefined reference to `_mm_set1_pd'
But this function is indeed defined in the emmintrin.h file it is pointing to. I know this header has something to do with instruction sets, but that's the extent of my knowledge.
I have not found any resources in my online searches or even going to the sysadmin's who run this cluster I'm working on. They all just groan a little bit and wave their hands around.
I know this code compiles on other machines -- so it has me thinking it has something to do with libgcc?
Can anyone give me some tips on how to trouble shoot this?
Thanks!
I'm having an odd linking problem with Boost (version 1.58). I'm building with g++ 4.8 on Ubuntu 15.10.
I get the following error:
undefined reference to
'boost::program_options::options_description::options_description(std::string
const&, unsigned int, unsigned int)' collect2: error: ld returned 1
exit status
What's strange is that all other symbols from lboost_program_options are found; options_description is the only undefined reference. If I comment out uses of options_description but keep uses of positional_options_description (which I'm also using) then the whole program compiles and links flawlessly. I am linking with -lboost_program_options, and if I remove this then as expected there are 8 missing boost::options_description symbols.
For a long time linking has worked correctly. Without any build system changes that I'm aware of it suddenly broke. The only systems level change was an upgrade to Ubuntu 15.10, which I don't think should have affected anything.
Any thoughts or suggestions appreciated.
Update: After lots of fiddling I got this working again, although I'm not sure what did it. I'm still interested in any answers to what could cause this type of behavior though.
Check that the ABI is compatible (you're using the same compiler version and flags used when compiling the boost libraries).
On Ubuntu, this means using stock GCC with libstdc++.
If you can't, compile your own Boost System and Boost Program Options binaries using your preferred flags.
Similar things prevent code samples from linking on http://coliru.stacked-crooked.com if your compiler is not the same as used when compiling boost there.
I had a similar problem after upgrading to Ubuntu 15.10 with a different symbol missing in a lib belonging to boost::program_options.
It helped to simply clean up the whole project by throwing away all object files etc. and recompiling it from scratch.
I am compiling a C++ project on Ubuntu 12.04 and I get a linking error stating
undefined reference to `clock_gettime#GLIBC_2.17'
undefined reference to `clock_getres#GLIBC_2.17'
I read a lot of threads about this issue and I tried all the usual solutions (separately). Such as adding the -lrt flag to the g++ command line (I tried in the beginning and in the end), setting the cmake linker flags variables to -lrt, adding the librt.so location to the link_directories variable or even to the target_link_libraries. None of this worked.
When I run ldd --version I get
ldd (Ubuntu EGLIBC 2.15-0ubuntu10.12) 2.15
And for what I understood from research this is the last glibc version for Ubuntu 12.04. But the error references to glibc 2.17...
So My question is: Am I getting this error because of the gclib version? Is there any way I can get a more recent version for Ubuntu 12.04?
Thank you in advance!
Although (because the OS is ancient) it might no longer apply, writing an answer (as #ecnl didn't visit the site in years).
Each OS (Nix) comes up with a [GNU]: The GNU C Library (glibc) version which (like any other package) could be upgraded during OS lifetime.
Ubuntu Precise (12.04), has (at question time) LibC 2.15 ([LaunchPad]: Binary package “libc-bin” in ubuntu precise)
A (3rd-party) library (.so) used by the project, was built against (and links to) LibC 2.17
The root cause of this is that between the 2 versions, clock_* functions were moved from LibRT to LibC (as pointed out by [SO]: C++ error: undefined reference to 'clock_gettime' and 'clock_settime' (#P.P's answer) (and referenced [SourceWare]: Move clock_* symbols from librt to libc.)).
As a consequence, an ELF linking to v2.17 will not run on v2.15, as it expects those functions to be exported by LibC. Possible fixes:
Rebuild the .so with v2.15 (option already took by OP)
Upgrade LibC to v2.17. However that might trigger some incompatibility issues (other stuff depending on v2.15 might stop working), so this has to be carefully considered
Recently I have asked a question about what I should use to create self-contained executables that would be deployed under a number of Linux distribution. I got very scared at first, but after reading about C++ a little, I managed to get the first version of my executable going.
After a day full of joy, I just hit the wall again with another dilemma. The resulting executable must be installed in a number of Linux distributions (Slackware, Arch, Ubuntu, Debian, CentOS and a few more), and I am completely clueless on how to achieve it. All I know CentOS and Debian-based OSes has package managers, like apt or yum, but I am not sure those apply to my case.
The code I wrote depends on a couple of libraries (more specifically RudeSocket and yaml-cpp. I have been told that I would be able to compile the executable and link it dynamically, so I just needed to distribute the executable.
It happens that I could not find the .a file for the yaml-cpp library (just for RudeSocket). And here's my problem so far:
At first, I went with dynamic linking but (obviously) when I copied the executable to another box:
$ ./main
./main: error while loading shared libraries: libyaml-cpp.so.0.2: cannot open shared object file: No such file or directory
When trying to compile it statically, I get an error too (because I don't have the yaml-cpp .a file as I mentioned):
$ g++ main.cpp parse.cpp parse.h rudesocket-1.3.0/.libs/librudesocket.a -o main -static -L/usr/local/librudesocket-1.3.0/.libs/librudesocket.a(socket_connect_normal.o): In function `rude::sckt::Socket_Connect_Normal::simpleConnect(int&, char const*, int)':
/root/webbyget/sockets/rudesocket-1.3.0/src/socket_connect_normal.cpp:250: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/tmp/cc3cEVK1.o: In function `operator>>(YAML::Node const&, Job&)':
parse.cpp:(.text+0x1a83): undefined reference to `YAML::Node::size() const'
/tmp/cc3cEVK1.o: In function `handle_job(rude::Socket, char const*)':
parse.cpp:(.text+0x1b79): undefined reference to `YAML::Parser::Parser(std::basic_istream<char, std::char_traits<char> >&)'
parse.cpp:(.text+0x1bfd): undefined reference to `YAML::Node::Node()'
parse.cpp:(.text+0x1c10): undefined reference to `YAML::Parser::GetNextDocument(YAML::Node&)'
parse.cpp:(.text+0x1dc6): undefined reference to `YAML::Node::size() const'
parse.cpp:(.text+0x1dee): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e18): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e37): undefined reference to `YAML::Parser::~Parser()'
parse.cpp:(.text+0x1e61): undefined reference to `YAML::Parser::~Parser()'
(...)
It's pretty obvious to me that g++ cannot compile it statically without telling it where to find the classes for yaml-cpp.
It is very important that the installation should happen without human interaction, in an automated fashion.
So my question is really twofold:
how can I distribute this compiled program in the least complex way targeting all those distributions?
is there any de facto standard solution for this kind of problem?
Thank you in advance,
Felipe.
You might give this technique a try.
There are many de-facto standards, but none of them are standardized. :( If you want to distribute a compiled binary, you will probably want to make a package for each platform you want to target. Generating an rpm and a deb will probably get you 90% of the way. If you want to automate the build process, autoconf/automake is still (probably) the best way to go.
Maybe The best solution for you is to use CMake.
CMake is cross-platform, open-source build system. It is a family of tools designed to build, test and package software. For Packaging, Mgb is right, CMake can easily be coupled with CPack.
KDE is using this solution and its a very good alternative to automake/autoconf.
If you use the platforms package manager (.rpm or .deb) the system will check for the correct version of the shared library for you and download it if it is needed.
CPack is probably the easiest package generator
I've been trying to move a project over from Xcode to Linux (Ubuntu x86 for now, but hopefully the statically-linked executable will run on an x86 CentOS machine? I hope I hope?). I have the whole project compiling but it fails at the linking stage-- it's giving me undefined references for all functions defined by IPP. This is probably something really small and silly but I've been beating my head over this for a couple days now and I can't get it to work.
Here's the compile statement (I also have a makefile that's generating the same errors):
g++ -static
/opt/intel/ipp/6.0.1.071/ia32/lib/libippiemerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippimerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippsemerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippsmerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippcore.a
-pthread -I /opt/intel/ipp/6.0.1.071/ia32/include
-I tools/include -o main main.cpp pick_peak.cpp
get_starting_segments.cpp
get_segment_timing_differences.cpp
recast_and_normalize_wave_file.cpp
rhythm_score.cpp pitch_score.cpp
pitch_curve.cpp
tools/source/LocalBuffer.cpp
tools/source/wave.cpp distance.cpp
...and here is the beginning of the long list of linker errors:
./main.o: In function `main':
main.cpp:(.text+0x13f): undefined reference to `ippsMalloc_16s'
main.cpp:(.text+0x166): undefined reference to `ippsMalloc_32f'
main.cpp:(.text+0x213): undefined reference to `ippsMalloc_16s'
Any ideas? FWIW, these are the IPP dependencies in my Xcode project that builds, links, and runs without a problem: "-lippiemerged",
"-lippimerged",
"-lippsemerged",
"-lippsmerged",
"-lippcore",
Thanks!
Your linking problem is likely due to the fact that your link line is completely backwards: archive libraries should follow source and object files on command line, not precede them. To understand why the order matters, read this.
Also note that on Linux statically linked executables are significantly less portable than dynamically linked ones. In general, if you link system libraries dynamically on an older Linux system, it will work on all newer systems (I use ancient RedHat 6.2, and I haven't seen a system on which my executable will not run). This is not true for completely static executables; they may crash in all kinds of "interesting" ways when moved to a system with a different libc from the one against which they were linked.
I had problems with linking code with the v 6 of the ipp; using the v11 version of the compiler (with the included updates to the ipp) mysteriously fixed them. Granted, that was with a windows platform, but I was getting 8u versions of functions to compile and no 32f versions, despite both being listed as valid in the documentation.