I'm working with RHEL6 systems, but need to port the code using C++11 (and even C++14) features. This forced me to build gcc-8.2 by hand, installed under a private prefix (/prod/pfe/local). This created a number of executables under /prod/pfe/local/bin: gcc, g++, ld, and gfortran.
I'm now trying to build CBLAS, which uses the above gfortran. Building the library (cblas_LINUX.a) works fine, but creating an executable fails with a cryptic errors cited in the title:
gfortran -o xscblat1 c_sblat1.o c_sblas1.o ../lib/cblas_LINUX.a
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: _edata: invalid version 21 (max 4)
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: error adding symbols: bad value
Did I configure build gfortran incorrectly? If not, how do I solve this problem -- additional FFLAGS or LDFLAGS of some kind?
Ok, according to the gcc-developers, this is a known bug triggered by the use of the new linker (gold).
Rebuilding the compiler suit with --disable-gold solves the problem.
Update: correction -- somehow, disabling gold is not good enough. Going back to the binutils-2.30 is what I ended up doing...
Related
Good Morning.
I am compiling Clang, following the instructions here Getting Started: Building and Running Clang
I am on linux and the compilation goes smoothly. But I think I am missing out something...
I want to compile ONLY clang, not all the related libraries. The option -DLLVM_ENABLE_PROJECTS=clang seems doing what I want (check LLVM_ENABLE_PROJECTS here)
If I use the instructions written there, I can compile, but I think I am compiling too much....a build directory of 70GB seems too much to me...
I tried to download the official debian source and compile the debian package (same source code! just using the "debian way" to create a package from official debian source), just to compare...The compilation goes smoothly, is very fast, and the build directory is much much smaller...as I expected...
I noticed in the first link I provided the phrase "This builds both LLVM and Clang for debug mode."...
So, anyone knows if my problem is due to the fact that I am compiling a "debug mode" version? if so, how could I compile the default version? and is there a way to compile ONLY clang without LLVM?
Yes, debug mode binaries are typically much larger than release mode binaries.
Cmake normally uses CMAKE_BUILD_TYPE to determine he build type. It can be set from the command line with -DCMAKE_BUILD_TYPE="Release" o -DCMAKE_BUILD_TYPE="Debug" (sometimes there are other build types as well).
I understand that this has come up a lot, but I've looked through all the other answers and none of them are relevant to me.
I am trying to compile the neuroimaging software FSL from source (I have to, it's not supported on my Linux Distro). I've followed all the instructions listed here, and it's about 80% compiled. There are a few modules that have not been successful, however, and they all seem to trace back to a problem trying to compile CiftiLib-master.
Per the instructions, whenever I try to run the 'make' command, it returns:
Makefile:34: warning: overriding recipe for target 'clean'
/home/thosvarley/Desktop/fslbuild/fsl/config/common/rules.mk:32: warning: ignoring old recipe for target 'clean'
gcc -c -Wall -ansi -pedantic -Wno-long-long -m64 -g -O3 -fexpensive-optimizations -m64 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/boost -g -DCIFTILIB_USE_XMLPP -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/libxml2 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/libxml++-2.6 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/lib/libxml++-2.6/include -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/boost -I./Common -I./Nifti -I./Cifti -I. -I/include -I/home/thosvarley/Desktop/fslbuild/fsl/include -o Common/XmlAdapter.o Common/XmlAdapter.cxx
In file included from Common/XmlAdapter.cxx:28:0:
Common/XmlAdapter.h:56:10: fatal error: libxml++/libxml++.h: No such file or directory
#include "libxml++/libxml++.h"
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:19: Common/XmlAdapter.o] Error 1
As I am not trying to compile one foo.c file, but rather, make a program a lot of the advice I've seen doesn't seem like it would apply to me. I've already installed all of the various libxml packages that get suggested in other posts (libxml2, libxslt1, etc).
I cannot make heads or tails of the error message: I'm not familiar with compiling C programs at all (this is my first serious foray into building from source). Apologies in advance if the answer is obvious and I just don't recognize it.
I'm on Antergos Linux (Arch kernel), which I think may be where the problem is coming from as all the other people who have asked after this seem to be on Debian or Ubuntu.
I have been attempting to solve the same problem. It seems that libxml++ is bundled with FSL by default, and the bundled version fails to compile.
Solution #1: Install and use an older compiler (e.g. GCC 4.8), since the project's configurations are made to fit those old compilers
I cannot vouch for this solution, as I haven't tried it myself (because apparently, I like to make life difficult for myself), but it's probably your best bet.
Solution #2: Fix the problems manually
NOTE: This is not a comprehensive solution, but it might point you in the correct direction.
Your first problem is most likely that the compiler you're using by default uses a more recent C++ standard than the project is written to be compiled with. This causes the implicit conversion of input streams and output streams to booleans to fail. You might be able to solve it by messing around with compiler flags in the makefile configurations, but it's probably easier to just fix the problematic parts of the code. The relevant lines (FSL 5.0.11) are:
- extras/src/libxml++-2.34.0/libxml++/io/istreamparserinputbuffer.cc (line 42)
return _input;
SHOULD BE
return static_cast<bool>(_input);
- extras/src/libxml++-2.34.0/libxml++/io/ostreamoutputbuffer.cc (line 32)
return _output;
SHOULD BE
return static_cast<bool>(_output);
- extras/src/libxml++-2.34.0/libxml++/io/ostreamoutputbuffer.cc (line 39)
return _output;
SHOULD BE
return static_cast<bool>(_output);
Depending on the version you're trying to install, the actual line numbers may be different, but they're probably in the same general area.
The next problem is that the include paths are not defined for INC_XML++, INC_XML++CONF and INC_XML2 in the generic makefile configuration. This is most likely the one your system defaults to, as there are no configurations for GCC versions > 4.8. Edit the config/generic/externallibs.mk file by adding the following lines (where exactly you add it is not important):
# XML++
LIB_XML++ = ${FSLEXTLIB}
INC_XML++ = ${FSLEXTINC}/libxml++-2.6
INC_XML++CONF = ${FSLEXTLIB}/libxml++-2.6/include
INC_XML2 = ${FSLEXTINC}/libxml2
(I addeed the LIB_XML++ for good measure, because the lib path was defined by other variables in the file, but I'm not 100% sure it's necessary.)
Again, this is what fixed it on my system. Depending on the version of the source code you downloaded, it might be different for you, but at least this is a starting point.
After fixing these errors, the CiftiLib-master target should compile. HOWEVER, if your system is anything like mine, this is far from the only error in the build process. Looking at the build.log file and searching for error: should give you a pretty good idea of which projects result in which errors, and what might be needed to fix them. The problems are likely to be similar in nature to the CiftiLib ones.
Final tip: If your libgd project fails to compile, look at the error: message. It probably complains about some undeclared identifiers (IMG_FMT_I420, PLANE_Y, PLANE_U, PLANE_V). If you prefix these identifiers with VPX_, it should work. The reason this fails is because of an update to the library that removes the definitions of the deprecated identifiers, forcing users to use the newer prefixed ones.
This is as far as I've come. I'm assuming you're not still troubled with this a year later, but I'm leaving this here for posterity.
I am trying to cabal install a component of wxHaskell (Haskell platform 2013.2 against wxWidgets 3.0).
I was able to compile the git version with 32 bit mingw from mingw.org. But in the end, the installed wx cannot function correct, and running a minimal example gives runtime exceptions in wxc.dll. So I try to compile the same thing under TDM-GCC 4.8.1 64bit, since the wxWidgets people provide their binary in the form of TDM-GCC compiled binaries.
But I immediately run into compilation errors with TDM-GCC, telling me
error: 'strnlen' was not declared in this scope
What surprises me is that even though both mingw32 and TDM-gcc uses the same external gcc from Haskell Platform c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe, one would give an error while the other compiles fine.
The first file causing problem is src\cpp\eljaccelerator.cpp. It compiles OK under mingw32:
...
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/MinGW/msys/1.0/local/include/wx-3.0 -IC:/Min
GW/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LAR
GEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerato
r.cpp -o dist\build\src/cpp/eljaccelerator.o
but gives an error under TDM-gcc:
Building wxc
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/mingw/msys/1.0/local/include/wx-3.0 -IC:/min
gw/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_FIL
E_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerator.cpp
-o dist\build\src/cpp/eljaccelerator.o
In file included from C:/mingw/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\eljaccelerator.cpp:1:
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope
Failed to install wxc-0.90.1.1
I was wondering if anyone has any similar experience. Any idea what went wrong and how to fix compilation for TDM-GCC? I tried adding #include <cstring> to wxcrt.h but it doesn't change anything.
FYI, I have compiled wxWidgets 3.0.0 from source in mingw and tdm-gcc versions respectively, using
./configure --enable-stl && make && make install
I can provide more details if needed.
First of all, wxWidgets certainly does work with MinGW, the fact that only TDM binaries are provided simply means that someone volunteered to provide the latter but not the former. But all three popular versions of MinGW (the two already mentioned and MinGW-w64) do work, so there must be something wrong with the build...
However while they all work, they are certainly different compilers, so what do you mean that they both use the same gcc binary? It must be either a MinGW one or a TDM one, but it can't be both at once.
It's also very suspicious that the configure detects different flags to use for the large file support. Look at config.log, something must have gone wrong and there must be some errors in the initial stage in it.
I've been trying to compile gcc 4.x from the sources using --with-fpmath=387 but I'm getting this error: "Invalid --with-fpmath=387". I looked in the configs and found that it doesn't support this option (even though docs still mention it as a possible option):
case ${with_fpmath} in
avx)
tm_file="${tm_file} i386/avxmath.h"
;;
sse)
tm_file="${tm_file} i386/ssemath.h"
;;
*)
echo "Invalid --with-fpmath=$with_fpmath" 1>&2
exit 1
Basically, I started this whole thing because I need to supply an executable for an old target platform (in fact, it's an old Celeron but without any SSE2 instructions that are apparently used by libstdc++ by DEFAULT). The executable crashes at the first instruction (movq XMM0,...) coming from copying routines in libstdc++ with an "Illegal instruction" message.
Is there any way to resolve this? I need to be on a fairly recent g++ to be able to port my existing code base.
I was wondering if it's possible to supply these headers/sources from an older build to enable support for regular x87 instructions, so that no SSE instructions are referenced?
UPDATE: Please note I'm talking about compiled libstdc++ having SSE2 instructions in the object code, so the question is not about gcc command line arguments. No matter what I'm supplying to gcc when compiling my code, it will link with libstdc++ that already has built-in SSE2 instructions.
The real answer is not to use ANY --with-fpmath switches when compiling GCC. I got confused by the configure script switch statement thinking that it only supports sse or avx, while, in fact, the default value (not mentioned in this switch is "387"). So make sure you don't use --with-fpmath when running configure. I recompiled GCC without it and it now works fine.
Thanks.
The argument to tell gcc to produce code for a specific target is -march=CPU where CPU is the particular cpu you want. For an old celeron, you probably want -march=pentium2 or -march=pentium3
To control the fp codegen separately, newer versions of gcc use -mfpmath= -- in your case, you want -mfpmath=387.
All of these and many others are covered in the gcc documentation
edit
In order to use those flags for building libraries (such as libstdc++) that you'll later link in to programs, you need to configure the build for the library to use the appropriate flags. libstdc++ gets built as part of the g++ build, so you'll need to do a custom build -- you can use configure CXXFLAGS=-mfpmath=387 to set extra flags to use while building things.
Please note the question was about compiled libstdc++ having SSE2 instructions in the object code, so the question was not about gcc command line arguments. No matter what I'm supplying to gcc when compiling my code, it will link with libstdc++ that already has built-in SSE2 instructions.
The real answer is not to use ANY --with-fpmath switches when compiling GCC. I got confused by the configure script switch statement thinking that it only supports sse or avx, while, in fact, the default value (not mentioned in this switch is "387"). So make sure you don't use --with-fpmath when running configure. I recompiled GCC without it and it now works fine.
I wrote a very simple ncurses program to be run in BusyBox environment. However, it seems like that I cannot get my program to compile with everything. I used:
g++ menu.cpp -ohello -lncurses --> Works fine
g++ -static menu.cpp -ohello -lncurses --> Undefined reference to SP (many times)
I found this question but it ignores linking to ncurses. I need a very single executable. My targeted environment is fixed, so I do not concern portability.
You should paste the exact compiler calls and the exact error messages that you are getting.
Do you have a static version of the ncurses library?
More importantly, do you have a static version of the ncurses library compiled for your target environment? For example your target environment may be using ulibc instead of glibc or it could even be a whole different platform (hint: tell us what your target platform is).
Are you certain that you are compiling with the right flags? The compiler flags that you are showing seem more suited to compiling an application for use in the build host environment...