NevemTeve blogja

MySql AIX-on: halad, csak lassan...

 ( NevemTeve | 2014. szeptember 15., hétfő - 19:18 )

Mostanra eljutottunk odáig, hogy a __fe_def_env miatt nincs duplikált szimbol, de azért még nem áll össze a 'myisam_ftdump'

ld: 0711-224 WARNING: Duplicate symbol: ._mi_report_crashed
ld: 0711-344 See the loadmap file loadmap for more information.
ld: 0711-317 ERROR: Undefined symbol: THR_THD
ld: 0711-317 ERROR: Undefined symbol: vtable for handler
ld: 0711-317 ERROR: Undefined symbol: key_map_empty
ld: 0711-317 ERROR: Undefined symbol: opt_myisam_use_mmap
...

MySql fordítás -- WTF

 ( NevemTeve | 2014. szeptember 8., hétfő - 11:05 )

Mármint a fordítás ezzel áll meg:

/usr/local/src/mysql-5.5.38/include/my_global.h: In function 'my_ulonglong2double':
/usr/local/src/mysql-5.5.38/include/my_global.h:289:74: error: expected ')' before 'A'

A kérdéses haeaderben:
[code]
/* Go around some bugs in different OS and compilers */
#ifdef _AIX /* By

*/
#define _H_STRINGS
#define _SYS_STREAM_H
/* #define _AIX32_CURSES */ /* XXX: this breaks AIX 4.3.3 (others?). */
#define ulonglong2double(A) my_ulonglong2double(A)
#define my_off_t2double(A) my_ulonglong2double(A)
C_MODE_START

Sony DVP-SR370

 ( NevemTeve | 2014. augusztus 18., hétfő - 9:41 )

Sony DVP-SR370 gyártmányú lejátszón próbálok DVD-ről mencoder-elt AVI fájlt lejátszani, a következő rendkívül kifinomult hibaüzenet jön:

Data error (VIDEO)

A leírás szerint:

Lejátszható fájlformátumok
Videó: MPEG-1 (Cyber-shot adat)/MPEG-4 (simple profile)/Xvid
Fénykép: JPEG (DCF formátum)
Zene: MP3 (kivéve mp3PRO)/WMA(kivéve WMA Pro)/AAC/LPCM/WAVE
Használható kiterjesztések: „.avi”,„.mpg”, „.mpeg”, „.mp4”,,„.jpg”, „.mp3”,„.wma”, „.m4a”, „.wav”

Pelikán elvtárs, a mplayer nem habostorta!

 ( NevemTeve | 2014. július 30., szerda - 17:44 )

Például crop-olni szeretnék (-vf crop=w:h:x:y), mplayer-ben megy, mencoder-ben segfault... Most fordul debug-gal, majd referálok az eredményről.

20140730.1749 Hát ennyit mondott:

#0  0x08126d97 in draw_bottom_blackbar_slice (y=<optimized out>, 
    x=<optimized out>, h=<optimized out>, w=<optimized out>, 
    stride=<optimized out>, src=<optimized out>, vf=<optimized out>)
    at libmpcodecs/vf_expand.c:366
#1  draw_slice (vf=0x928abb0, src=0xffffc694, stride=0xffffc700, w=720, h=16, 
    x=0, y=0) at libmpcodecs/vf_expand.c:402
...

új PHP, új gond

 ( NevemTeve | 2014. július 4., péntek - 13:37 )

PHP-5.4.30 nem fordul, pontosabban a libphp5.la linkelése nem sikerül:

ld: 0711-317 ERROR: Undefined symbol: .tgetnum
ld: 0711-317 ERROR: Undefined symbol: .tputs
ld: 0711-317 ERROR: Undefined symbol: .tgoto
ld: 0711-317 ERROR: Undefined symbol: .tgetstr
ld: 0711-317 ERROR: Undefined symbol: .tgetent
ld: 0711-317 ERROR: Undefined symbol: .tgetflag

Ez egy AIX-6.1, legutóbb a PHP-5.4.27 fordult rajta; a kérdéses szimbóleumok a /usr/lib/libcurses.a-ból kellene jöjjenek.

pthread vagy pthreads

 ( NevemTeve | 2014. június 10., kedd - 18:28 )

Nagyon úgy tűnik, hogy ismét egy apróságon pörgök, de mintha AIX-on a 's'-végű lenne a szabvány/szokvány; linux-on meg a másik.
A gcc opció mindkét esetben -pthread, de a shared lib, amit beleszerkeszt, különbözik:

AIX: /usr/lib/libpthreads.a(shr_xpg5_64.o)
linux:(NEEDED) Shared library: [libpthread.so.0]

