#25 disk.c:(.text+0x2f): undefined reference to `llseek'
Opened 3 years ago by alciregi. Modified 2 years ago

Fedora 29
4.18.3-300.fc29.x86_64

Running with -t performance I get

/usr/bin/ld: /tmp/cckYRPo4.o: in function `seekto':
disk.c:(.text+0x2f): undefined reference to `llseek'
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:321: ../bin/x86_64-linux-gnu/disk] Error 1
make[1]: *** [Makefile:114: lmbench] Error 2
make: *** [Makefile:20: build] Error 2
/usr/bin/ld: /tmp/ccLzfARo.o: in function `seekto':
disk.c:(.text+0x2f): undefined reference to `llseek'
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:321: ../bin/x86_64-linux-gnu/disk] Error 1
make[1]: *** [Makefile:114: lmbench] Error 2
make: *** [Makefile:23: results] Error 2
./performance/lmbench3                                           PASS

I'm seeing this too. This is a regression as it works nicely on 28.

Well, not a regression in the test suite, but a change in the distro. I will look into it today and see if I can find something that works for both.

I've fixed this locally with the following changes to disk.c (lmbench source)

Defined __USE_FILE_OFFSET64 before including "unistd.h"

#ifdef  __linux__
#define __USE_FILE_OFFSET64
#endif
#include    <unistd.h>

Removed the prototype for llseek() in the seekto() function and replaced the call with a call to lseek() which as far as I can tell from the "unistd.h" header will result to a call to lseek64() when __USE_FILE_OFFSET64 is defined.

int
seekto(int fd, uint64 off)
{
#ifdef  __linux__
    if (lseek(fd, (__off64_t)off, SEEK_SET) == (__off64_t)-1) {
        return(-1);
    }
    return (0);
#else
    uint64  here = 0;

    lseek(fd, 0, 0);
    while ((uint64)(off - here) > (uint64)BIGSEEK) {
        if (lseek(fd, BIGSEEK, SEEK_CUR) == -1) break;
        here += BIGSEEK;
    }
    assert((uint64)(off - here) <= (uint64)BIGSEEK);
    if (lseek(fd, (int)(off - here), SEEK_CUR) == -1) return (-1);
    return (0);
#endif
}

I've tested the change on both Fedora 28 and 29 but unfortunately as I am not an experienced Linux developer I don't have the confidence (or knowledge) to submit a patch but thought that it might be useful for anyone looking into the issue. Perhaps someone with more experience can check to make sure it's the correct solution and won't break anything else.

If using lseek() (lseek64()) is the right solution going forward there's probably some additional clean up required to switch from using the locally defined "off64_t" type to "__off64_t" but I am unsure of the implications of checking the "sgi" define and changing the following.

#ifndef sgi
#define NO_LSEEK64
#define off64_t long long
#endif

I've forked the repo and committed a fix for this. I'll submit a pull request once I have it tested if that's ok?

I still got this error when issuing the command sudo ./runtests.sh -t performance, using the test iso image for the Kernel 5.0 Test Day (Linux localhost-live 5.0.1-300.fc30.x86_64 #1 SMP Mon Mar 11 04:27:50 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux)

Prior to this i also got permission error and had to chmod +x on two files "./performance/lmbench3/scripts/getlist and ./performance/lmbench3/scripts/getsummary" I dont see an open issue about this, should i open one for that?

Login to comment on this ticket.

Metadata