Bruno Haible <[email protected]> writes:
> Hi Collin,
>
>> > Once you are done with that: Maybe it would make sense to install GNU grep
>> > from source; then you should be able to build a testdir of all of Gnulib?
>>
>> Well, you would have to run ./configure in GNU grep's tarball which
>> wouldn't work. :)
>>
>> I did end up finding a workaround, though. Using an Alpine container
>> since it is easier to start than the QNX VM and both use 'apk':
>>
>> $ podman run --rm -it alpine:latest
>> $ cd /tmp && apk fetch grep
>> Downloading grep-3.12-r0
>> $ tar -xf grep-3.12-r0.apk
>> $ ls bin
>> egrep fgrep grep
>
> Hmm. Which kernel is used inside this Alpine container? Linux probably?
> Whereas inside the QNX VM, it would be the QNX microkernel, right?
>
> The point of running the Gnulib test suite in the QNX VM would be to
> exercise the QNX system calls and see how compatible they are with POSIX
> and GNU. But when you are in a container, what would you be testing
> exactly?
Sorry if I explained it poorly. I was too lazy to start the QNX VM, and
just showed my work around to install packages in an Alpine Linux
container since they use the same package manager. I wasn't meaning to
imply that Gnulib tests should be run there.
Now I have my VM up I can show you the issue. Here is what happens when
I try to install GNU grep, logged in as the root user:
$ apk update
ERROR: Unable to read database: No such file or directory
ERROR: Failed to open apk database: No such file or directory
$ apk add grep
ERROR: Unable to read database: No such file or directory
ERROR: Failed to open apk database: No such file or directory
$ apk fix
ERROR: Unable to read database: No such file or directory
ERROR: Failed to open apk database: No such file or directory
I am not sure why anyone would print strerror (ENOENT) without a file
name associated with it. That would make life much easier, but whatever.
Here is what happens when you try to configure GNU grep from source:
$ curl --silent --location --remote-name \
https://mirrors.ocf.berkeley.edu/gnu/grep/grep-3.12.tar.xz
$ echo $?
0
$ tar -xf grep-3.12.tar.xz
$ cd grep-3.12
$ ./configure
[...]
checking for gcc option to enable C23 features... grep: bad regex '^ *+':
Invalid use of repetition operators
[...]
checking for error.h... grep: bad regex '^ *+': Invalid use of repetition
operators
no
checking for fnmatch.h... yes
checking for stdio_ext.h... grep: bad regex '^ *+': Invalid use of
repetition operators
no
checking for sys/vfs.h... grep: bad regex '^ *+': Invalid use of repetition
operators
[...]
Actually, I do notice now that despite the 'grep' errors the result of
the checks seems correct, at least enough so that the subsequent 'make'
suceeds.
Before noticing that, the work around I mentioned in my previous message
would work:
$ apk update && apk fetch grep
ERROR: Unable to read database: No such file or directory
ERROR: Failed to open apk database: No such file or directory
$ apk fetch grep
Downloading grep-3.11-r0
$ ls -d ./usr/bin/grep
ls: ./usr/bin/grep: No such file or directory
$ tar -xf grep-3.11-r0.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
$ ./usr/bin/grep --version | head -n 1
grep (GNU grep) 3.11
Collin
