(I have the answer to this already; I'm going to answer my own question so that I can share what I've learned and save someone else this trouble in the future)
When I attempt to build Erlang on Solaris 10 Sparcv9, the build fails partway through:
cd lib && \
ERL_TOP=/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221 PATH=/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/bootstrap/bin:${PATH} \
make opt SECONDARY_BOOTSTRAP=true
make[1]: Entering directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib'
make[2]: Entering directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib/hipe'
=== Entering application hipe
make[3]: Entering directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib/hipe/misc'
erlc -W +debug_info +warn_exported_vars +warn_missing_spec +warn_untyped_record -o../ebin hipe_consttab.erl
make[3]: *** [../ebin/hipe_consttab.beam] Bus Error (core dumped)
make[3]: Leaving directory `/var/tmp/pkgbuild-0/erlang/sparcv9/erlang-otp-73b4221/lib/hipe/misc'
Why is this and what can I do to complete my Erlang build?
The reason that the build fails is due to a broken build environment.
In this specific case the Sun GCC build is being used. This particular version of GCC was compiled to use a mixture of the the GNU assembler and the Sun linker.
The Sparc platform is highly sensitive to alignment of code and it will fault (for example, with a bus error) if unaligned code is executed.
The GNU assembler used by the stock GCC build on Sparc Solaris 10 doesn't work so hard to automatically align functions generated by the compiler, leading to unaligned code.
The solution is to build your own GCC and make sure that you use the system assembler and linker; you can achieve this by using the following options to GCC's configure script:
--with-as=/usr/ccs/bin/as \
--without-gnu-as \
--without-gnu-ld \
--with-ld=/usr/ccs/bin/ld \
The resultant GCC build will generated properly aligned code and allow you to build Erlang successfully.
Related
Issue: Problem compiling bitcoin source code from https://github.com/bitcoin/bitcoin
Building bitcoin code requires Berkeley DB 4.8( https://github.com/tinybike/get-bdb-4.8).
No problem with that.
My system is running on Ubuntu 20.04.
$ cpp --version
cpp (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
When compiling the bitcoin code, after running 'configure' and 'make' an error occurs indicating that it could not find iostream.h
...
CXX libbitcoin_server_a-txrequest.o
CXX libbitcoin_server_a-txmempool.o
CXX libbitcoin_server_a-validation.o
CXX libbitcoin_server_a-validationinterface.o
CXX libbitcoin_server_a-versionbits.o
CXX wallet/libbitcoin_server_a-init.o
In file included from ./wallet/bdb.h:27,
from wallet/init.cpp:19:
/bitcoin/src/bdb/build_unix/build/include/db_cxx.h:59:10: fatal error: iostream.h: No such file or directory
59 | #include <iostream.h>
| ^~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:8933: wallet/libbitcoin_server_a-init.o] Error 1
make[2]: Leaving directory '/bitcoin/src'
make[1]: *** [Makefile:15214: all-recursive] Error 1
make[1]: Leaving directory '/bitcoin/src'
make: *** [Makefile:809: all-recursive] Error 1
On examining the header files location /usr/include/c++/9 I could not locate iostream.h
Is this a compiler package issue or bitcoin not using c++ iostream header file
I would guess you tried to build the "depends" BDB before installing the required system packages, and that produced an invalid/unusuable build.
Try removing your current "depends" builds and doing them over.
Alternatively, you could just use my db48 PPA for Ubuntu: https://launchpad.net/~luke-jr/+archive/ubuntu/db48
i got the same error,but it came when i build zero-ice with berkeley db. I found some usages about libdb and most of them add #define HAVE_CXX_STDHEADERS at the begining of codes, so i tried add this definition in ICEDIR/cpp/include/IceUtil/Config.h. It works.Wish it works for you.
something was completely wrong during db4.8 compilation
but as temporary fix, you may add in
include/db_cxx.h
#define HAVE_CXX_STDHEADERS 1
this may help, but depends.
imho
most correct way to build db-4.8 for bitcoin
wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz
tar zxvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC
build_unix/
../dist/configure --prefix=/usr/local/db48 --enable-cxx --with-pic --disable-replication --disable-shared
make install
cd ../bitcoin-x.x
export BDB_PREFIX=/usr/local/db48
export BDB_LIBS="-L/usr/local/db48/lib -ldb_cxx-4.8"
export BDB_CFLAGS="-I/usr/local/db48/include"
./configure
and etc.
I am trying to run coverage on my project, after updating to Ubuntu 16.04.
I get
Deleted 665 files
Writing data to coverage.info.cleaned
lcov: ERROR: cannot write to coverage.info.cleaned!
CMakeFiles/coverage.dir/build.make:57: recipe for target 'CMakeFiles/coverage' failed
make[3]: *** [CMakeFiles/coverage] Error 13
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/coverage.dir/all' failed
make[2]: *** [CMakeFiles/coverage.dir/all] Error 2
CMakeFiles/Makefile2:74: recipe for target 'CMakeFiles/coverage.dir/rule' failed
make[1]: *** [CMakeFiles/coverage.dir/rule] Error 2
Makefile:129: recipe for target 'coverage' failed
make: *** [coverage] Error 2
enter code here
Before the update I had no problem running the coverage
Does it help if you use absolute paths instead of relative paths when passing files to lcov?
I ran into a similiar problem where lcov also failed to write the file.
Not sure if it is a bug in lcov, but the problem was that it got confused with relative paths:
lcov -a test_fast_cxxtest_gcov__base.info -a test_fast_cxxtest_gcov__test.info \
-o test_fast_cxxtest_gcov__total.info
Combining tracefiles.
Reading tracefile test_fast_cxxtest_gcov__base.info
Reading tracefile test_fast_cxxtest_gcov__test.info
lcov: WARNING: function data mismatch at /home/phil/ghost/constants.h:1862
Writing data to test_fast_cxxtest_gcov__total.info
lcov: ERROR: cannot write to test_fast_cxxtest_gcov__total.info!
Running it with strace revealed that it executes chdir("/") on several locations, which changes the working directory to /. That explains why it cannot write the file.
One workaround is to use absolute paths. For instance, if you are using GNU make, you can use the abspath command:
lcov -a $(abspath test_fast_cxxtest_gcov__base.info) \
-a $(abspath test_fast_cxxtest_gcov__test.info) \
-o $(abspath test_fast_cxxtest_gcov__total.info)
After that change, it was finally able to write the file.
(Other options like trying to set the directories using the --base-directory or --directory option did not have an effect, as far as I saw.
The version of lcov that I tested with is 1.12.)
The problem is not limited to Ubuntu, as I ran into it on Arch Linux. It could be a regression introduced in 1.12, however, so I reported it (see issue #77630).
Update: Lcov is not part of GCC, so my original bug report was closed, but I got an answer from the Lcov mailing list. The problem is already fixed in commit 632c25. Users of Arch Linux based distros can try the latest snapshot with aur/lcov-git.
I have been trying to enable the gold linker on FreeBSD to use the link time optimizations. I made gold from the binutils under /usr/ports. After building binutils using make -k install clean i got ld under /usr/bin and in the directory /usr/local/bin i got ld, ld.gold and ld.bfd.
Now while trying to use link time optimization for the simple example programs here http://llvm.org/docs/GoldPlugin.html (a.c and b.c under the heading 'Examples of Link Time Optimization') i entered the four commands as follows:
clang -flto a.c -c -o a.o
ar q a.a a.o
clang b.c -c -o b.o
clang -flto a.a b.o -o main
I got the following error:
usr/bin/ld: unrecogonized option '-plugin'
usr/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is there the problem with the linker that ld.gold is not being called. Should I replace the ld with ld.gold? Does the linker looks in the right directiry for the .so plugins?
The LLVMgold.so and libLTO.so shared objects are in the directory /usr/local/llvm-devel/lib/.
I cannot find the directory where clang is installed. I am not sure where to make the bfd-plugins directory and add the symlinks to LLVMgold.so and libLTO.so.
I am using freebsd 10.1 release. How to enable the gold linker for link time optimizations?
also how can I enable it to be the default linker?
You may want to use ld.gold instead of ld. It is installed at /usr/local/bin/ld.gold. If you are using a Makefile, it would work by setting LD variable to ld.gold, either by modifying your Makefile or specifying it on command line. Example in case you are using lang/clang37:
gmake all CC=clang37 LD=ld.gold
EDIT:
It would be even more neat if you add -fuse-ld=gold to your LDFLAGS:
LDFLAGS=-fuse-ld=gold
I'm not sure ld.bfd allows plugins, but I could be wrong.
Your /usr/bin/ld should be a symlink to whatever linker you want. You can change which linker is used by using binutils-config. Check the man-page here: http://www.linuxhowtos.org/manpages/8/binutils-config.htm. I realise this is a Linux link, but it's directed at binutils itself rather than linux-specifically.
It should be something along the lines binutils-config --gold.
On my Gentoo box it is binutils --linker=gold
EDIT: As pointed out, binutils-config doesn't work on BSD it seems. You can still manually update the symlinks though, the downside is that there might be a few of them.
You can find out which ld is used by your compiler by using gcc -print-prog-name=ld or clang -print-prog-name=ld. The file printed should be a symlink you can re-create to point to ld.gold as oposed to ld.bfd.
I've been trying to compile syn64k--for use in Executor, to run System's Twilight (a game I played as a kid). I'm doing this on my macbook pro (lion 10.7.4 with the latest Xcode and command line tools). I mapped CC to gcc -m32 to fix a couple problems I was having, but I got the following:
Making all in native/i386
make[2]: Nothing to be done for `all'.
outgoing=;\
gcc -m32 -maccumulate-outgoing-args -c -x c /dev/null 2> /dev/null && outgoing=-maccumulate-outgoing-args; \
gcc -m32 -S -O2 -fomit-frame-pointer -Wall -static -fno-defer-pop -Wno-unused\ -I./include -I./../include -I. -I../include $outgoing syn68k.c -o ./syn68k.s
syn68k.c: In function ‘s68k_handle_opcode_0x07A3’:
syn68k.c:52968: internal compiler error: in EmitLV_DECL, at llvm-convert.cpp:7475
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[2]: *** [syn68k.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I went to URL, and it doesn't look like a place to really put a bug report about LLVM. I the file 'syn68k.c' is about 50k lines long after the preprocessor is done with it, so I really don't thing I can make a reproducible test case to show the bug.
Turns out this issue is already on the github project (it is the only issue listed, ha). MaddTheSane says that this happens because clang does not support global register variables (as I verified here).
I don't really have much more than a basic understanding of how compilation works after you type make, so is there a way I can skip clang or something like that? What do you suggest?
Unfortunately, you need to use gcc, not llvm-gcc to compile this program. The LLVM backend of llvm-gcc does not support global register variables. Switching to clang won't help because it too will choke on the global register variables, for the same reason.
you definitely can skip building clang if its not necessary for what using llvm for.
llvm uses cmake for configuration and the generation of makefiles. you can modify the .cmake files to create a configuration that disables any modules you don't want to create.
http://developer.apple.com/bugreporter is definitely the right place to report a bug against any compiler distributed by Apple, even if it may not look like it. That said, there's no point to filing a bug report against anything other than clang. (BTW, the size of the testcase doesn't really matter.)
If you don't know enough C to hack the source code, it might be worth a shot to grab a newer version of gcc from macports or something like that.
I'm trying real hard to install vowpal wobbit and it fails when i run the make file, throwing:
cd library; make; cd ..
g++ -g -o ezexample temp2.cc -L ../vowpalwabbit -l vw -l allreduce -l boost_program_options -l z -l pthread
ld: library not found for -lboost_program_options collect2: ld returned 1 exit status make[1]: *** [ezexample] Error 1'
I then added the links to the boost library here by specifying -L/usr/local/lib
Now I get the following error:
g++ -g -o ezexample temp2.cc -L/usr/local/lib ../vowpalwabbit -l vw -l allreduce -l boost_program_options -l z -l pthread
ld: library not found for -lvw
collect2: ld returned 1 exit status
make: *** [ezexample] Error 1
I happened to get everything working on OS X 10.7 as follows:
Make sure you have a working Boost installation. As indicated on the Getting started page, usually we only need header files, but some Boost libraries must be built separately, including the program_options library which is used to process options from command line or config file. Go into your boost folder, and then at your shell prompt:
$ ./bootstrap.sh
$ ./bjam
This will compile and build everything. You should now have a bin.v2/ directory in your boost directory, with all built libraries for your system (static and threaded libs).
$ ls bin.v2/libs/
date_time iostreams python serialization test
filesystem math random signals thread
graph program_options regex system wave
More importantly, extra Boost libraries are made available in the stage/lib/ directory. For me, these are Mach-O 64-bit dynamically linked shared library x86_64.
The include path should be your_install_dir/boost_x_xx_x, where boost_x_xx_x is the basename of your working Boost. (I personally have boost_1_46_1 in /usr/local/share/ and I symlinked it to /usr/local/share/boost to avoid having to remember version number.) The library path (for linking) should read your_install_dir/boost_x_xx_x/stage/lib. However, it might be best to symlink or copy (which is what I did) everything in usual place, i.e. /usr/local/include/boost for header files, and /usr/local/lib for libraries.
Edit the Makefile from the vowpal_wabbit directory, and change the include/library paths to reflect your current installation. The Makefile should look like this (first 12 lines):
COMPILER = g++
UNAME := $(shell uname)
ifeq ($(UNAME), FreeBSD)
LIBS = -l boost_program_options -l pthread -l z -l compat
BOOST_INCLUDE = /usr/local/include
BOOST_LIBRARY = /usr/local/lib
else
LIBS = -l boost_program_options -l pthread -l z
BOOST_INCLUDE = /usr/local/share/boost # change path to reflect yours
BOOST_LIBRARY = /usr/local/share/boost/stage/lib # idem
endif
Then, you are ready to compile vowpal_wabbit (make clean in case you already compiled it):
$ make
$ ./vw --version
6.1
$ make test
You can also install vowpal wabbit on OS X using brew:
brew install vowpal-wabbit
Or you can just install boost, and then install vw from the github repo.
brew install boost
For installation on CentOS 7 (6.5 perl version is too old for latest vw source code), I've found the instructions at http://wkoplitz.blogspot.be/2012/12/vowpal-wabbit-on-centos.html to work fine:
yum install zlib-devel boost-devel
yum groupinstall "Development Tools"
git clone git://github.com/JohnLangford/vowpal_wabbit.git
cd vowpal_wabbit
./autogen.sh
make
make test
Good news:
As of the latest release VowpalWabbit version 9.1.0, vw no longer relies on Boost program_options
From the release highlights:
Removal of Boost Program Options dependency
For a long time we have depended on Boost Program Options
for command line options parsing. In this release, we have > replaced this dependency with our own implementation of
command line parsing. Apart from one place where we depend > on Boost Math in standalone mode, this means that VW core
and the command line tool are free of Boost dependencies
hopefully making the code a bit easier to build and package.
Vowpal Wabbit 9.1.0 release notes