www.fabiankeil.de/blog-surrogat/2021/02/22/gatling-und-electrobsd.html
Zu Testzwecken wollte ich kürzlich gatling auf ElectroBSD installieren, musste aber feststellen, dass der FreeBSD-Port veraltet ist.
Außerdem warf der Compiler einen Haufen hässlicher Warnungen. Eine kleine Auswahl:
=>> Status www/gatling | gatling-0.15_2: build
=======================<phase: build >============================
===> Building for gatling-0.15_2
gmake[1]: Entering directory '/wrkdirs/usr/ports/www/gatling/work/gatling-0.15'
rm -f havesetresuid.h
(head -n 1 CHANGES | sed 's/\([^:]*\):/#define VERSION "\1"/') > version.h
if cc -O2 -pipe -I/usr/local/include/libowfat -I/usr/local/include -I/usr/local/include -g -fstack-protector-strong -fno-strict-aliasing -g -Og -DUSE_ZLIB -o tryresuid trysetresuid.c >/dev/null 2>&1; then echo "#define LI
BC_HAS_SETRESUID"; fi > havesetresuid.h
rm -f havealloca.h
echo "#include <stdlib.h>" > havealloca.h
if cc -O2 -pipe -I/usr/local/include/libowfat -I/usr/local/include -I/usr/local/include -g -fstack-protector-strong -fno-strict-aliasing -g -Og -DUSE_ZLIB -c tryalloca.c -DA >/dev/null 2>&1; then echo "#include <alloca.h
>"; fi >> havealloca.h
if cc -O2 -pipe -I/usr/local/include/libowfat -I/usr/local/include -I/usr/local/include -g -fstack-protector-strong -fno-strict-aliasing -g -Og -DUSE_ZLIB -c tryalloca.c -DB >/dev/null 2>&1; then echo "#include <malloc.h
>"; fi >> havealloca.h
rm -f tryalloca.o
cc -c mime.c -o mime.o -I. -O2 -pipe -I/usr/local/include/libowfat -I/usr/local/include -I/usr/local/include -g -fstack-protector-strong -fno-strict-aliasing -g -Og -DUSE_ZLIB
rm -f tryresuid
cc -c ftp.c -o ftp.o -I. -O2 -pipe -I/usr/local/include/libowfat -I/usr/local/include -I/usr/local/include -g -fstack-protector-strong -fno-strict-aliasing -g -Og -DUSE_ZLIB
ftp.c:42:11: warning: implicitly declaring library function 'alloca' with type 'void *(unsigned long)' [-Wimplicit-function-declaration]
char* x=alloca(l+str_len(s)+5);
^
ftp.c:42:11: note: include the header <stdlib.h> or explicitly provide a declaration for 'alloca'
cc -c http.c -o http.o -I. -O2 -pipe -I/usr/local/include/libowfat -I/usr/local/include -I/usr/local/include -g -fstack-protector-strong -fno-strict-aliasing -g -Og -DUSE_ZLIB
http.c:121:15: warning: implicitly declaring library function 'alloca' with type 'void *(unsigned long)' [-Wimplicit-function-declaration]
char* buf=alloca(fmt_urlencoded(0,s,len));
^
http.c:121:15: note: include the header <stdlib.h> or explicitly provide a declaration for 'alloca'
http.c:1479:18: warning: implicit declaration of function 'crypt' is invalid in C99 [-Wimplicit-function-declaration]
char* crypted=crypt(password,map+l+ul+1);
^
http.c:1479:10: warning: incompatible integer to pointer conversion initializing 'char *' with an expression of type 'int' [-Wint-conversion]
char* crypted=crypt(password,map+l+ul+1);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
http.c:3278:9: warning: implicitly declaring library function 'vfork' with type 'int (void)' [-Wimplicit-function-declaration]
int r=vfork();
^
http.c:3278:9: note: include the header <unistd.h> or explicitly provide a declaration for 'vfork'
http.c:3286:40: warning: implicit declaration of function 'chroot' is invalid in C99 [-Wimplicit-function-declaration]
if (chroot_to) { chdir(chroot_to); chroot(chroot_to); }
^
1 warning generated.
Um den gatling-Port zu aktualisieren musste erst mal die Abhängigkeit libowfat aktualisiert werden. Der FreeBSD-Port stand noch bei Version 0.31 obwohl Version 0.32 laut Website schon 2018 veröffentlicht wurde.
libowfat 0.32 ließ sich gar nicht ohne Patchen bauen. Erster Versuch:
clang -c io/iom_init.c -O2 -pipe -O2 -fomit-frame-pointer -g -fstack-protector-strong -fno-strict-aliasing -pipe -W -Wall -Wextra -D_REENTRANT -I.
io/iom_init.c:16:9: warning: implicit declaration of function 'fcntl' is invalid in C99 [-Wimplicit-function-declaration]
if (fcntl(c->ctx,F_SETFD,FD_CLOEXEC) == -1) {
^
io/iom_init.c:16:22: error: use of undeclared identifier 'F_SETFD'
if (fcntl(c->ctx,F_SETFD,FD_CLOEXEC) == -1) {
^
io/iom_init.c:16:30: error: use of undeclared identifier 'FD_CLOEXEC'
if (fcntl(c->ctx,F_SETFD,FD_CLOEXEC) == -1) {
^
io/iom_init.c:17:7: warning: implicit declaration of function 'close' is invalid in C99 [-Wimplicit-function-declaration]
close(c->ctx);
^
2 warnings and 2 errors generated.
Nächster Versuch nach Einbinden der fehlenden Header-Datei:
clang -c textcode/base64url.c -O2 -pipe -O2 -fomit-frame-pointer -g -fstack-protector-strong -fno-strict-aliasing -pipe -W -Wall -Wextra -D_REENTRANT -I.
io/iom_wait.c:68:34: warning: incompatible pointer types passing 'struct kevent (*)[128]' to parameter of type 'struct kevent *' [-Wincompatible-pointer-types]
int r=kevent(c->ctx, 0, 0, &kev, freeslots, &ts);
^~~~
/usr/include/sys/event.h:320:21: note: passing argument to parameter 'eventlist' here
struct kevent *eventlist, int nevents,
^
io/iom_wait.c:79:12: error: use of undeclared identifier 'i'
for (i=0; i<r; ++i) {
^
io/iom_wait.c:79:17: error: use of undeclared identifier 'i'
for (i=0; i<r; ++i) {
^
io/iom_wait.c:79:24: error: use of undeclared identifier 'i'
for (i=0; i<r; ++i) {
^
io/iom_wait.c:81:15: error: use of undeclared identifier 'i'
int e = (kev[i].filter == EVFILT_READ ? IOM_READ : 0) |
^
io/iom_wait.c:82:15: error: use of undeclared identifier 'i'
(kev[i].filter == EVFILT_WRITE ? IOM_WRITE : 0);
^
io/iom_wait.c:83:6: error: use of undeclared identifier 'i'
if (i+1==r) {
^
io/iom_wait.c:85:10: error: member reference base type 'struct kevent [128]' is not a structure or union
*s=kev.ident;
~~~^~~~~~
io/iom_wait.c:88:22: error: use of undeclared identifier 'i'
c->q[c->h].fd=kev[i].ident;
^
1 warning and 8 errors generated.
Da hat wohl jemand offensichtlich komplett ungetesteten Code veröffentlicht ...
Nachdem ich auch diese Fehler weggepatcht hatte, habe ich festgestellt, dass die Fehler in CVS bereits behoben wurden ...
Keine Ahnung warum es noch kein neues libowfat-Release gibt, die Anfrage beim Upstream wurde abgelehnt:
From: Mail Delivery System <Mailer-Daemon@ispgateway.de>
To: fk@fabiankeil.de
Subject: Mail delivery failed: returning message to sender
Date: Sat, 20 Feb 2021 10:03:00 +0100
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
felix@fefe.de
host a.mx.fefe.de [31.15.64.162]
SMTP error from remote mail server after RCPT TO:<felix@fefe.de>:
553-mhh, that does not look good...
553-let's see what we have here
553-still no improvement...
553-mhhh...
553 sorry, but you are coming from a blacklisted IP range; see www.fefe.de/contact.html (#5.1.8)
Return-path: <fk@fabiankeil.de>
Received: from [217.246.52.33] (helo=fabiankeil.de)
by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.92.3)
(envelope-from <fk@fabiankeil.de>)
id 1lDO6D-0007y5-QM
for felix@fefe.de; Sat, 20 Feb 2021 09:58:49 +0100
Date: Sat, 20 Feb 2021 09:58:34 +0100
From: Fabian Keil <fk@fabiankeil.de>
To: Felix von Leitner <felix@fefe.de>
Subject: libowfat 0.32 auf ElectroBSD
Message-ID: <20210220095834.22b89f58@fabiankeil.de>
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="Encrypt_/f4Hnv6OZSQANxgpH0NTPknu";
protocol="application/pgp-encrypted"
X-Df-Sender: MTgwOTA5
Domainfactory scheint mal wieder auf einer Spam-Blacklist gelandet zu sein und ich sollte endlich, wie bereits 2006 angedacht, einen eigenen Mailserver für fabiankeil.de aufsetzen und die Domain umziehen ...
gatling 0.16 ließ sich schließlich bauen, hatte aber keinen anständigen IPv4-Support:
fk@t520 /tmp $gatling -i 127.0.0.1 -p 8000 socket_bind6_reuse: Can't assign requested address
Das Problem lässt sich durch Definieren von __broken_itojun_v6__ umgehen,
gatling beschwert sich dann allerdings über itojun KAME madness
:
fk@t520 /tmp $fk@t520 /tmp $gatling -i 127.0.0.1 -p 8000
WARNING: We are taking heavy losses working around itojun KAME madness here.
Please consider using an operating system with real IPv6 support instead!
Für meine Testzwecke ist das zum Glück egal. gatling 0.15 hat das gleiche Problem, das Update macht die Sache also nicht schlimmer.
Das devel/libowfat-Update wird als FreeBSD-Bug 253762 geführt, das www/gatling-Update als FreeBSD-Bug 253763.