configure: error: GRUB requires a working absolute objcopy; upgrade your binutils
 

I am trying to compile grub on Fedora 8 because I need to apply the patch for bug 250299.

First, I downloaded and installed http://mirrors.kernel.org/fedora/rel....97-19.src.rpm

Next, I extracted the included grub-0.97.tar.gz to /usr/src/

At this point, if I run configure, I will get the error mentioned in the subject, as follows:

However, I am running binutils 2.17.50.0.18 which is the latest in the fedora repo, so I cannot upgrade, and I do not know how to downgrade.

I saw another issue where this same error was happening, and someone suggested downloading ftp://alpha.gnu.org/gnu/grub/grub-0.97.tar.gz and using it.

I tried this and determined that that is the exact file included in the srpm I had downloaded, and the error still surfaces when I try it.

Additionally, if I apply the included grub-fedora-8.patch, the configure file disappears. I can get it from the tar again, but I will still get the same error, so while I need to know how I am supposed to compile after applying that patch (which I apply before the patch for the aforementioned bug), but that point is moot until I can determine how to fix this binutils issue.

try a LQ solution
http://www.linuxquestions.org/questi...31#post2933831

I may be dense, but I'm not sure what you're getting at. That was a problem I had compiling grub in F7, and I determined the problem was missing headers. In this case, I am getting a totally different error, and those headers aren't missing.

On a whim, I tried installing some other headers where 32-bit ones didn't exist (ilbstdc++-devel in this case), but that made no difference on the error I am getting.

Also, when I said: I was referring to another LQ suggestion from someone else's post (the other post wasn't especially relevant, but it was as close to relevant as I had found). I also tried yahoo and google, but found very little at all and nothing leading to a solution (it should be noted that I am consistently exceptionally bad at searching).

Anyway, I didn't post the config.log earlier. Here is the relevant part of it:
Any suggestions on how to resolve this would be appreciated. As previously noted, I haven't tried compiling a newer copy of binutils manually, because I doubt it would help (I can't imagine the Fedora repo copy really doesn't work), and because I am concerned that manually compiling it could lead to other problems.

I am also still curious as to whether anyone can tell me whether or not I should use the configure script from the source after applying grub-fedora-8.patch since said patch deletes said script (but I certainly don't know how else to go about building it with that patch). Should I post a separate topic on that?

Resolved
 

This is the "not especially" relevant thread I mentioned earlier (it may also be the article you meant to refer me to):
http://www.linuxquestions.org/questi...nutils-603125/
I revisited it, and it looked more relevant (I tuned out once you guys started talking about LFS, so I didn't notice your suggestion: was actually about the original issue.)
After installing compat-gcc-34 (and compat-gcc-34-c++ for good measure), I tried configure again, and the configure script worked fine, so hopefully that's all I needed. Thanks.

I notice, in your output, that the _start value was defaulted to different addresses in the two compilations. Since cmp is doing a byte-by-byte comparison, that may explain why it failed.

Whoever wrote the config script seems to have assumed that any failure of the cmp indicated an objcopy failure. I suspect that the assumption may be incorrect.

Resolved
 

Cool info, and you may be right, but it turns out that using an older version of gcc got through it, so I am going to leave that (potential err) to the coders in case it was nothing but a compatibility problem. Since you were probably posting before I noted that the issue was resolved, I am noting that again here. I ultimately used this command: as I didn't want to install to /hd/usr. Also, I didn't get make to work with the fedora patch applied, so I went without that and will ask about said patch in a separate thread, but aside from that, grub is at least giving xen the correct amount of memory now.

Sorry for bumping up an old thread. But I have the same problem, and the solution here does not apply to it.

I am trying to compile a grub pxe boot image, and I get the same error in the first post. And also solution in the last post does not apply to it because of this :

Trying gcc34 as compiler fails as you can see, and without gcc34 parameter I get the same log in the first post. What should I do ?

Thanks in advance.

What's in the config.log file?

Often the "cannot create executable" problem is just that you don't have write permission on the directory into which the executable is to be created.

Just to add, I have had the same problem. Using gcc-3.4 solves the build. However, the command line I used to configure was:

./configure CC=gcc-3.4

Thanks for the input. I'll try that one out.

Cannot create executable
 

@M.e.M.O. I had the same error configuring with an alternate version of gcc. Looking at config.log explained it. It turned out that Grub builds to 32 bits binaries, and the alternative compiler did not have the 32 bits libraries in /usr/lib32/gcc/i686-linux-gnu. Even if they're probably not used in the particular case of Grub, the small test compiled by configure does require them.

My 2 cts...

Small Changes in configure file
 

To Solve this error just do minute changes in configure file

Below is the Snippet of configure file:

echo $ECHO_N "checking whether ${OBJCOPY} works for absolute addresses...
....
....
for link_addr in 0x2000 0x8000 0x7C00; do
....
....
if { ac_try='${OBJCOPY-objcopy} --only-section=.text -O binary conftest.exec conftest'
....
....



The Lines with Bold Should be replaced.

I had this problem when compiling grub4dos (for glrdr). Adding --only-section=.text to configure didn't solve all problems, as it's referenced elsewhere in the Makefile.in files. Obviously the configure test is there for a reason. Quickest solution was to write a bash script called objcopy containing "/usr/bin/objcopy --only-section=.text $@" and add it to the start of PATH env var.

Grub still fails to build, as the new .note.gnu.build-id section gets in the way. I tried using the newer binutils with -Wl,--build-id=none to remove the section, but it produced an invalid grub binary. Eventually I installed binutils version 2.10.1 (using --prefix). To get binutils 2.10.1 to build with gcc 4.7, I had to replace some variable arrays [] with pointers.

Then there's a trick - to get grub4dos to build with gcc 4.7, you need to run configure with the system installed version of binutils as gcc47 will call as with option --32 which the older as won't understand. Then export LDFLAGS="-B <path to binutils 2.10.1>", and run make. Ugly, but it works.

This is a rather old thread, but might still be relevant to some people (like me).

I am building an embedded linux on Ubuntu 16 with PTXdist, which wants to use grub 0.97. The binutils from ubuntu are too new for it to work. Rather than downgrading anything, I wanted a solution that works without much hassle. So I looked into your solution. But since PTXdist uses autoconf, it would always rewrite the edited configure file, reverting my changes again.

The absolute solution for this was to change the acinclude.m4 file. This one has the exact same lines as the configure file. I edited them and then grub just built fine on the recent development tools. So cheers and good luck to other people having the same issues.