NevemTeve blogja

Cannot load libexec64/apache2/libphp.so into server: /usr/local/libexec64/apache2/libphp.so: cannot allocate memory in static TLS block

Egyesek szerint a gomp-nak köszönhetjük ezt az érdekességet, mások szerint a sors nem kegyes. Modern világunkban ilyenkor jön a kikapcs+bekapcs, ha attól megjavul, akkor nem nyomozunk tovább.

Csak ebből a debugüzenetből gondolom:

  log does not need rotating (log has been already rotated)considering log /var/log/kern.log
  log does not need rotating (log has been already rotated)considering log /var/log/messages

Na jó, nem is az a fő gond, hogy nem találta a soremelést a derék fejlesztő, inkább az, hogy végül is nem is rotálta meg a kern.log-ot. Sem semmit. Ja és a copyright szerint az a 3.8.6-os verzió, 2001-ből.

rsyslog-8.2402.0-t próbálom ./configure-olni, de ez a kódrészlet (15664-es sor) túl nehéz a shell-nek:

 for flag in     ; do

De tényleg, ezt a ciklust most hányszor kellene végrehajtani, nullaszor?

Azt mondja nekem a perl, hogy

doio.c:Perl_do_print:2118 Wide character in print offset=0 x'ce91' IO_isutf8=0 DO_UTF8=1 at ./yasql.in line 3236,  line 7.
ΑαΒβΓγΔδΕε ЁёЖжЗзИиЙйΑαΒβΓγΔδΕε ЁёЖжЗзИиЙй

Ez azt próbálja jelenteni, hogy a fájl nincs utf8-módban. Ezt akár debugkiírással is ellenőrizhetjük:

printf ("layers: %s", join(' ', (PerlIO::get_layers(FOUT))));
layers: unix perlio encoding(utf-8-strict) utf8

Én se hinném el másnak, de már jónéhány verzió óta egyes betűk láthatatlanná váltak a Firefoxon, a "Use hardware acceleration when available" állítgatása nem segített. Most valahogy összegugléztam, hogy a Windows-ból való TTF fájlok törlésével lehet segíteni a dolgon (eddig a /usr/share/fonts/trutype/ alatt volt nekem egy windows-ttf könyvtáram, abba szimlinkeltem a Windows7 fontjait, azt töröltem most.) Kicsit csúnyább lett, de látszanak a betűk.

TL;DR: https://github.com/lzsiga/yasql-fx/blob/main/ReadMeFx.TXT
https://github.com/lzsiga/yasql-fx/blob/main/test/test0001.sh
https://github.com/perl5-dbi/DBD-Oracle/issues/171

Utólag nyilván ez is egyszerű és világos lesz, csak még most van egy kis furcsaság (perl/yasql/substr/utf8), nevezetesen a string a substr hatásara meghosszabbodni látszik, 36 hosszúról 38 hosszúra; a két extra karakter közül az első egy x'00'.

"Némely emberi agy egészen másképp működik, mint ahogy azt hétköznapi észjárással elvárhatnánk."
Akarom mondani, ez a derék nginx a fordításához külső komponensek (zlib, pcre, openssl) forrásprogramját szeretné látni, sőt, azokat is ő maga szeretné lefordítani... Vagy lehet hogy, még a szerkesztőprogram (linkage editor) feltalálása előttről származik ez a termék, és ez bizony még meglátszik rajta?

Négy készüléken installáltam sikeresen a harfbuzz-8.3 nevű terméket, elégedett is voltam (fordítás után alig háromszor annyi lemezhelyet foglal, mint a php-8.3, szóval semmiképp sem bloat), de aztán botor fejjel egy újabb masinával is megpróbálkoztam. Természetesen nem megy, végtelen ciklusban gyönyörködhetem. (A jó hír az, hogy ez C++, header-fájlban implementált végtelen mélységű templétekkel, tehát gdb-vel debuggolni alig lehet.)

Az include-fixed részre gondolok, ahová a javított header-fájlokat teszi. Nyilván, hogy megoldjon egy kompatibilitási problémát. És okozzon egy másikat. Ilyen ez a popszakma.

gpgsm az érintett termék neve, annyira felhasználóbarát, hogy mindenféle levelezési listáról kell összevadászni a legegyszerűbb használati esetet; valamint van két segítő démonja (gpg-agent, dirmngr), amik esszenciálisak, és automatikusan elindulnak, illetve nem esszenciálisak, és nem indulnak el maguktól, illetve adott esetben systemd kellhet hozzá, de az is lehet, hogy a RedHat ismét segített rajtam...
TL;DR: itt egy pelda az importalasra

