Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Advertise on
[SOLVED] Need portable ioping executables
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

[SOLVED] Need portable ioping executables

teknolaizteknolaiz Member
edited November 2015 in Help

Hello fellow LET members,

I'm in need of portable ioping 0.9 executables in both architectures (32 and 64 bit).

I downloaded the ioping 0.9 source code and compiled it. It works... So reinstall the VPS and download this compiled 0.9 executable from my file server and it does not work.

So I either need a way to compile it so that it works on both 32 and 64 bit and that on every Linux distribution. It kinda smells like a dependency issue but I can't pinpoint it because the executable I compiled on Jessie 64 bit works with a fresh installation without build-essentail and libc6/libc6-dev. I'm using OpenVZ VPSs to test and compile with official minimal templates of Debian/CentOS/Fedora/Ubuntu.

Anyone here can help me to figure this out? I'm trying to build working ioping version for my bench-sh-2 script.

This are the executables I compiled: (compiled on Debian 6 32 Bit) (compiled on Debian 8 64 Bit)

I'm on vacation in Belize.


  • rincewindrincewind Member
    edited November 2015

    Did you build static binaries? Open the Makefile and at the end of the first line "CFLAGS" add "-static". So it should look like

    CFLAGS+=-std=gnu99 -g -Wall -Wextra -pedantic -O2 -funroll-loops -ftree-vectorize -static

    Then compile by running make. I tried it on Ubuntu 15.10 and got a static binary. To confirm, after compiling do ldd ioping. It should say something like

    ioping: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, .....

    If you build a dynamic library ldd will list the dependencies you need for your binary to run.

    EDIT: If compilation fails on adding -static, then remove -lrt from the second line of the Makefile - changing it to LIBS=-lm. And run 'make'

    Thanked by 2netomx teknolaiz
  • teknolaizteknolaiz Member
    edited November 2015

    @ricewind I'll try out your solutions and post updates.

    I tried to compile the 32 Bit version first with Debian 7 32 Bit. Used the latest release (0.9) from

    The first solution (added -static to the end of the first line) results in the message below when I try to execute the executable:

    ioping: ioping: cannot execute binary file

    Compiling process:

    [email protected]:~/ioping-0.9# make
    test ! -d .git || git describe --tags --dirty=+ | sed 's/^v//;s/-/./g' > version
    cc -o ioping ioping.o -std=gnu99 -g -Wall -Wextra -pedantic -O2 -funroll-loops -ftree-vectorize -static  -lm
    [email protected]:~/ioping-0.9# ldd ioping
            not a dynamic executable

    (the second line already is LIBS=-lm in the Makefile with my edits)

    If I add "-lrt" instead of "-lm" to LIBS I get this:

    [email protected]:~/ioping-0.9# make
    test ! -d .git || git describe --tags --dirty=+ | sed 's/^v//;s/-/./g' > version
    cc -o ioping ioping.o -std=gnu99 -g -Wall -Wextra -pedantic -O2 -funroll-loops -ftree-vectorize -static  -lrt
    ioping.o: In function `main':
    /root/ioping-0.9/ioping.c:1126: undefined reference to `sqrt'
    /root/ioping-0.9/ioping.c:1178: undefined reference to `sqrt'
    collect2: error: ld returned 1 exit status
    make: *** [ioping] Error 1

    EDIT: I removed -static again and compiled it with make. I can run the executable and get the help page of ioping with all parameters.

    [email protected]:~/ioping-0.9# make
    test ! -d .git || git describe --tags --dirty=+ | sed 's/^v//;s/-/./g' > version
    cc -o ioping ioping.o -std=gnu99 -g -Wall -Wextra -pedantic -O2 -funroll-loops -ftree-vectorize  -lm
    [email protected]:~/ioping-0.9# clear
    [email protected]:~/ioping-0.9# ./ioping
     Usage: ioping [-LABCDWRq] [-c count] [-w deadline] [-pP period] [-i interval]
                   [-s size] [-S wsize] [-o offset] directory|file|device
            ioping -h | -v
          -c       stop after  requests
          -w    stop after 
          -p      print raw statistics for every  requests
          -P      print raw statistics for every  in time
          -i    interval between requests (1s)
          -s        request size (4k)
          -S       working set size (1m)
          -o      working set offset (0)
          -k              keep and reuse temporary working file
          -L              use sequential operations (includes -s 256k)
          -A              use asynchronous I/O
          -C              use cached I/O
          -D              use direct I/O
          -W              use write I/O *DANGEROUS*
          -R              seek rate test (same as -q -i 0 -w 3 -S 64m)
          -B              print final statistics in raw format
          -q              suppress human-readable output
          -h              display this message and exit
          -v              display version and exit


    [email protected]:~/ioping-0.9# ldd ioping
   =>  (0xb7715000)
   => /lib/i386-linux-gnu/ (0xb76e9000)
   => /lib/i386-linux-gnu/ (0xb759a000)
            /lib/ (0xb7716000)

    I'm on vacation in Belize.

  • rincewindrincewind Member
    edited November 2015

    Dont see why you cant execute your static binary - unless it is being prevented/blocked on your target system. Can you try on a KVM? I didnt have issues with static binaries on either Arch Linux or Ubuntu, but then I have never used OpenVZ/Docker.

    You can work with your dynamic-linked executable - that last one you built, but you will need to replicate your binary dependencies (libm, libc and Ideally in some sort of chrooted environment, like a docker/lxc/openvz. The linux-gate or linux-vdso is a linux kernel dependency - so your target system will still need a similar linux kernel.

    EDIT: Just noticed that you are using an ancient Debian distro for 32-bit. If you compile on a system with linux kernel 2.x, the static binary may not work on linux 3.x or linux 4.x - the system calls may have changed or been re-numbered.

    EDIT2: If you work with far-apart kernel versions you can also run into ABI incompatibilities. ABI is the file-format for Unix executables.

    Thanked by 1teknolaiz
  • teknolaizteknolaiz Member
    edited November 2015


    1) I don't have any usable KVM to compile it or test it there.

    2) I understand. So there is no way to make it portable at all. Too many different things. A lot of dependencies, kernel versions and et cetera. This would go way out of the purpose behind bench-sh-2 being a simple to use script and only using that was is available and working on any Linux distribution.

    3) I tried Debian 6 (LTS), Debian 7 and Debian 8. Neither of them are really ancient. Debian 5 is ancient. Atleast personally I don't consider Debian 6 to be ancient as long as it has LTS status. 7 has a 3.x kernel and 8 also has a 3.x kernel. Kernel wise Debian 6 is really ancient though.

    Making this work would blow the top of the script after all. 2 is as its old version meant to be working on any Linux distribution because it uses what is available on pretty much any Linux distribution (sed, grep, echo, cut and et cetera).

    Thank you for your input ricewind. I'll be removing the iops test from the script. It's pointless to include it if the binary works here but for others it does not. It goes way too far away from the point of the script.

    @Jarland or @mpkossen please close this thread. Thank you.

    I'm on vacation in Belize.

  • @Hidden_Refuge Don't give up buddy :)

    Happy to be alive and kicking!

  • @vRozenSch00n said:
    Hidden_Refuge Don't give up buddy :)

    I'm not giving up.

    Would I make a extended script that involves a lot of extra software and et cetera I would certainly work on a solution to install necessary build tools and download the source code so it would get compiled in time when necessary for the benchmark.

    Bench is meant to be really simple and use what any Linux distribution has. I'm not even very happy about the Geekbench part but I added it as a feature. It may not always work due to missing 32 bit dependencies on 64 bit OSs. Thanks to Geekbench money hungry people who don't allow to run the 64 bit executable because it's not licensed.

    We're in 2015... and these morons live in what? 1990? Yeah... Screw them.

    Thanked by 1vRozenSch00n

    I'm on vacation in Belize.

  • Most modern machines support 64bits to take advantage of multi-threading and large memory system. How come they don't allow to run 64 bit executables.

    Doesn't make sense.

    Happy to be alive and kicking!

  • @vRozenSch00n said:
    Most modern machines support 64bits to take advantage of multi-threading and large memory system. How come they don't allow to run 64 bit executables.

    Doesn't make sense.

    Geekbench does not allow to run the 64 bit executable in "try out mode". You need a Geekbench license... Money all the monies.

    I'm on vacation in Belize.

  • Well, that's not so simple then, when you meant the script to be a simple to use, while the purpose itself is limited by a commercial license.

    Happy to be alive and kicking!

  • The Geekbench tool is 3rd party so... I don't care that much. Its license does not apply to bench-sh-2. It's declared as experimental in the script and it's clearly warned about that it may not work.

    I'm on vacation in Belize.

  • Dang! I'm on a max 30KB/sec connection right now. LET page take too long to load :( and then freezes.

    Happy to be alive and kicking!

  • rincewindrincewind Member
    edited November 2015

    Hidden_Refuge said: no way to make it portable

    Not exactly. You can have limited portability - within similar kernel versions. Just dont expect the same binary to work across long periods of time because of lack of backward compatibility. So maybe build one for Debian 6 (older kernels) and another for Debian 8 (newer kernels).

    If you are looking at getting some sort of minimal binary packaging - there are two ways

    • Use to pull in all shared libraries connected to a binary and build a Docker package of around 15 to 20 MB. Another software that takes a similar approach is Both should work in OpenVZ. This is closer to what you got working - a dynamic-linked binary and 3 shared libraries.

    • For KVM type environments, a new trend is to build Rump kernels.

    If you put in some coding work, you could have a script that detects kernel version, ABI etc and pulls in the right binaries and shared libraries from a prebuilt collection.

    I have been reading up on this stuff recently, even though I dont have an immediate need for binary packaging. So would be interested in any ideas that you come across..

    EDIT: I haven't tried any of these packages, just going from my understanding of how they are supposed to work

  • jarjar Provider

    Closed by OP request

    MagicSpam blackmails providers into buying their software, and ServerHub is a professional spam organization.

This discussion has been closed.