20140610.2115: tehát a megfejtés: ahol lehet, ott a -lpthread(s) helyett -pthread legyen, ahol nem lehet (mondjuk direktben hívjuk a ld-t valamilyen spec esetben), ott el kell ágazni platform szerint.

mc, TERM=linux, gpm, jajjanyám

 ( NevemTeve | 2014. május 21., szerda - 16:28 )

20190406
És ha rákattintunk a linkre, azt látjuk, hogy (remélhetőleg) közel a megoldás!
http://midnight-commander.org/ticket/3208

20170611
Úgy nézem, akkor lép fel, ha TERM=putty-256color... Na most jön a --without-gpm-mouse
Szerk: téves riasztás, volt a gépemen egy ősrégi /usr/bin/mc[edit], az indult el tévedésből ($EDITOR volt ráálítva)

20170609
Na ez miez (végtelen sok ismétlődéssel az 'user-log'-ban, Debian8/mc-4.8.17):
[code]
Jun 7 11:46:52 z-pc mcedit: Warning: closing connection
Jun 7 11:46:52 z-pc mcedit: *** info

find -- ez most kiszúrás, vagy csak szórakozik velem?

 ( NevemTeve | 2014. május 7., szerda - 18:00 )

find . -name Makefile -exec echo {}.extension \;

Ez a find-parancs AIX5.3-on a következőt generálja:

{}.extension
{}.extension
{}.extension

Na ez most kiszúrás, vagy csak szórakozik velem?

20140508.0508: Köszönöm a hozzászólásokat, azóta működik a kerülő-módszerrel ( vagyis átirányítással egy 'while read FILENAME; do'-ba)

git=szenya

 ( NevemTeve | 2014. április 29., kedd - 18:47 )

Vagy hasonló. Például Harry Potter ellenszenves tanárát 'greasy git'-ként emlegetik. Ennél nagyobb gondom, hogy a git-1.9.2 ellenáll a fordításnak az egyik AIX-os gépemen. A következő apróságok örvendeztettek meg:

1. a make distclean törli a configure-t. Szerintem inkább a Makefile-t kellene törölnie, de hát ahány ház, annyi szokás; megoldjuk:
sed_repl 's/^ \$(RM) configure/ # $(RM) configure/' Makefile

2. Nem használja a libtool-t. Megoldás:
make ... QUIET_LINK='aix-libtool --mode=link ' ...

libtool újabb kalandjai...

 ( NevemTeve | 2014. április 4., péntek - 12:36 )

Nem fordul a gettext... már számtalanszor lefordult, de most nem, megpusztult a configure a libiconv keresésénél...
És végül kiderült, hogy ki a hibás. Hát én, természetesen. Nem tudtam, hogy a configure script a libtool *.la fájlját (esetünkben a /usr/local/lib/libiconv.la-t) shell-scriptként akarja feldolgozni!
Vagyis abban nem lehet ám akármi, csak változó=érték hozzárendelések, és #kettőskereszttel bevezetett megjegyzések... Persze ennek egy jó kis kapkodás közben kellett előkerülnie, semmiképp sem valami békés pillanatban...

sshd: key_parse_private2: missing begin marker

 ( NevemTeve | 2014. március 26., szerda - 17:31 )

Ez mi ez?

debug1: sshd version OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker

Egyelőre annyit látok, hogy van egy authfile.c és abban egy key_parse_private2 függvény.

20140326.1643 Mintha az lenne, hogy a [/usr/local]/etc/ssh-beli ssh_host_*_key fájlokban a fejléc/lábléc lenne hibás:

ez van:

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

ezt várja:

-----BEGIN OPENSSH PRIVATE KEY-----
-----END OPENSSH PRIVATE KEY-----

LC_CTYPE: ISO-8859-2 vagy ISO8859-2

 ( NevemTeve | 2014. március 25., kedd - 13:07 )

Újabb nagy diadala a szabványoknak és az együttműködésnek: egyik unix így szereti, a másik meg amúgy... Ha én meg ssh-ból megyek egyikből a másikba (vö: SendEnv és AcceptEnv), akkor vagy jó lesz a másikfajta, vagy nem. Hirtelen ennyit tudok javasolni megoldásként:

http://web.axelero.hu/lzsiga/ekezet.html#Q0094

20140127.1003: És ehhez egy kis kiegészítés

http://web.axelero.hu/lzsiga/ekezet.html#Q0096

Oracle TCP_KEEPALIVE nélkül?

 ( NevemTeve | 2014. március 14., péntek - 12:50 )

