NevemTeve blogja

Mea culpa

 ( NevemTeve | 2015. október 15., csütörtök - 13:54 )

Ezt most találtam egy saját programomban, és nagyon nem tetszik:

q= strchr (p, '\0');

Mi a haragos moha ez? Jó, tegyük fel, hogy működik, de akkor is inkább így kellene:

q= p + strlen (p);

vagy

q= memchr (p, '\0', plim-p);

netkit-telnetd elavulta magát

 ( NevemTeve | 2015. október 14., szerda - 16:58 )

Nem lehet forrásból fordítani (ezt már abból is ki lehet találni, hogy C++ is van benne), marad a Debian, emlékeztetőül magamnak:

cd /usr/local/src
tar xfzv depo/netkit-telnet_0.17.orig.tar.gz
zcat depo/netkit-telnet_0.17-36.diff.gz | \
patch -p0 2>&1 | tee patch.log

Szerk: na jó, oké, így sem fordul, dehát mi tökéletes ebben a fájó életben?!

Szerk: a CPPFLAGS (és benne a -D_XOPEN_SOURCE) nem jutott el a Makefile-ig; az ilyenkor szokásos elegáns megoldás:

[code]
export CFLAGS="$CFLAGS $CPPFLAGS"
export CXXFLAGS="$CXXFLAGS $CPPFLAGS"

curl: nem a méret a lényeg...

 ( NevemTeve | 2015. szeptember 24., csütörtök - 21:23 )

Akárcsak az odbc-vel, a curl-lel is bajba kerülünk, ha 32- és 64-bitre is lefordítjuk; a gond forrása a /usr/local/include/curl/curlbuild.h -- tök jól belehardkódol mindenféléket, pl:

$ diff -u curlbuild_32.h diff curlbuild_64.h # részlet
  /* The size of `long', as computed by sizeof. */
- #define CURL_SIZEOF_LONG 4
+ #define CURL_SIZEOF_LONG 8

  /* Signed integral data type used for curl_off_t. */
- #define CURL_TYPEOF_CURL_OFF_T int64_t
+ #define CURL_TYPEOF_CURL_OFF_T long

Első tesztem a curl-FTP-vel (upload)

 ( NevemTeve | 2015. szeptember 24., csütörtök - 16:30 )

Persze semmi sem megy elsőre, most éppen az van, hogy

* Uploaded unaligned file size (359 out of 7 bytes)

amiből aztán az lesz, hogy

curl_easy_perform() failed: 18: Transferred a partial file

Namostan a tcpdump szerint a dróton 359 byte ment át (történetesen a /etc/motd, ami tényleg ekkora).

Első ötlet: hátha más partnerrel más a jelenség. Nem vált be, ugyanaz történik.

Második ötlet: van egy opcionális setopt-hívás, hogy CURLOPT_INFILESIZE / CURLOPT_INFILESIZE_LARGE. Most próbáljuk ki, hogy hátha nem annyira opcionális.

odbc: nem a méret a lényeg...

 ( NevemTeve | 2015. augusztus 18., kedd - 18:20 )

Mármint az egyes típusoké...

[code]
=== AIX ===

$ odbcinst --version
unixODBC 2.3.2

32-bit: Sizes of types: SQLINTEGER:4 SQLLEN:4 SQLSETPOSIROW:2
64-bit: Sizes of types: SQLINTEGER:8 SQLLEN:8 SQLSETPOSIROW:2

Ha '-DBUILD_LEGACY_64_BIT_MODE'-val fordítjuk:
64-bit: Sizes of types: SQLINTEGER:8 SQLLEN:8 SQLSETPOSIROW:2

=== linux ===

$ odbcinst --version
unixODBC 2.2.14

32-bit: Sizes of types: SQLINTEGER:4 SQLLEN:4 SQLSETPOSIROW:4
64-bit: Sizes of types: SQLINTEGER:4 SQLLEN:8 SQLSETPOSIROW:8

Ha '-DBUILD_LEGACY_64_BIT_MODE'-val fordítjuk:

Mire is jó nekem a unixODBC?

 ( NevemTeve | 2015. augusztus 17., hétfő - 16:14 )

Hát a teória szerint már annyira belaktuk magunkat az Oracle világába, hogy ideje más gyártók termékeit is kipróbálni... Minél egzotikusabb, annál jobb alapon (most ne firtassuk, miért, nem is szeretném tudni).

Namostan ez a derék gyártó azt mondta, hogy a rendszerük ugyan legjobban úgy működik, ha minden hw+sw komponenst ők szállítanak (meg vagyok lepve), de azért van lehetőség az adatbázis-szerverük elérésére más platformról, pl unix-ból unixODBC útján, Javá-ból JDBC-vel stb.

Oracle 12.1 instant client működik AIX-on

 ( NevemTeve | 2015. augusztus 11., kedd - 15:40 )

Mármint úgy működik, hogy a LIBPATH-t jól beállítjuk. Ez se rossz persze, de lehet rajta hangolni. Most pl. ide jutatottam:

[code]
# dump -H -X64 /opt/lib64/libsqora.so.12.1
INDEX PATH BASE MEMBER
0 /opt/lib64:/usr/lib
1 /usr/local/lib64 libodbcinst.so.2
2 /opt/lib64 libclntsh.so.12
3 /opt/lib64 libclntshcore.so.12
4 /opt/lib64 libons.so.12
5 /usr/lib libc.a shr_64.o

Lesz nekem unixODBC-m! Remélem...

 ( NevemTeve | 2015. augusztus 1., szombat - 12:45 )

Eddig még nem volt szerencsém ehhez a csodasághoz, de most a felsőbb hatalmak azt mondják, hogy kell nekem egy ilyen.
Innen szedtem le a 2.3.2-t forrásban: ftp://ftp.unixodbc.org/pub/unixODBC/
Egyelőre itt állt meg a 'make all':
libodbcinst.la linkelése nem sikerül:
ld: 0711-317 ERROR: Undefined symbol: lt_libltdlc_LTX_preloaded_symbols

Ez a komponens hiányolja: libltdl/libltdlc_la-ltdl.o, annak a forrása pedig a ltld.c:
#define preloaded_symbols LT_CONC3(lt_, LTDLOPEN, _LTX_preloaded_symbols)

Tök jó, linuxon sem fordul az OpenSSL-1.0.2d

 ( NevemTeve | 2015. július 23., csütörtök - 9:45 )

Ugye-ugye, itt rinyálok hogy AIX így meg úgy...

ghash-x86_64.s: Assembler messages:
ghash-x86_64.s:890: Error: junk `.15473355479995e+19' after expression

a kérdéses rész:

   889          subq    $48,%rcx
   890          movq    $1.15473355479995e+19,%rax
   891          movdqu  48(%rsi),%xmm14
   892          movdqu  64(%rsi),%xmm15

as --version
GNU assembler (GNU Binutils for Debian) 2.20.1-system.20100303
This assembler was configured for a target of `i486-linux-gnu'.

Egy kis gond OpenSSH körül...

 ( NevemTeve | 2015. július 21., kedd - 6:39 )

Tényleg kicsinek látszik, de nem tetszik...

Last unsuccessful login: Tue Jan 29 00:30:09 *'(- on ssh from 1.2.3.4
Last login: Wed Jan  1 07:54:08 *,-0 on /dev/pts/1 from 1.2.3.4

telnet esetében nincs ilyen, jók a dátumok. Ez most egy OpenSSH 6.9p1, 64-bites. Nincs jobb ötletem, mint kipróbálni régebbi verziókat illetve ugyanezt 32-biten...

Szerk: 6.8p1, 32-bit: jó
Szerk: 6.9p1, 32-bit: jó

Mi az a zip_utf-.libs/8.o

 ( NevemTeve | 2015. július 17., péntek - 12:49 )

Azért csak jó ez az ipar, mindig adódik valami kis nyomoznivaló, most például az, hogy a php ezt hogyan bírta előállítani:

nm: ext/zip/lib/zip_utf-.libs/8.o: 0654-200 Cannot open the specified file.

Gondolom, volt egy olyanja, hogy ext/zip/lib/zip_utf-8, és ügyesen bele akarta szúrni, hogy '.libs'...

Szerk: No, ez rövid volt: ez van a Makefile-ban:

echo *.lo | sed 's/\([A-Za-z0-9_]*\)\.lo/.libs\/\1.o/g'

Szerk2: Mondjuk ez a gond nem is jelentkezett addig, amíg a -X64 opciót bele nem erőltettem a nm(1) hívásába...

OpenSSL-1.0.2d vs AIX5

 ( NevemTeve | 2015. július 13., hétfő - 9:49 )

