Hátétépé, rajtam kezdé -- httpd-2.4.33 nem fordul

Eddig szokott fordulni a httpd, dehát semmi sem tart örökké... Kellett neki újabb libcurl, azt tettem neki, de annak nincs köze ehhez a hibához 


libtool: compile: gcc ... mod_proxy.c -o .libs/mod_proxy.o
mod_proxy.c:2675:1: error: unknown type name 'apr_OFN_ssl_engine_set_t'

mod_proxy.c:2675:1: error: unknown type name 'apr_OFN_ssl_engine_set_t'
 static APR_OPTIONAL_FN_TYPE(ssl_engine_set) *proxy_ssl_engine = NULL;
 ^
mod_proxy.c: In function 'ap_proxy_ssl_engine':

És igaza van: a cpp -dD nevű varázseszközzel megnézve sincs ilyen 'apr_OFN_ssl_engine_set_t' definiálva.

Apr és apr-util frissnek látszik lenni: 


$ ls -l depo/apr*
-rw-r--r-- 1 projects devel 854100 Oct 29 18:35 depo/apr-1.6.3.tar.bz2
-rw-r--r-- 1 projects devel 428595 Oct 29 18:35 depo/apr-util-1.6.1.tar.bz2

A forrásprogramban (mod_proxy.c): 


static APR_OPTIONAL_FN_TYPE(ssl_proxy_enable) *proxy_ssl_enable = NULL;
static APR_OPTIONAL_FN_TYPE(ssl_engine_disable) *proxy_ssl_disable = NULL;
static APR_OPTIONAL_FN_TYPE(ssl_engine_set) *proxy_ssl_engine = NULL;
static APR_OPTIONAL_FN_TYPE(ssl_is_https) *proxy_is_https = NULL;
static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *proxy_ssl_val = NULL;

ez lesz belőle precompilás útján: 


static apr_OFN_ssl_proxy_enable_t *proxy_ssl_enable = ((void *)0);
static apr_OFN_ssl_engine_disable_t *proxy_ssl_disable = ((void *)0);
static apr_OFN_ssl_engine_set_t *proxy_ssl_engine = ((void *)0);
static apr_OFN_ssl_is_https_t *proxy_is_https = ((void *)0);
static apr_OFN_ssl_var_lookup_t *proxy_ssl_val = ((void *)0);

/usr/local/include/apr_optional.h: 


/**
 * The type of an optional function.
 * @param name The name of the function
 */
#define APR_OPTIONAL_FN_TYPE(name) apr_OFN_##name##_t

Szerk: a hülye is kitalálhatta volna: derék fejlesztők néhány header-fájlban (pl. mod_ssl.h, mod_proxy.h) változtattak, amik majd a 'make install' során szépen be is fognak kerülni a /usr/local/include/apache2/ könyvtárba. Addig viszont, az include-utasítások sorrendjének megváltoztatásával, vagy a régi header törlésével kellene megoldani, hogy a fordítás során ne a régi header-t használja (és ezzel hibára fusson.)

Vagy a /usr/local/include/apache2 törlésével, de akkor mindent újra kell csinálni, úgyismint apr-1.6.3, apr-util-1.6.1, httpd-2.4.33, mivel ezek közösen használják ezt a könyvtárat.

Szerk: végül begépeltem ide is, hadd épüljenek a külföldiek is: https://serverfault.com/questions/904762/mod-proxy-compile-error-with-a…

( uid_7086 | 2018. 03. 29., cs – 17:30 )

Csak kíváncsi vagyok: az ilyen mazochista megnyilvánulásaid pusztán a hobbid következményei vagy munkahelyi problémák? :)

És akkor jön a köv. kérdés, hogy akkor meg miért? :)
Komolyan nem cikizni akarlak, csak próbálom érteni, hogy kell a munkához - és akkor miért fontos, hogy AIX-en legyenek ezek -, vagy csak szimplán hobbi/mazochista hajlam etc. miatt.
Ha engem munkahelyen köteleznének rá, már rég kiléptem volna. :)

Ez olyan, mint valami logikai láncolat: a dolog egyik végén (pl) egy PHP program van (Oracle adatbázist használ), a másik végén a felhasználó. Hogy összetalálkozzanak, mindenféle program kell még, amiknek még további függőségei vannak, és így tovább. (Az persze előfordul, hogy a pkg-confignak kell a glib, a glibnek meg kell a pkg-config; vagy pl a gettext és a libiconv kölcsönösen függenek egymástól.)

Na jó, de ez nem magyarázat arra, hogy kötelesség vagy mazochista hobbi? ;)

(mondjuk az Oracle-ből arra tippelek, hogy az előbbi, de ugye anno én is csináltam olyat, mondhatni hobbiból, hogy VMS szerverek elé linuxos web szervert toltam, pedig akkoriban nem igazán volt vezetőileg támogatott... :D - egyébként fasság volt, de VMS-en még az AIX-nél is rosszabbul ment az apache)

( NevemTeve | 2019. 08. 21., sze – 13:57 )

A httpd-2.4.41 is ilyen. Persze most már reflexből megy: 


rm /usr/local/include/apache2/*
cd /there/src/apr; make install
cd /there/src/apr-util; make install
cd /there/src/httpd-2.4.41
...