You are not logged in.
Background: I have found a regression in binutils that did not exist with 2.25. I'd like to use `git bisect` on the binutils source to determine where the regression began.
Problem: When I finish building and installing binutils the linker cannot link even the simplest hello-world C++ program.
Here is how I am building binutils.
$ git clone git://sourceware.org/git/binutils-gdb.git
$ mkdir -v build
$ cd build
$ ../configure --prefix=/usr \
--with-lib-path=/usr/lib:/usr/local/lib \
--with-bugurl=https://bugs.archlinux.org/ \
--enable-threads --enable-shared --with-pic \
--enable-ld=yes --enable-gold=yes --enable-plugins \
--enable-deterministic-archives \
--disable-werror --disable-gdb
$ make tooldir=/usr
$ sudo make install
For the most part this is lifted from this PKGBUILD.
Using this hello-world C++ program.
#include <iostream>
int main()
{
std::cout << "Hello World!";
}
When compiled produces the following linking error.
$ g++ hello.cpp -o hello
/usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib/crti.o: unrecognized relocation (0x2a) in section `.init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Suggestions or pointers are appreciated.
Last edited by rlovelett (2016-03-22 19:59:39)
Offline
Why don't you pull an old PKGBUILD from the package page and install it properly?
Offline
Awebb, I want to be able to run `git bisect` on the binutils repo to determine exactly which commit in that repository is causing my regression. Hopefully then I can either work around the regression or possibly (hopefully) commit a patch back upstream.
I do want to acknowledge though, you are right to get back to a compiling version that is what I can (and have) done.
Offline
I see. I probably shouldn't even be out of bed, but I needed to sit for a while. :-)
In the PKGBUILD diff you linked, there is a comment:
# toolchain build order: linux-api-headers->glibc->binutils->gcc->binutils->glibc
You might want to find out, why that is and how to deal with it.
Offline
That is a great point. I never noticed that comment before now.
I'm still new to Arch and etiquette is not always clear to me. Is it innapropriate for me to email the developer listed in the header of the PKGBUILD and ask them?
Offline
I don't think Allan would mind. You could also post to "arch-general" (https://lists.archlinux.org//listinfo/). It would certainly help, if you described, what kind of a regression you have in mind.
Offline
Awebb, I want to be able to run `git bisect` on the binutils repo.
Check out
makepkg -ef
PKGBUILD are completely cooperative with git and development after moving configure et al into prepare(). Using the PKGBUILD ensures you don't introduce additional problems by using non standard compile and install. It's also way easier than whatever it is you're doing.
Offline
It's also way easier than whatever it is you're doing.
That really was a little bit of an ungenerous remark.
Regardless I do appreciate the suggestion. In fact I did know of it and was making use of it in my `git bisect run` script.
I reached out to Allan and he pointed out that the older glibc and gcc have relocations only recognised by newer binutils. At his suggestion, what I did was make a VM that used Arch Linux Archive to restore glibc and gcc to a state before the relocation changes. Then I was able to compile newer version of binutils using the above linked `git bisect run` script.
Long story short. Problem is solved. Thank you for the suggestions.
Offline