public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Work in progress
Date: Wed, 07 Apr 2021 16:01:28 +0200	[thread overview]
Message-ID: <eeebd7d7-a13e-a1c6-d172-361668de67bd@ipfire.org> (raw)
In-Reply-To: <1cc9cada-865e-84f9-513d-8f2f0ed19837@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 6922 bytes --]

Hi all,

On 06/04/2021 14:43, Adolf Belka wrote:
> Hi Michael,
>
> On 06/04/2021 12:21, Michael Tremer wrote:
>> Hi,
>>
>> It looks like cap_text.c is missing to include stddef.h. That is where size_t is defined.
>>
>> I just merged the libcap, so you can give this another try.
>
> I just found a bug entry in Gentoo from 2017 for the same issue I found of gperf-3.1 with libcap-2.25
> Apparently gperf is called in the makefile to generate a hash table lookup and if gperf is not available libcap falls back to using a plain list of cap names, so it is not essential to use gperf.
>
> I just checked and the gperf call is no longer in the makefile for libcap-2-49 so the new libcap version should solve things.
> I will retry the build and let you know how it goes.
>
The build of gperf-3.1 went without any problems with libcap-2.49

The only think I found was that there was a message "Changes in libcap-2.49 check rootfile!" and there were a lot of lines with +usr/share/gocode/src/kernel.org/pub/linux/libs/security/libcap.....


A patch for the update of gperf will be submitted shortly.

Regards,

Adolf.

> Thanks and regards,
> Adolf.
>>
>> Best,
>> -Michael
>>
>>> On 5 Apr 2021, at 15:44, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi All,
>>>
>>> I had failures with building libcap-2.25 with the new gperf. From the fail messages I can see that the libcap build calls gperf and is finding unknown type names in the response.
>>>
>>> I have seen that Matthias has updated libcap and submitted the patch.
>>>
>>> I will wait till the updated libcap is merged and then redo my gperf build and see if that solves the problem. Until then I have excluded gperf from my current builds.
>>>
>>> Here is the log output from building libcap with gperf updated from 3.0.4 (2009) to 3.1 (2017).
>>>
>>> Apr  5 13:45:53: Building libcap libcap-2.25.tar.xz checksum OK
>>> + cd /usr/src/lfs
>>> + make -f libcap LFS_BASEDIR=/usr/src install
>>> ====================================== Installing libcap-2.25 ...
>>> Install started; saving file list to /usr/src/lsalr ...
>>> # Prevent a static library from being installed
>>> cd /usr/src/libcap-2.25 && sed -i '/install.*STALIBNAME/d' libcap/Makefile
>>> cd /usr/src/libcap-2.25 && make
>>> make[1]: Entering directory '/usr/src/libcap-2.25'
>>> make -C libcap all
>>> make[2]: Entering directory '/usr/src/libcap-2.25/libcap'
>>> => making cap_names.list.h from /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
>>> perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ \t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print "{\"$tok\",$val},\n"; } }' /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | fgrep -v 0x > cap_names.list.h
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames
>>> ./_makenames > cap_names.h
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_alloc.c -o cap_alloc.o
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_proc.c -o cap_proc.o
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_extint.c -o cap_extint.o
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_flag.c -o cap_flag.o
>>> perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);\n%}\n%%\n"; while ($l = <>) { $l =~ s/[\{\"]//g; $l =~ s/\}.*// ; print $l; }' < cap_names.list.h | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20  > _caps_output.gperf
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -include _caps_output.gperf -c cap_text.c -o cap_text.o
>>> In file included from <command-line>:
>>> ./_caps_output.gperf:71:80: error: unknown type name 'size_t'
>>>     71 | gperf_case_strncmp (register const char *s1, register const char *s2, register size_t n)
>>> | ^~~~~~
>>> ./_caps_output.gperf:96:53: error: unknown type name 'size_t'
>>>     96 | __cap_hash_name (register const char *str, register size_t len)
>>>        | ^~~~~~
>>> ./_caps_output.gperf:200:55: error: unknown type name 'size_t'
>>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>>        | ^~~~~~
>>> ./_caps_output.gperf:200:1: error: conflicting types for '__cap_lookup_name'
>>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>>        | ^~~~~~~~~~~~~~~~~
>>> ./_caps_output.gperf:33:29: note: previous declaration of '__cap_lookup_name' was here
>>>     33 | const struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);
>>>        |                             ^~~~~~~~~~~~~~~~~
>>> make[2]: *** [Makefile:63: cap_text.o] Error 1
>>> make[2]: Leaving directory '/usr/src/libcap-2.25/libcap'
>>> make[1]: *** [Makefile:12: all] Error 2
>>> make[1]: Leaving directory '/usr/src/libcap-2.25'
>>> make: *** [libcap:75: /usr/src/log/libcap-2.25] Error 2
>>>
>>> On 05/04/2021 13:36, Adolf Belka wrote:
>>>> Hi all,
>>>>
>>>> For information I am working on the following updates:-
>>>>
>>>> gettext
>>>> gmp
>>>> go
>>>> gperf
>>>> grep
>>>> libmpc
>>>> mpc
>>>> mpd
>>>> zstd
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>> -- 
>>> Sent from my laptop
>>>
>>

  reply	other threads:[~2021-04-07 14:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 11:36 Adolf Belka
2021-04-05 14:44 ` Adolf Belka
2021-04-06 10:21   ` Michael Tremer
2021-04-06 12:43     ` Adolf Belka
2021-04-07 14:01       ` Adolf Belka [this message]
2021-04-07 14:59         ` Michael Tremer
  -- strict thread matches above, loose matches on Subject: below --
2021-04-01  7:51 Matthias Fischer
2021-04-01  9:59 ` Michael Tremer
2021-04-01 11:34   ` Matthias Fischer
2021-04-01 12:32     ` Michael Tremer
2020-11-21 10:33 Matthias Fischer
2020-11-23 11:29 ` Michael Tremer
2020-11-25 17:09   ` Matthias Fischer
2020-11-25 20:49     ` Michael Tremer
2020-11-26 18:20       ` Matthias Fischer
2020-06-09 15:24 Matthias Fischer
2020-06-10  8:35 ` Michael Tremer
2020-06-10 22:32   ` Matthias Fischer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eeebd7d7-a13e-a1c6-d172-361668de67bd@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox