Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Rbutil
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version RBUtil 1.0.6
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by scottie - 2008-08-17
Last edited by bluebrother - 2008-11-22

FS#9291 - Rockbox Utility SEGV on Linux

lapss» bzip2 -dc rbutilqt-v1.0.6.tar.bz2| tar xvf -
rbutilqt-v1.0.6/
rbutilqt-v1.0.6/rbutilqt
lapss» cd rbutilqt-v1.0.6/
lapss» ./rbutilqt
zsh: floating point exception ./rbutilqt
lapss(sigFPE)» uname -a
Linux lapss 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 i686 i386 GNU/Linux
lapss» cat /etc/fedora-release
Fedora Core release 4 (Stentz)

Closed by  bluebrother
2008-11-22 10:09
Reason for closing:  Not a Bug
Additional comments about closing:  

This is an issue with the provided binary, not a bug. We can't make sure the linux binary runs on every outdated distro around.
Rockbox Utility itself is statically linked – against Qt. Linking statically against system libraries would make the binary size explode with minimal gain – it works fine on recent distros.

Please post the output of ldd ./rbutil. Also, please recompile yourself – your distribution is heavily outdated, and due to constantly changing libraries etc. on linux it is almost impossible to create a binary that runs on all systems.

Please post the output of ldd ./rbutil.

lapss» ldd ./rbutilqt-v1.0.6/rbutilqt
/usr/bin/ldd: line 124: 17323 Floating point exceptionLD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= “$@”

Also, please recompile yourself

How? Where is the source code & instructions to build it?

your distribution is heavily outdated

Fedora 4 was released 3 years ago.

and due to constantly changing libraries etc. on linux it is almost impossible to create a binary that runs on all systems.

Perhaps a statically-linked binary would be less likely to have these problems?

Scott. :)

Your ldd failing is rather strange. Please check if you don’t have a broken download or a broken ldd.

How? Where is the source code & instructions to build it?

The Rockbox Utility wiki page has a direct link to the development wiki page which has exact instructions. Please look first …

Fedora 4 was released 3 years ago.

This doesn’t mean it’s not outdated in the linux world. Even FC5 had EOL over a year ago.

Perhaps a statically-linked binary would be less likely to have these problems?

The binary *is* statically linked. You just can’t link the binary statically against every library in a sensible way …

Please check if you don’t have a broken download or a broken ldd.

ldd seems to work ok with other binaries.

lapss» ldd /bin/ls

      linux-gate.so.1 =>  (0x002ce000)
      librt.so.1 => /lib/librt.so.1 (0x0098e000)
      libacl.so.1 => /lib/libacl.so.1 (0x00bfd000)
      libselinux.so.1 => /lib/libselinux.so.1 (0x04ffd000)
      libc.so.6 => /lib/libc.so.6 (0x00aa5000)
      libpthread.so.0 => /lib/libpthread.so.0 (0x00de9000)
      /lib/ld-linux.so.2 (0x00a87000)
      libattr.so.1 => /lib/libattr.so.1 (0x0061f000)

I agree that it is strange - ldd shouldn’t crash when given a binary with an unexpected format.

The Rockbox Utility wiki page has a direct link to the development wiki page which has exact instructions. Please look first …

I did look first, but I couldn’t find it easily. Not whinging, just offering feedback on my experience as an end user.

I gave up trying to recompile rbutil - too many dependencies (svn, Qt >4.3, etc.) … I just want to install RockBox on my MP3 player.

The binary *is* statically linked.

lapss» file rbutilqt
rbutilqt: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped

According to “file” the rbutilqt binary is dynamically linked.

You just can’t link the binary statically against every library in a sensible way …

I must be missing something. I thought the point of a statically linked library is that the binary can run almost anywhere because it doesn’t have any shared library dependencies?

Anyway, I decided to circumvent the problem by running rbutilqt on a different Linux distribution (SuSE 10.1). Imagine my surprise:

ss@silkie:/tmp/rbutilqt-v1.0.6> ./rbutilqt
./rbutilqt: /usr/lib/libpng12.so.0: no version information available (required by ./rbutilqt)
zsh: 5046 floating point exception ./rbutilqt
ss@silkie:/tmp/rbutilqt-v1.0.6> cat /etc/SuSE-release
SUSE LINUX 10.1 (i586)
VERSION = 10.1
ss@silkie:/tmp/rbutilqt-v1.0.6> ldd ./rbutilqt
./rbutilqt: /usr/lib/libpng12.so.0: no version information available (required by ./rbutilqt)

      linux-gate.so.1 =>  (0xffffe000)
      libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7f4a000)
      libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7f41000)
      libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7f29000)
      libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb7f21000)
      libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7eb4000)
      libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7e7b000)
      libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7e6c000)
      libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7d75000)
      libz.so.1 => /lib/libz.so.1 (0xb7d63000)
      libgthread-2.0.so.0 => /opt/gnome/lib/libgthread-2.0.so.0 (0xb7d5f000)
      librt.so.1 => /lib/librt.so.1 (0xb7d56000)
      libglib-2.0.so.0 => /opt/gnome/lib/libglib-2.0.so.0 (0xb7cd0000)
      libdl.so.2 => /lib/libdl.so.2 (0xb7ccb000)
      libpthread.so.0 => /lib/libpthread.so.0 (0xb7cb7000)
      libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7bd7000)
      libm.so.6 => /lib/libm.so.6 (0xb7bb2000)
      libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ba7000)
      libc.so.6 => /lib/libc.so.6 (0xb7a87000)
      libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7a67000)
      /lib/ld-linux.so.2 (0xb7fa4000)

can you please check the version of your installed libpng and the version information in the file (readelf -V /usr/lib/libpng12.so)? I have the impression that this has something to do with this version info error.

Reports from IRC:
- rbutil runs fine with libpng 1.2.27-1 on kubuntu 8.10 alpha 5
- it doesn’t run on etch, due to a wrong glibc version I think

"./rbutilqt: /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.4' not found (required by ./rbutilqt)"
can you please check the version of your installed libpng

ss@silkie:~> rpm -q -a libpng
libpng-1.2.8-17

and the version information in the file (readelf -V /usr/lib/libpng12.so)?

ss@silkie:~> readelf -V /usr/lib/libpng12.so | grep -i version
Version symbols section ‘.gnu.version’ contains 419 entries:
Version needs section ‘.gnu.version_r’ contains 2 entries:

000000: Version: 1  File: libm.so.6  Cnt: 1
0x0010:   Name: GLIBC_2.0  Flags: none  Version: 4
0x0020: Version: 1  File: libc.so.6  Cnt: 4
0x0030:   Name: GLIBC_2.1.3  Flags: none  Version: 6
0x0040:   Name: GLIBC_2.4  Flags: none  Version: 5
0x0050:   Name: GLIBC_2.3.4  Flags: none  Version: 3
0x0060:   Name: GLIBC_2.0  Flags: none  Version: 2

please check if m1.0.5 runs fine – it was build on an older distro (F5 to be exact).

I tried a 64-bit version of rbutil on a Centos 5 system - worked fine! Now I have RockBox on my MP3 player at last! :)

please check if m1.0.5 runs fine

lapss» ./rbutilqt
./rbutilqt: /lib/libc.so.6: version `GLIBC_2.4’ not found (required by ./rbutilqt)

The program terminated, but didn’t crash.

I don’t understand why rbutilqt isn’t statically linked - wouldn’t that avoid all the problems I’ve had?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing