lmbench gnu-os script finds a different arm system name than the one that was built for

Bug #683795 reported by Ricardo Salveti on 2010-12-01
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lmbench (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: lmbench

Lmbench uses a script called "os", that then calls "gnu-os" to find the configuration name of the system while building and running lmbench.

When building, the result is used to deploy the bin files in a directory with the same system configuration name. While running lmbench it then uses the same script to find the correct location of the bin files.

Problem is that for Lucid, Maverick and Natty the target ARM system is an armv7 compatible board, and the package was built during Karmic time, using an armv5 machine as builder. The same package was copied to later distro revisions without rebuilding it.

Example, in Maverick:
Lmbench bin directory: /usr/lib/lmbench/bin/armv5tel-linux-gnu
OS script output: armv7l-linux-gnu

Then when you run lmbench-run it will give many error messages, saying it can find the scripts used during configuration:
# lmbench-run
...
Hang on, we are calculating your timing granularity.
./config-run: 138: /usr/lib/lmbench/bin/armv7l-linux-gnu/msleep: not found
./config-run: 139: /usr/lib/lmbench/bin/armv7l-linux-gnu/enough: not found
OK, it looks like you can time stuff down to usec resolution.

Hang on, we are calculating your timing overhead.
./config-run: 144: /usr/lib/lmbench/bin/armv7l-linux-gnu/msleep: not found
./config-run: 145: /usr/lib/lmbench/bin/armv7l-linux-gnu/timing_o: not found
OK, it looks like your gettimeofday() costs usecs.

Hang on, we are calculating your loop overhead.
./config-run: 150: /usr/lib/lmbench/bin/armv7l-linux-gnu/msleep: not found
./config-run: 151: /usr/lib/lmbench/bin/armv7l-linux-gnu/loop_o: not found
OK, it looks like your benchmark loop costs usecs.
...

Just rebuilding the package makes it work fine.

tags: added: armel
Loïc Minier (lool) wrote :

It would be ok to rely on the triplet staying the same, but expecting uname to be the same at build time and runtime is just wrong :-/

Oliver Grawert (ogra) wrote :

not if you port the package to dkms ;)

Steve Langasek (vorlon) on 2011-02-16
tags: added: arm-porting-queue
Marcin Juszkiewicz (hrw) wrote :

Do we really want to invest time in benchmark which is now 6 years old? probably easiest would be "s/uname -m/dpkg-architecture -qDEB_HOST_ARCH/" which would have to be kept as upstream is rather dead now.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers