configure: error: GRUB requires a working absolute objcopy; upgrade your binutils
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
Code:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking whether optimization for size works... yes
checking whether gcc has -fno-stack-protector... yes
checking whether -Wundef works... yes
checking whether -falign-loops works... yes
checking for objcopy... objcopy
checking if C symbols get an underscore after compilation... no
checking whether objcopy works for absolute addresses... no
configure: error: GRUB requires a working absolute objcopy; upgrade your binutils
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 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.
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.
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?
Last edited by The00Dustin; 05-27-2008 at 08:44 AM.
Reason: re-ordered sentences for easier read
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:
Code:
./configure --prefix=/hd/usr CC=gcc34
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.
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:
Code:
./configure CC=gcc34
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 :
Code:
./configure --prefix=/usr --enable-diskless --enable-rtl8139 CC=gcc34
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc34
checking for gcc... (cached) gcc34
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
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 ?
@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.
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'
....
....
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.