NevemTeve blogja

Naná, majd elsőre fordul, mi?

$ cd /usr/local/src/gdb-7.10.1/sim/ppc
$ make
/bin/sh ./../../gdb/common/create-version.sh ./../../gdb \
      version.c
Usage: mv [-I] [ -d| -e] [-i | -f] [-E{force|ignore|warn}] [--] src target
   or: mv [-I] [-i | -f] [-E{force|ignore|warn}] [--] src1 ... srcN directory

Namostan a 'version.c' előtt még van pár érték nélküli változó:

$(SHELL) $(srcroot)/gdb/common/create-version.sh \
$(srcroot)/gdb \
$(host_alias) $(target_alias) version.c

Már csak meg kellene tudni, hogy miért nincsenek idézőjelek között, és/vagy miért nincs értékük...

Egy FTP-szerver azt mondta nekem:

421 Timeout - try typing a little faster next time

Egy másik meg, kapcsolatbontásnál:

221 You could at least say goodbye.

Nem tudom, mi lesz még itt, ha öntudatra ébrednek a szoftverek...

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);

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:

export CFLAGS="$CFLAGS $CPPFLAGS"
export CXXFLAGS="$CXXFLAGS $CPPFLAGS"

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ő tippem az, hogy a 32-bites változatéból kell kiindulni, csak egy darab négyest flexibilisebbre venni:

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.

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

=== 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:
64-bit: Sizes of types: SQLINTEGER:4 SQLLEN:4 SQLSETPOSIROW:2

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.

Akkor már csak annyi dolgom van, hogy az ODBC-ról és a unixODBC-ről mindenféle infókat gyűjtsek, tesztprogramok készítsek (egyelőre a meglévő Oracle-hez), amiket aztán nagyon könnyű lesz átirányítani a másik gyártó adatbázisára. (Én meg Napóleon vagyok.)

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:

# 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
6      /                             unix

Azért ez nem rossz. Kivéve (most jön a banénhéj), hogy időnként dlopen-nel hivogatják egymást a komponensek, de persze verziószám nélkül:

Breakpoint 1, 0x09000000000d723c in dlopen () from /usr/lib/libc.a(shr_64.o)
1: (char *)$r3 = 0xfffffffffffd290 "libclntshcore.so"

vagyis ha eljő egy boldog nap, amikor 13-as verziót telepítek (vagy 8-ast, mert erőt vesz rajtam a nosztalgia), akkor úgy összekavarodnak, ahogy kell.

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)

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'.

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ó

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...

Miért is menne elsőre?! Azt mondja, hogy:

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:
sha256p8-ppc.s: line 11: invalid opcode or pseudo-op

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:

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
from module /usr/local/libexec64/apache2/mod_access_compat.so
but a runtime definition of the symbol was not found.

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

/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
#define st_pad3    st_ctim.tv_pad
#endif

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.

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
Keycode 514 01002, name kDN5
Keycode 524 01014, name kRIT5
Keycode 519 01007, name kLFT5

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.

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)

20150224.1027: Ilyet talál a google: https://bugzilla.samba.org/show_bug.cgi?id=4447

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

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

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

When bash is running in Posix mode, it allows signals -- including SIGCHLD --
to interrupt the `wait' builtin, as Posix requires.  However, the interrupt
causes bash to not run a SIGCHLD trap for all exited children.  This patch
fixes the issue and restores the documented behavior in Posix mode.

(Fordított időrendben)

2015.08.32. unixODBC 2.3.4
2015.08.22. unixODBC 2.3.3
2015.08.21. OpenSSH 7.1p1
2015.07.09. OpenSSL 1.0.1p 1.0.2d
2015.06.30. OpenSSH 6.9p1
2015.06.12. OpenSSL 1.0.1o 1.0.2c
2015.06.11. PHP     5.6.10
2015.03.19. OpenSSL 1.0.1m 1.0.2a
2015.03.18. OpenSSH 6.8p1
2015.01.15. OpenSSL 1.0.1l
2015.01.08. OpenSSL 1.0.1k
2014.12.18. PHP     5.6.4
2014.10.15. OpenSSL 1.0.1j
2014.10.07. OpenSSH 6.7p1
2014.10.05. bash    4.3.30
2014.09.04. Midnight Commander 4.8.13
2014.08.06. OpenSSL 1.0.1i

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) {
case SCEWOULDBLOCK:
if (mcb.rdebuglevel>1) {
S3I_DebugLineT ("S3IR_read_soc(%d): WOULDBLOCK\n"
, (int)rdp->pio->sock);
}
rc = S_RD_NODATA; /* nincs mit olvasni */
break;

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):

        -o libmysqlclient.so\
        CMakeFiles/libmysql.dir/libmysql_exports_file.cc.o\
        -lpthread libclientlib.a ../dbug/libdbug.a ../strings/libstrings.a\
        ../vio/libvio.a ../mysys/libmysys.a -lz\
        /usr/local/lib/libssl.so\
        /usr/local/lib/libcrypto.so\
        /usr/local/lib/libcrypto.so\
        ../dbug/libdbug.a ../mysys/libmysys.a ../strings/libstrings.a\

Mindegy, a shared lib jól jön létre. Remélem, legalábbis.

Ú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

Ha hozzálinkelünk egy másik objektet, amit nem hívunk és nem használunk ugyan, de amiben van egy globális objektum, akkor annak azért lefut a konstruktora (AIX-on és linuxon is):

$ ./collect2_prob_o
HibaProvokalo: Nekem qrvára nem kellene futnom
A főprogram vagyok, semmi különös