[SOLVED]unable to initialize decompress status for section .debug_info

aleixrocks · 2018-12-16 11:17:12

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)

loqs · 2018-12-16 11:38:11

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)

aleixrocks · 2018-12-16 13:31:05

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)

osandov · 2018-12-19 23:36:20

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.

oz · 2018-12-22 03:25:34

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)

eschwartz · 2018-12-23 02:49:21

oz wrote:

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.

https://bugs.archlinux.org/task/61151

anatolik · 2018-12-26 07:01:30

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?

eschwartz · 2018-12-26 15:07:33

aleixrocks wrote:

Yes, I was building the kernel with CONFIG_DEBUG_INFO

anatolik · 2018-12-26 17:32:02

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.

lightsmile · 2019-02-15 09:01:51

osandov wrote:

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)

anatolik · 2019-02-15 14:45:01

lightsmile wrote:

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.

fx101 · 2019-02-17 23:21:35

@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.

loqs · 2019-02-17 23:50:01

@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.

sobota · 2019-03-08 21:55:54

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)

loqs · 2019-03-08 22:48:05

sobota wrote:

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?

Ekami · 2019-03-09 20:12:26

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)

hhatefi · 2019-03-30 21:53:22

I had the same issue while running:

pip install ujson

The problem solved by downgrading binutils.

Ekami · 2019-07-25 04:11:27

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

anatolik · 2019-07-25 04:17:08

Why do you want to use the third-party binaries if the official Arch version already fixed this issue long time ago?

shilka · 2019-09-19 01:50:32

anatolik wrote:

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)

loqs · 2019-09-19 02:23:15

@shika can you please provide detailed instructions to reproduce the issue.

shilka · 2019-09-19 07:00:25

@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)

jasonwryan · 2019-09-19 07:05:07

shilka: none of this has anything to do with pacman or the Arch repos...

shilka · 2019-09-19 07:29:57

@jasonwryan yep, but it do caused by the binutils's update.

jasonwryan · 2019-09-19 08:02:55

Nope: you are using AUR and Pip.

Closing

Arch Linux

#1 2018-12-16 11:17:12

[SOLVED]unable to initialize decompress status for section .debug_info

#2 2018-12-16 11:38:11

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#3 2018-12-16 13:31:05

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#4 2018-12-19 23:36:20

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#5 2018-12-22 03:25:34

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#6 2018-12-23 02:49:21

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#7 2018-12-26 07:01:30

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#8 2018-12-26 15:07:33

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#9 2018-12-26 17:32:02

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#10 2019-02-15 09:01:51

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#11 2019-02-15 14:45:01

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#12 2019-02-17 23:21:35

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#13 2019-02-17 23:50:01

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#14 2019-03-08 21:55:54

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#15 2019-03-08 22:48:05

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#16 2019-03-09 20:12:26

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#17 2019-03-30 21:53:22

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#18 2019-07-25 04:11:27

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#19 2019-07-25 04:17:08

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#20 2019-09-19 01:50:32

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#21 2019-09-19 02:23:15

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#22 2019-09-19 07:00:25

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#23 2019-09-19 07:05:07

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#24 2019-09-19 07:29:57

Re: [SOLVED]unable to initialize decompress status for section .debug_info

#25 2019-09-19 08:02:55

Re: [SOLVED]unable to initialize decompress status for section .debug_info

Board footer