Running the build script from ELLCC results in this error
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/binutils -I. -I../../../src/binutils/binutils -I../bfd -I../../../src/binutils/binutils/../bfd -I../../../src/binutils/binutils/../include -I./../intl -DLOCALEDIR="\"/Library/Caches/Homebrew/ellcc--svn-HEAD/lib/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -Wno-unused-value -Wno-shadow -MT nm.o -MD -MP -MF .deps/nm.Tpo -c -o nm.o ../../../src/binutils/binutils/nm.c
../../../src/binutils/binutils/nm.c:1690:28: error: 'sbrk' is deprecated
[-Werror,-Wdeprecated-declarations]
char *lim = (char *) sbrk (0);
^
/usr/include/unistd.h:582:7: note: 'sbrk' declared here
void *sbrk(int);
^
The following compilers have been used with the same result:
gcc 4.8
llvm-gcc 2.8
llvm 3.3
I had the same issue compiling binutils-2.24 on Mac OSX Mavericks 13.2.0 with clang. Thanks to Richard Pennington's suggestion, I was able to get binutils to compile by specifying a few other -Wno-error arguments to gcc by setting CFLAGS before running configure. Namely, these are the commands I ran to build and install binutils:
CFLAGS="-Wno-error=deprecated-declarations -Wno-error=unused-variable -Wno-error=unused-function" ./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf
make
make install
EDIT: I just noticed that the binutils configure script accepts an --disable-werror argument, which disables gcc turning warnings into errors, and removes the need for the settings CFLAGS. With this argument, building could be done as follows:
./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf --disable-werror
make
make install
This error is occurring because sbrk() is deprecated on OSX, -Werror is enabled for the binutils build, and the compiler (in this case "gcc" is an alias for clang) rightly complains about the use of sbrk(). I'll be looking into eliminating this error this weekend when I won't have to be at my day job. ;-)
I looked into it a bit more. This happened because the latest version of OS X (Mavericks) uses clang as its compiler and /usr/include/unistd.h has a deprecated declaration of sbrk().
The solution was to add a -Wno-error=deprecated-declarations option to the CFLAGS for binutils. I also had to make a few other changes to complete the Max OS build. You can find the latest stuff in the ELLCC subversion tree.
Related
I'm doing all this on a VLE and below is what I'm working with:
Running OS: Linux Centos 7
GCC:4.8.5 & 7.1.0
I'm trying to use GNU autotools (libtool, autoconf, automake) to build a project in 32-bit using gcc-7.1.0. Also, as a requirement, I must do this on Centos 7 and use gcc-7.1.0.
Apparently, the latest version of gcc that can be officially upgraded through yum is 4.8.5. However, I successfully installed gcc-7.1.0 from the official source and even included --enable-multiarch --with-list-multilib=m32,m64 --enable-multilib during configure.
The issue I'm running into is that the autotools seem to want to use the 64-bit libraries even though I'm including -m32 compiler switch in CXXFLAGS, CFLAGS, and LDFLAGS. The reason I think it's using 64-bit libraries at linking is that I get the error below:
libtool: link: g++ -m32 -fPIC -Wall -Wextra -Weffc++ -Werror -std=c++03 -O2 -o fldprog fldprog-icpprog.o ../../ ../seal3/fld/src/.libs/libbsp_fld.a -lpci /usr/local/lib/../lib64/libstdc++.so -lm -Wl,-rpath -Wl,/usr/local/lib /../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64
/usr/local/lib/../lib64/libstdc++.so: error adding symbols: File in wrong format
And when I rename /usr/local/lib64 to lib64_something, the program will compile without any errors. However, I want to find a permanent solution.
I've searched the internet for answers but none of them seem to really work. I've tried including -L/usr/local/lib to AM_LDFLAGS, AM_CFLAGS in configure.ac
I'd appreciate any input. Thank you.
Edit:Revised
I noticed that in the default release configuration, qmake (qmake 3.1, qt 5.9.5 - whatever is installed on my Ubuntu build box) passes -Wl,O1 to g++ when linking. So the linking command line looks like
g++ -Wl,-O1 -flto -O2 -o program program.o lib1.a lib2.a ...
where -flto -O2 are the options that I'm passing via QMAKE_LFLAGS_RELEASE to enable LTO.
Now the question: why qmake has this -Wl,-O1 option and is it going to interfere with LTO?
QMake passes -Wl,O1, because it is meant to be a good default.
It will not harm LTO, because your -O2 option comes later and overrides the -Wl,O1.
From g++'s man page:
If you use multiple -O options, with or without level numbers, the
last such option is the one that is effective.
You can remove the -Wl,-O1 from your Makefile by specifying
QMAKE_LFLAGS_RELEASE -= -Wl,-O1
When attempting to compile GNU GCC 5.3.0 I encounter the following error when it tries to build libjavamath.la.
/bin/bash ../../../libtool --tag=CC --mode=link /home/borish/Downloads/gcc-build/./gcc/xgcc -B/home/borish/Downloads/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Iyes/include -g -O2 -module -version-info 0:0:0 -no-undefined -Lyes/lib -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/lib/../lib64/gcj-5.3.0-16 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo
../../../libtool: line 5209: cd: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
Makefile:403: recipe for target 'libjavamath.la' failed
This is on a Debian 8.4 system with GCC 4.9.2-10 installed. I believe I have satisfied all of the prerequisites, and Google wasn't been much help.
Any thoughts?
Update:
I used the following for running the configuration script:
../gcc-5.3.0/configure --disable-multilib --with-mpc --with-isl --with-mpfr --with-gmp
It sounds like you didn't run "configure" correctly. For example:
https://software.ecmwf.int/issues/browse/SUP-676
OK, I see a problem already, the "--with-jasper" option must point the
to the prefix of the "jasper" installation, for example
$./configure --with-jasper=/usr/local/jasper --with-png-support.
Otherwise the value "yes" is set as prefix..
For example, if you look here:
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
you'll see that a flag like ‘--with-headers=directory’ REQUIRES YOU TO ENTER A DIRECTORY PATH. I suspect the same thing is happening with your "-with-mpc" etc.
SUGGESTION: clean your build directory, and (carefully!) re-run ./configure.
The culprit appears to be the --with-gmp, --with-mpc and --with-mpfr switches when initiating the configure script. I suspect since libgmp is a prerequisite for libmpc and libmpfr, a bug feature in the configure script will include the offending -I and -L directives. Inclusion of any of them will result in the following in the root Makefile
HOST_GMPLIBS = -Lyes/lib -lmpc -lmpfr -lgmp
HOST_GMPINC = -Iyes/include
I haven't confirmed this to be the case in any of the other Makefiles, but I suspect something similar is going on elsewhere which is what I ran into when it attempted to building libjavamath.la.
The work around is to omit those switches from the configure invocation. They should be included in any event since the configure script will fail if they aren't present on the host.
I'm using GCC 4.7.2 and LD 2.23 but when I add -flto to my compile options my compile time increases by over 20%! The manual seems to indicate that -fuse-linker-plugin is needed for the optimization to work. It also says that it's enabled by default with -flto but when I add it explicitly I see the following error in the link command:
g++: error: -fuse-linker-plugin is not supported in this configuration
According to manual, it should be supported by LD 2.21 or greater. Any idea why I'm getting this error? For reference here are examples of my full compile commands:
g++ -Wall -pipe -O3 -flto -fno-strict-aliasing -mtune=generic --no-exceptions -fPIC -c some.cc
g++ -o exec -Xlinker some1.o some2.o -static some1.a some2.a -Wl,--wrap,open -flto -fuse-linker-plugin
Running 'ld --help | grep plugin' shows "-plugin" option so I don't understand why GCC is complaining:
-plugin PLUGIN Load named plugin
-plugin-opt ARG Send arg to last-loaded plugin
Link time optimizations aren't supposed to reduce compilation time, but optimize runtime of your program.
#options, just add "-flto -fuse-linker-plugin" to your CFLAGS(or CXXFLAGS for c++) and LDFLAGS and it should work just fine.
#gold: ld --version is probably gonna return gnu LD, to switch to gold, make ld symlink which ld point to which ld.gold
e.g. ln -s /usr/bin/ld.gold /usr/bin/ld
I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)