2017.02.27. 10:46
Említsük meg, hogy AIX-on a könnyen googlizható nevű "no" segédprogrammal lehet a TCP_KEEPALIVE időzítését hangolni.

$ /usr/sbin/no -a | grep keep
                ndpt_keep = 120
              tcp_keepcnt = 8
             tcp_keepidle = 14400 # = 2 óra
             tcp_keepinit = 150
            tcp_keepintvl = 150
# /usr/sbin/no -o tcp_keepidle=120 #  = 60 sec (félmásodperces egységben)

2014.03.14. 15:53
Továbbá szerveroldalon: sqlnet.ora-ban sqlnet.expire_time=<perc>

Szemaforok -- van választék

 ( NevemTeve | 2014. március 3., hétfő - 21:04 )

A múltkori eset után picit utánaolvastam a szemaforoknak, és egy kis táblázatot alkottam: itt látható..

Már írtam is hozzá egy kis kiegészítést: a SsystemV IPC-nek szerencsés tulajdonsága, hogy ha használjuk a SEM_UNDO opciót, akkor egy váratlan leállás sem tudja zárolva hagyni a szemafort, ami viszont megtörténhet a POSIX-os szemaforral.

Bepörög az Apache az imagick-tól

 ( NevemTeve | 2014. február 26., szerda - 19:29 )

Ez most csak egy emlékeztető magamnak, hogy ismét akadt egy kis nyomoznivaló...

Komponensek:

AIX 6.1 (oslevel 6100-09)
Apache httpd-2.4.7
PHP-5.4.24
ImageMagick-6.8.8-4
imagick-3.1.2

Hibajelenség:

A 'phpinfo()' elég a hiba bemutatásához, de csak Apache-on át, standalone-ban jó.
Úgyszintén jó, ha httpd -X paranccsal futtatom.
Akkor is, ha nincs a php.ini-ben az extension=imagick.so.

új Apache, új gondok...

 ( NevemTeve | 2014. február 6., csütörtök - 12:37 )

Komponensek:

AIX-5.2
httpd-2.4.7
apr-1.5.0
apr-util-1.5.3

Problémás rész:

[code]/usr/local/src/httpd-2.4.7/srclib/apr/libtool --silent --mode=link \
gcc -pthread -mtune=native -maix32 -std=c99 \
-Wl,-brtl -L/usr/local/lib -lcpotlas -Wl,-brtl,-brtllib -lrtl \
-Wl,-blibpath:/usr/local/lib:/usr/lib:/lib -Wl,-brtl \
-o mod_cache_socache.la \
-Wl,-bI:/usr/local/src/httpd-2.4.7/server/httpd.exp \
/usr/local/src/httpd-2.4.7/srclib/apr-util/libaprutil-1.la \

OpenSsl reloaded

 ( NevemTeve | 2014. január 30., csütörtök - 19:06 )

openssl-ék szerint az 1.0.1 az már nem olyan, mint a 0.9.8, hogy minden alverzió inkompatibilisnek számít. Nem, itt már az 1.0.1 kompatibilis az 1.0.0-lal.

Normálisan ilyenkor a verziószámot major+minor részre bontják, a major változása inkompatibilis fejlesztést jelent, a minor változása kompatibiliset (vagyis újrafordítás/szerkesztés nélkül használható az új) pl:

major=1.0.1g minor=(üres)
major=1.0.1 minor=g
major=1.0 minor=1
major=1.0 minor=1g
stb

gdb-vel kavarok

 ( NevemTeve | 2014. január 23., csütörtök - 15:31 )

egyik gép (linux; gdb-7.5.1) így írja ki a shared libeket:

From        To          Syms Read   Shared Object Library
0xf7fe1830  0xf7ff7c8f  Yes (*)     /lib/ld-linux.so.2
0xf7fc1a40  0xf7fc2988  Yes (*)     /lib/i686/cmov/libdl.so.2
0xf7e90a80  0xf7f8647c  Yes (*)     /lib/i686/cmov/libc.so.6

Nem rossz, de lehetne jobb: ha kiírná az adatterületeket is.

másik gép (AIX; gdb-7.3):
[code]Text Range Data Range Syms Shared Object Library
0xd052d240-0xd052da3e 0xf0828608-0xf0828730 Yes /usr/lib/libcrypt.a(shr.o)

backspace ^H vagy ^?

 ( NevemTeve | 2014. január 11., szombat - 16:43 )

De komolyan, olvtársak, hogy van az, hogy az elmúlt 40-50 év még nem volt elég ahhoz, hogy megnyugtatóan rendeződjön ez a mélységesen mély probléma?