Már aggódtam, hogy a php-8.3.0 nem hoz érdekességet. Ez most Amd64/Linux lenne, egyelőre ennyi van:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffefea01fe in initialize_env () at /usr/local/src/gcc-13.2.0/libgomp/env.c:2062
2062	  for (env = environ; *env != 0; env++)

TL;DR A megoldás: a főprogram (php.exe) szerkesztésénél is kell a -fopenmp opció, hogy az imagick plugin működjön.

Panaszkodott, hogy az SQL darabokbol van összeragasztgatva. Gondoltam, talán ha lát egy replaceAll-t, megbékül. De sikerült?!

stmt = con.prepareCall("begin " + Connector.getDBSchema().replaceAll("[\\W]", "_")
                    + ".packagename.functionname(?,?,?,?,?,?,?,?);end;");

Természetesen nem fordul elősőre; de szerintem most nem fáradtak új hiba kifejlesztésével, csak felmelegítettek egy korábbit. Legalábbis volt más pár Assembly-s hiba.

crypto/aes/aesp8-ppc.s: line 2412: invalid opcode or pseudo-op

Akinek a C++ nem elég bonyolult, az használhat boost-ot. Akinek az sem elég, próbálja ki a readelf -d libboost_serialization.so | grep 'Library rpath' parancsot. [Itt javítottam egy elírást.]

Ha azt látja ott, hogy Library rpath: [/usr/lib:/usr/lib/python2.7/config], akkor már meg is nyugodhat a világ sora felől.

Eddig minden verzió simán fordult, hát nyilván kellett egy kis változás.

-export-symbols-regexp ^jk_module

cc1: error: the "xcoff" debug format cannot be used with pre-compiled headers [-Werror=deprecated]

Ha lenne mikrofon a gépen, most belemondanám, hogy "kedves gcc, nem kértem precompiled headert, de ha már önkéntes jóságból csinálsz ilyet, legalább azt gyónd meg, hogy hogyan lehet letiltani!"

Esetünkben két tizenhat bites mezőben kellene tárolni egy sorszámot (konkrétan a sor számát a forrásprogramban), nade hogyan is lehetne? Nagyon egyszerű: egyik_mező + 8192*másik_mező. Csodálom, hogy magamtól nem erre gondoltam először.

Nyomasek Bobónak elgurult a gyógyszere, és jogos haragjában dekrepálta az ftime(3) függvényt. Igaz, hogy ami van helyette (gettimeofday, pl), az nem megy minden platformon, tehát meg kellene szórni a programokat #if-ekkel, de hát nem lehet mindenkinek kedvezni.

Most jön a nehéz kérdés: mit telepítsek helyette? Linuxon Evolution lett a megoldás pár hónapja, most Windows-on kellene valami.

letiltom a rtkit-daemon-t. Legalábbis valami folyamatos, monoton diszkpörgést hallottam folyamatosan, ami szerintem azóta szűnt meg, hogy ezt mondtam neki:

systemctl stop rtkit-daemon.service
systemctl disable rtkit-daemon.service
systemctl mask rtkit-daemon.service

Az egyik jóember belerakott egy if-et a JBoss7-be, hogy ne induljon el 7-nél újabb Javával. A másik jóember kitalálta, hogy az xmlsec nevű komponensből újabb verzió kellene, mert ez (remélhetőleg)  EC-s kulccsal is tud XML-t aláírni. A harmadik jóember annyira híve a görög ABC-nek, hogy pár lambdát is rakott az xmlsec újabb verziójába. A végeredmény kitalálható. Én kérek elnézést.

Ott kezdődik, hogy van egy PuTTY emulátorom, egy elavult AIX-om, és azon belül két, inkompatibilis terminfo/curses, az egyik a gyári, a másik az /opt/freeware féle.

Panaszom lenne a 'cache.h'-val kapcsolatban [nevezetesen, hogy nem include-olja a "dir.h"-t], el is mentem ide: https://github.com/git/git, de ott már nincs is cache.h. No, csak jó dolog a fejlődés.

Esetünkben az egzotikus rendszer linux/amd64, a fordítandó termék a nmap-7.94, a hibaüzenet:

gcc -fvisibility=hidden -m64 -std=c99  -fpic -I.  -DBUILDING_PCAP -Dpcap_EXPORTS -DHAVE_CONFIG_H  -m64 -std=c99    -c ./fad-getad.c
./pcap/bpf.h:97:9: error: unknown type name 'u_int'
 typedef u_int bpf_u_int32;

Megmondom őszintén, nem nagyon használtam ilyen ssh-agent-et, legfeljebb akaratomon kívül (vö: segítőszoftver), de az igaz, hogy egyes gépeken még csak 8.7-es OpenSSH van, például azért, mert az szót ért a még régebbi verziókkal. (Amivel az sem ért szót, azon meg van telnetd.)