Miért is menne elsőre?! Azt mondja, hogy:
[code]
cd crypto/sha
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std=gnu99 -D__UNIX__ -D__unix__=1 -Dnl_langinfo=local_nl_langinfo -DUSE_LOCAL_ISPRINT -D_GNU_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_THREAD_SAFE -I/usr/local/include -maix32 -O -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -c -o sha256p8-ppc.o sha256p8-ppc.s
Assembler:

Apache+PHP+pluginok 64-biten (AIX)

 ( NevemTeve | 2015. június 10., szerda - 16:50 )

Az első, ami feltűnik, hogy 7.x-en és 5.x-en látszólag megy, 6.x-en meg nem. A múltkoriak fényében azt mondanám, hogy a '-brtllib' hiánya okozhat ilyesféle gondokat, de látszólag megadtam ezt az opciót (egyébként 32-biten ennek feltűnő jele van: megjelenik librtl.a(shr.o) mint függőség; 64-biten nincs ilyen.

Van például egy ilyen üzenetem:
[code]
httpd: Syntax error on line 48 of /usr/local/etc/apache2/httpd.conf:
Cannot load libexec64/apache2/mod_access_compat.so into server:
rtld: 0712-001 Symbol access_compat_module was referenced

aix 7 -- új verzió, új kavarás

 ( NevemTeve | 2015. május 28., csütörtök - 6:59 )

Aszondja nekem a compiler, mi a fene az, hogy 'time_t st_atim.tv_sec'
Hát persze igaza van, tényleg minek írok én ilyet... bár én nem ezt írtam, hanem azt, hogy 'time_t st_atime' de úgy látszik, valami jószándékú #define ezt felülbírálta

[code]
/usr/include/sys/stat.h

#if _XOPEN_SOURCE>=700
#define st_atime st_atim.tv_sec
#define st_mtime st_mtim.tv_sec
#define st_ctime st_ctim.tv_sec
#define st_atime_n st_atim.tv_nsec
#define st_mtime_n st_mtim.tv_nsec
#define st_ctime_n st_ctim.tv_nsec
#define st_pad1 st_atim.tv_pad
#define st_pad2 st_mtim.tv_pad

Minden terminál egyenlő, de az xterm még egyenlőbb

 ( NevemTeve | 2015. március 13., péntek - 18:22 )

Mondjuk van egy konsole, ami azt állítja magáról, hogy TERM=xterm. Futtatjuk benne a 'vi'-t, Ctrl+Bal/Jobb billentyűk működnek (lehet, hogy a Shift+Nyíl is működne, ha a konsole nem nyúlná le).

Most futtassuk a 'TERM=konsole vi'-t, és vegyük örömmel észre, hogy Ctrl+Bal/Jobb billentyűk nem működik.

Akkor nézzük meg például a ncurses demo_keyok című programját.
[code]
TERM=xterm:
Keycode 561 01061, name kUP5
Keycode 520 01010, name kDN5
Keycode 555 01053, name kRIT5
Keycode 540 01034, name kLFT5
TERM=konsole:
Keycode 530 01022, name kUP5

dtelnet-1.3.4 preverzió

 ( NevemTeve | 2015. március 11., szerda - 17:59 )

Lassan új verzió lesz dtelnet-ből, nagy újdonság nincsen, csak annyi, hogy működik a 3x és 4x egérkattintás sor- illetve paragrafuskijelölés értelemben. Valamint hangolni lehet, hogy a beillesztést (paste), a jobb vagy a középső gomb csinálja-e.
Ide töltöttem a preverziót: dtelnet.exe

201500313.1650: Javított verziót feltöltöttem.

Bamba-3.6.25

 ( NevemTeve | 2015. február 24., kedd - 11:26 )

Na, vajon fordul régi AIX-on? Eltaláltad, nem fordul.

../nsswitch/winbind_nss_aix.c: In function 'wb_aix_user_attrib':
../nsswitch/winbind_nss_aix.c:634:36: error: 'S_PGID' undeclared (first use in this function)
../nsswitch/winbind_nss_aix.c:634:36: note: each undeclared identifier is reported only once for each function it appears in
../nsswitch/winbind_nss_aix.c: In function 'wb_aix_attrlist':
../nsswitch/winbind_nss_aix.c:776:4: error: 'S_PGID' undeclared (first use in this function)

terminal-howto bővülés: gnome-terminal

 ( NevemTeve | 2015. február 12., csütörtök - 16:38 )

http://web.axelero.hu/lzsiga/terminal.html#S0015

Nem sok, de ha valaki hibát talál benne, legyen szíves szóljon;)