Most ne mondjuk azt, hogy a bash/readline/mc/egyéb program tök jól kezeli mindkettőt, hanem vegyük elő a legfelhasználóbarátságtalanabb programunkat (pl dash, ksh), és nézzük meg, hogy abban működik-e a BackSpace, vagy esetleg megjelenik helyette egy ^H vagy ^? szekvencia.

Win16-os hibakeresés

 ( NevemTeve | 2014. január 9., csütörtök - 16:50 )

Valamit elronthattam, debuggolni kellene. Ahogy látszik a dolog, Assembly szinten kellene nézelődni (A function-prolog lehet rossz. Talán.)... Sajnos a jó öreg BorlandC4.5-höz tartozó TDW nem indul el. Google barátom az OpenWatcom-ot ajánlotta, annak van 16-bites fordítója és debuggere is. Kipróbáltam, tényleg van.
Sajnos megpusztul azon a ponton, amikor 'huge' pointerrel kellene matekoznia.

struct list

 ( NevemTeve | 2014. január 6., hétfő - 18:03 )

cvs-1.11.21 nem fordul AIX-5.3-on; a hiba oka: 'struct list' redefined.
Megnéztem, tényleg.
Egyrészt a cvs/src/hash.h -ban, másrészt a /usr/include/grp.h -ban van ilyen. Gratulálok a fantáziájukhoz. Eddig nem jött ki, mert az utóbbi csak a _THREAD_SAFE beállítás mellett aktíválódik.

Első ötletként keresek újabb CVS-t (nyílván új függőségekkel és inkompatibilitásokkal, természetesen).

20140106.1717: Úgy néz ki, hogy ez lett a barátunk: http://ftp.gnu.org/non-gnu/cvs/source/stable/1.11.23/

Ora64 kliens a jó öreg debian6.0.5-re

 ( NevemTeve | 2013. november 14., csütörtök - 12:37 )

Volt már nekem egy 10-es verzióm, Pro*C-vel meg Sql*Plus-sal, de lassan kellene haladni a 64-bit felé is.

Oracle-től leszedtem ezeket:

instantclient-*-linux.x64-11.2.0.4.0.zip;
*=basic,jdbc,odbc,precomp,sqlplus,tools

egyelőre ezek közül csak a basic-ba mentem bele, abból mindent, aminek tetszett a neve, telepítettem a meglévő /usr/local/OraHome_Current-be egy új lib64 mappába:

[code]
-rwxrwxr-x 1 root root 25420 Aug 24 19:30 adrci
-rw-rw-r-- 1 root root 439 Aug 24 19:30 BASIC_README
-rwxrwxr-x 1 root root 47860 Aug 24 19:30 genezi

16-bit vagy 64-bit?

 ( NevemTeve | 2013. október 26., szombat - 20:24 )

Valamilyen lelki okból a dtelnet-ből most először 64-bites verziót is csináltam. A leltöltési statisztika két hét után a következő:

source: 5
16-bit: 16
32-bit: 476
64-bit: 6

Namostan én vagyok hülye, vagy rosszul látok, vagy a felhasználóknak nem szóltak, hogy a 16-bites Windows 3.x elavult?

bash fagyik AIX-on

 ( NevemTeve | 2013. október 17., csütörtök - 10:45 )

A komponensek:
szerver: AIX 5.2, házilag fordított bash-3.2.48
kliens: Debian linux 6, házilag fordított rxvt-2.7.10

Hibajelenség reprodukálása:
1. belépés (telnet)
2. még működik (pl kiprobáljuk a stty size parancsot -- jó)
3. felnagyítjuk az ablakot
4. már nem működik (ugyanaz a parancs, mint az előbb -- nincs válasz)

Kieg:
1. ugyanez a jelenség xterm-mel
2. mindegy, milyen parancsot futtatunk, az átméretezés után mindenképp fagyás van
3. ahol én fagyást látok, ott igazából a bash végtelen ciklusban falja a CPU-t

64-bites compiler Windows-ra

 ( NevemTeve | 2013. október 7., hétfő - 17:50 )

Keresgéltem egy keveset, míg végül kiderült, hogy az 'apt-get install mingw-w64' az én barátom; most éppen ezek a komponensek vannak a gépemen:

ii  gcc-mingw32      The GNU Compiler Collection (cross compiler for MingW32 / MingW64)
ii  mingw-w64        Minimalist GNU w64 (cross) runtime
ii  mingw32-binutils Minimalist GNU win32 (cross) binutils
ii  mingw32-runtime  Minimalist GNU win32 (cross) runtime

Ilyesmik lesznek a Makefile-ban:

CC      := amd64-mingw32msvc-cc
RC      := amd64-mingw32msvc-windres
LIBS    := -lkernel32 -lws2_32