You are not logged in.
Pages: 1
Topic closed
Hi!
I used to compile the mainland's Linux Kernel without problems but after upgrading arch I'm getting the following warnings which apparently lead to a compilation failure:
[...]
objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info
objdump: kernel/.tmp_signal.o: unable to initialize decompress status for section .debug_info
objdump: kernel/.tmp_signal.o: file format not recognized
CC arch/x86/kernel/platform-quirks.o
objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info
objdump: arch/x86/kernel/.tmp_ebda.o: unable to initialize decompress status for section .debug_info
objdump: arch/x86/kernel/.tmp_ebda.o: file format not recognized
objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info
objdump: mm/.tmp_swap_slots.o: unable to initialize decompress status for section .debug_info
objdump: mm/.tmp_swap_slots.o: file format not recognized
LDS arch/x86/kernel/vmlinux.lds
CC mm/frontswap.o
CC kernel/umh.o
objdump: arch/x86/kernel/.tmp_platform-quirks.o: unable to initialize decompress status for section .debug_info
objdump: arch/x86/kernel/.tmp_platform-quirks.o: unable to initialize decompress status for section .debug_info
objdump: arch/x86/kernel/.tmp_platform-quirks.o: file format not recognized
AR arch/x86/kernel/built-in.a
make[1]: *** [/home/aleix/projects/kernel/kernel/kernel/linux/Makefile:1060: arch/x86] Error 2
make[1]: *** Waiting for unfinished jobs....
[...]
I have seen a similar bug report on the gentoo forum, but seems weird that nobody else had reported it before in arch. Anyways I tried downgrading elfutils as well. However, I'm getting warned of unresolvable dependencies which scared me off.
(ins)[aleix@arks ~]$ sudo pacman -U /var/cache/pacman/pkg/elfutils-0.174-1-x86_64.pkg.tar.xz
loading packages...
warning: downgrading package elfutils (0.175-1 => 0.174-1)
resolving dependencies...
warning: cannot resolve "libelf=0.174-1", a dependency of "elfutils"
:: The following package cannot be upgraded due to unresolvable dependencies:
elfutils
:: Do you want to skip the above package for this upgrade? [y/N]
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libelf=0.174-1' required by elfutils
So I guess the safest option (apart from doing nothing and wait for the next update ) is to downgrade the entire system, right? Otherwise, what would you recommend me to solve the compilation problem?
Thank you!!!
Last edited by aleixrocks (2018-12-16 13:31:49)
Offline
elfutils and libelf would need to be downgraded together. Alternatively can you try building in a clean chroot without elfutils (the kernel package requires libelf only)
https://sourceware.org/bugzilla/show_bug.cgi?id=23919
Edit:
The build with the issue has CONFIG_DEBUG_INFO enabled?
Last edited by loqs (2018-12-16 11:57:42)
Offline
Hi loqs!
Yes, I was building the kernel with CONFIG_DEBUG_INFO
Downgrading both elfutils and libelf at the same time did the trick! I will also keep in mind the idea of using a chroot for the next time.
For the record, I used the command:
sudo pacman -U /var/cache/pacman/pkg/elfutils-0.174-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/libelf-0.174-1-x86_64.pkg.tar.xz
Thank you very much!
Last edited by aleixrocks (2018-12-16 13:33:32)
Offline
I ran into this as well, and it appears to be a binutils bug which was exposed by a libelf change. So, it should be safe to update elfutils/libelf again once binutils 2.32 is released.
Offline
Now my server is borked because I need to compile SCST for my diskless clients and it won't compile now. No machines on my network can boot!
Why was elfutils updated before binutils 2.32 was ready? This is crazy.
Edit:
OK, found the official archive to downgrade.
Last edited by oz (2018-12-22 03:31:17)
Offline
Now my server is borked because I need to compile SCST for my diskless clients and it won't compile now. No machines on my network can boot!
Why was elfutils updated before binutils 2.32 was ready? This is crazy.
Um, because there was a bug and it was only discovered after elfutils was updated, obviously. Sometimes bugs happen.
By the way, no one reported this bug while elfutils was in the testing repo, or I guess we wouldn't have moved it to core... It's regrettable that no one actually utilizing the specific compiler options that trigger this bug, was opting into the use of the testing repos in order to report the bug.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
You said that you have a problem compiling Linux sources.
So I checked out Linux master tree v4.20-2953-g5694cecdb092 at my up-to-date Arch machine with [testing] repo enabled.
then
zcat /proc/config.gz > .config
yes '' | make oldconfig
make -j8
and it compiled without any problems. So I am confused how did you able to trigger this problem.
Could you please provide step-by-step instructions to repro the issue?
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
Yes, I was building the kernel with CONFIG_DEBUG_INFO
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Awesome. Thank you for the help. A patched version of binutils been pushed to the testing repo. Please pull binutils update and see if it fixes the original issue.
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
I ran into this as well, and it appears to be a binutils bug which was exposed by a libelf change. So, it should be safe to update elfutils/libelf again once binutils 2.32 is released.
Thanks too much for osandov's reply, I have solved the problem by installing binutils-2.30
Last edited by lightsmile (2019-02-15 09:06:42)
Offline
Thanks too much for osandov's reply, I have solved the problem by installing binutils-2.30
https://bugs.archlinux.org/task/61151 bug is fixed so you don't need to downgrade binutils anymore.
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
@anatolik this is not fixed, actually. I still get the same issue with libelf-0.175-1, elfutils-0.175-1, and binutils-2.31.1-4.
Offline
@fx101 why did you not request https://bugs.archlinux.org/task/61151 be reopened?
I have just built 4.20.10 with CONFIG_DEBUG_INFO enabled all dependent options left as default without encountering the issue.
Offline
I encounter this problem during installation of python package, solve this problem by:
sudo pacman -U https://archive.archlinux.org/packages/e/elfutils/elfutils-0.174-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/libelf-0.174-1-x86_64.pkg.tar.xz
sudo pacman -U https://archive.archlinux.org/packages/b/binutils/binutils-2.30-5-x86_64.pkg.tar.xz
Last edited by sobota (2019-03-08 21:56:52)
Offline
I encounter this problem during installation of python package
What command were you using to install the python package and what output did it produce?
Offline
I'm affected by the same issue, using:
sudo pacman -U https://archive.archlinux.org/packages/e/elfutils/elfutils-0.174-1-x86_64.pkg.tar.xz https://archive.archlinux.org/packages/l/libelf/libelf-0.174-1-x86_64.pkg.tar.xz
sudo pacman -U https://archive.archlinux.org/packages/b/binutils/binutils-2.30-5-x86_64.pkg.tar.xz
Also helped me solve this issue
Last edited by Ekami (2019-03-31 16:59:45)
Offline
I had the same issue while running:
pip install ujson
The problem solved by downgrading binutils.
Offline
New links:
sudo pacman -U http://archlinux.arkena.net/archive/packages/e/elfutils/elfutils-0.174-1-x86_64.pkg.tar.xz http://archlinux.arkena.net/archive/packages/l/libelf/libelf-0.174-1-x86_64.pkg.tar.xz
sudo pacman -U http://archlinux.arkena.net/archive/packages/b/binutils/binutils-2.30-5-x86_64.pkg.tar.xz
Offline
Why do you want to use the third-party binaries if the official Arch version already fixed this issue long time ago?
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
Why do you want to use the third-party binaries if the official Arch version already fixed this issue long time ago?
Actually not, I meet the same bug when compiling the python wrapper of ta-lib on binutils 2.32-2, but binutils 2.30 works fine. May be we should reopen the closed bug report?
Last edited by shilka (2019-09-19 01:55:06)
Offline
@shika can you please provide detailed instructions to reproduce the issue.
Offline
@loqs Of course, first install aur/ta-lib, then using "pip install TA-Lib" install the python wrapper. pip would automatically compiling source files and after a while you would catch the error message like "........o: file format not recognized ".
btw. I'm on Arch x86_64, using python3.7 in anaconda environment.
The detail of this problem could be found at:
https://github.com/mrjbq7/ta-lib/issues/260
Last edited by shilka (2019-09-19 07:41:29)
Offline
shilka: none of this has anything to do with pacman or the Arch repos...
Offline
@jasonwryan yep, but it do caused by the binutils's update.
Offline
Nope: you are using AUR and Pip.
Closing
Offline
Pages: 1
Topic closed