Mi is van a bash-sal?

 ( NevemTeve | 2015. január 12., hétfő - 19:40 )

Mármint nem hallok semmit a hírekben, pedig olvasom a rádiót, azt mégis itt van három új patch: http://ftp.gnu.org/gnu/bash/bash-4.3-patches/

Szerk: na jó, mivel ChangeLog-ot nem látok, belenézek a patch-fájlokba...

http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-031

The new nameref assignment functionality introduced in bash-4.3 did not perform
enough validation on the variable value and would create variables with
invalid names.

http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-032

[code]

Verzióemlékeztető önmagamnak

 ( NevemTeve | 2014. október 8., szerda - 10:42 )

(Fordított időrendben)
[code]
2015.08.32. unixODBC 2.3.4
2015.08.22. unixODBC 2.3.3
2015.08.21. OpenSSH 7.1p1

recv gondja: errno=113 EHOSTUNREACH

 ( NevemTeve | 2014. szeptember 22., hétfő - 12:19 )

Vajon előfordulhat-e, hogy azt mondja a 'read' (avagy 'recv'), hogy EHOSTUNREACH = No route to host?

A jelek szerint igen, meg is lepte a programocskámat... Most az egyszer nem tudom az egzotikus platformot hibáztatni, CentOs 6.4, x86_64

Asszem az lesz a legjobb megoldás, ha azt a default programágat, ahol az 'ez a hiba nem fordulhat elő' van, szépen kiszedem, és helyette az 'ezt a kapcsolatot megette a fene' nevű ágat használom az 'egyéb hiba' esetén...

Pillanatnyi állapot:
[code]
rc2 = soc_errno;
len = 0;
switch (rc2) {

MySql AIX-on part 5/9

 ( NevemTeve | 2014. szeptember 22., hétfő - 10:29 )

Szóval a collect2 problémáján elegánsan túllendülünk a '-berok' opcióval, és áttérünk a következő problémá(k)ra.

Ugyebár a libtool ellenkezik a cmake-hit tanításaival, ő kézi erővel állítja el a statikus és a shared libet. Persze amíg van sed és perl, ez kezelhető, de azért zavar tud hozni egy-két apróság:

1. duplikált könyvtárak a linkelésnél (talán csak a hangsúly kedvéért):
[code] -o libmysqlclient.so\
CMakeFiles/libmysql.dir/libmysql_exports_file.cc.o\

AIX: linkelési hiba -- túlbuzgó collect2

 ( NevemTeve | 2014. szeptember 19., péntek - 13:10 )

Úgy tűnik nekem, hogy AIX-on a collect2 olyan konstruktorokra/destruktorokra is lecsap, amelyek ott vannak ugyan a *.a fájlban, de a konkrét executabléba nem kellenének. A példaprogram:

/* collect2_main.cc */

#include <cstdio>

int main ()
{
    fprintf (stderr, "A főprogram vagyok, semmi különös\n");
    fflush (stderr);
}

Futásának eredménye, ha csak úgy 'normálisan' linkeljük:

$ ./collect2_prob
A főprogram vagyok, semmi különös

MySql AIX-on: pfs_hton

 ( NevemTeve | 2014. szeptember 18., csütörtök - 17:26 )

Ugyebár itt tartottunk az imént: http://hup.hu/node/135300
Jobban megnézve az első és második menet xref-fájljáit, az tűnik fel, hogy az elsőben pfs_hton nem fordul elő. De a jó collect2 mégis úgy érzi, hogy az pedig kell...

ilyen egyébként (ha_perfschema.cc):

handlerton *pfs_hton= NULL;

MySql AIX-on: ki az a collect2?

 ( NevemTeve | 2014. szeptember 18., csütörtök - 6:20 )

Az előző adás folytatása: a g++ nem a 'ld' (sem a 'gld') nevű programot hívja, hanem az /opt/freeware/libexec/gcc/*/*/collect2-t. (Mondjuk a név nem ismeretlen, hiszen linuxon tényleg ő szokta kiírni a linkelési hibákat.)

Talán az lenne a legjobb, ha ennek a collect2-nek lenne valamilyen kimenete, amiben meggyónná, hogy mit és miért csinál. No, majd keresgélek.