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.
Related
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...
I'm using current riscv-tools to build a firmware image for the PicoRV32 core. The firmware requires floating point, so I'm using -msoft-float. This are the compiler/linker options I am using:
-Os -m32 -march=RV32I -msoft-float -ffreestanding -nostdlib -lgcc
in this configuration, __muldf3 is provided by (according to the linkers -Map output):
/opt/riscv/lib/gcc/riscv64-unknown-elf/4.9.2/soft-float/32/libgcc.a(dp-bit.o)
But this code is not compatible with the RV32I ISA: It uses the MUL and MULHU instructions!
How do I get soft-float for the plain RV32I ISA? Do I need to compile my own version of libgcc.a? Are there instructions somewhere on how to do this?
As you've noticed, the "-march=" flag only affects the current translation unit, not the libraries which get generated at toolchain build time.
Although there exist "disable-atomics"/"disable-float" configuration flags for building the toolchain, there is no multilib option for multiply/divide because they don't affect the ABI; the assumption is that the execution environment can emulate those instructions.
To the last point, the latest Privileged ISA v1.7 is designed such that you can run mul/div code and then trap into the machine-mode to emulate the mul/div instructions (you can even trap into M-mode while running in M-mode!). You'd have to provide your own mul trap handler in M-mode (probably located in your own crt0 file and linked in at compile time).
I instead recommend you try the "--with-arch" flag. A recent patch supports the --with-arch flag, so it's possible to build a gcc that by default won't generate multiply/divide. This will prevent libgcc from containing those instructions. You can try adding --with-arch=RV32I to the gcc configure line (to do so, you'll have to modify Makefile.in in the riscv-gnu-toolchain).
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 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...
Is there some way to use ld.so.preload and cover both 32bit and 64bit binaries?
If I list both the 32bit and 64bit versions of the fault handler in ld.so.preload then the loader always complains that one of them fails to preload for whatever command I run. Not exactly earth shaking since the error is more a warning but I could certainly do without the printout.
Instead of specifying an absolute path I tried specifying simply "segv_handler.so" in the hopes that the loader would choose the lib in the arch appropriate path (a 32bit version is in /lib and a 64bit version is in /lib64).
Not likely apparently.
Is there a way to setup ld.so.preload to be architecturally aware? Or if not is there some way to turn off the error message?
This works:
put library under /path/lib for 32bit one, and put the 64bit one under /path/lib64
and they should have the same name
put the following line in /etc/ld.so.preload:
/path/$LIB/libname.so
$LIB will get the value "lib" (for 32bit) or "lib64" (for 64bit) automatically.
There's no reason to try to use ld.so.preload like this. By default ld is smart enough to know that if you're running a 64bit app to only lookup 64bit libs, and same with 32bit.
Case in point, if you have
/lib64/libawesome.so
/lib/libawesome.so
And you try
gcc -lawesome -o funtime funtime.c
It'll choose whatever the default that gcc wants to build, ld will skip libraries of incorrect bit size for that build.
gcc -m64 -lawesome -o funtime funtime.c will pick the 64bit one
gcc -m32 -lawesome -o funtime funetime.c will pick the 32bit one.
This presumes that /etc/ld.so.conf lists /lib and /lib64 by default..
Sadly, I think the answer might be "Don't do that."
From glibc, elf/rtld.c:
There usually is no ld.so.preload file, it should only be used for emergencies and testing. So the open call etc should usually fail. Using access() on a non-existing file is faster than using open(). So we do this first. If it succeeds we do almost twice the work but this does not matter, since it is not for production use.
You can provide 32 and 64 bit library using special expansion keys in the path name.
For instance you can use /lib/$PLATFORM/mylib.so and create /lib/i386/mylib.so and /lib/x86_64/mylib.so. Linked will choose the correct one for your executable.