CIB EKI API nyomor

C/C++

Hello,

próbált már valaki a CIB Bankon keresztüli fizetéshez mellékelt sakiCrypt libet használni?

A mellékelt példa program: 

gcc -lsakiCrypt -Wall -O2 sakide.c 
sakide.c: In function ‘keyinfo’:
sakide.c:464: warning: implicit declaration of function ‘ctime’
sakide.c:469: warning: format ‘%s’ expects type ‘char *’, but argument 8 has type ‘int’
sakide.c: In function ‘doCrypt’:
sakide.c:406: warning: ‘cRes’ may be used uninitialized in this function
/tmp/ccWvgYdQ.o: In function `keyinfo':
sakide.c:(.text+0x2c): undefined reference to `ekiGetKeyInfo'
/tmp/ccWvgYdQ.o: In function `doCrypt':
sakide.c:(.text+0x21c): undefined reference to `ekiEncodeUrl'
sakide.c:(.text+0x28c): undefined reference to `ekiDecodeUrl'
/tmp/ccWvgYdQ.o: In function `usage':
sakide.c:(.text+0x3f7): undefined reference to `ekiGetLibVersion'
/tmp/ccWvgYdQ.o: In function `Init':
sakide.c:(.text+0x976): undefined reference to `ekiGetLibVersion'
collect2: ld returned 1 exit status

szal' egyik szimbólumot sem tudja feloldani, amit egyébként a lib hivatott...

Köszi:

a.

( NagyZ v | 2010. 04. 16., p – 16:47 )

es? attol hogy idairod a -l -t, meg nem biztos, hogy meg is talalja. -L.? ott van helyben? kompatibilis a te dolgoddal? (ertsd jo libc verzio, etc).

es? attol hogy idairod a -l -t, meg nem biztos, hogy meg is talalja. -L.?
megtalálja, a /usr/lib/ alatt ott van, nem kell "-L.".

kompatibilis a te dolgoddal? (ertsd jo libc verzio, etc).
hát ez az amit nem tudok, 1999-es az egész kód/doksi. A history-ben libc6 2.2.5 van, nálam 2.10.1 - ez nem tudom mennyire kompatibilis. Ezen kívül semmi hivatkozás/igény nincs.

Gondoltam hátha valaki használta már, és nem 10+ éves rendszeren üzemelteti.

Köszönöm:
a.

Őőőő izé, szerintem keversz dolgokat.
A gcc a -l kapcsoló után álló szimbólumot statikus lib formátumban keresi (ar formátum), lásd: 

file /usr/lib/libsakiCrypt.a
/usr/lib/libsakiCrypt.a: current ar archive

Az ldconfig (szerintem) a dimanikusan betölthető futáshoz szükséges libeket tartalmazó könyvtárakat kezeli.
És igen, a .so ott van a kimenetben.

Tehát ott két file van:
/usr/lib/libsakiCrypt.a

és 

file /usr/lib/libsakiCrypt.so.1.1 
/usr/lib/libsakiCrypt.so.1.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

Azért köszönöm a szándékot:

a.

ps: még annyit ehhez a vonalhoz, hogy ha nem találná a lib-et, akkor _azt_ írná ki, nem a szimbólum feloldásra panaszkodna: 

gcc -Wall -O2 -lsakiCrypt1 ... 
/usr/bin/ld: cannot find -lsakiCrypt1
collect2: ld returned 1 exit status

hmm... 

man gcc
...
  -llibrary
  -l library
      Search the library named library when linking. ...

      [...]

      The linker searches a standard list of directories for the library,
      which is actually a file named liblibrary.a. ...

      The directories searched include several standard system directories plus any that you specify with -L.

      Normally the files found this way are library files---archive files whose members are object files.
      The linker handles an archive file by scanning through it for members which define symbols
      that have so far been referenced but not defined.  But if the file that is found is an ordinary
      object file, it is linked in the usual fashion.  The only difference between using an -l option
      and specifying a file name is that -l surrounds library with lib and .a and searches several directories.

plusz:
http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html

szal' ez:
a -l NEM statikban keresi, hanem dynamicban. a statikus .a libeket kezzel ki kell irni, amihez linkelsz.
imho butaság.

a.

bár azt nem értem, h a man is így írta és az a pár doksi is, akkor mijavér' van.

"nem talalja meg az .a -kat normalisan"
kb 2 éve nem nagyon csináltam semmit C-ben, ez most így meglepett...
És miért a szimbólum feloldására panaszkodott, miért nem arra h nem találja a lib-et? valami nem ok itt, de most már mindegy, kész a Python modul :)

csak hogy ne csak negativ repum legyen :D
??

Aham, és akkor ha a gcc kap egy -l kapcsolót, akkor hív exec-el egy ld-t?

A gcc man-ban van egy ilyen: 

The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a

Szerinted a gcc adja át az ld-nek a teljes nevet vagy az ld találja ki?

És még mindig ott a kérdés: miért azt mondja h nem találja a szimbólumot, miért nem a file-ra rinyált?

Köszi:

a.

Baromi egyszeru kideriteni, mit csinal a gcc: be kell dobni a kalapba a -v flaget.

Amugy meg azert nem talalja meg, mert a gcc mindig .so-t keres, nem .so.valamit. Ha megnezitek, akkor az osszes libnek van .so symlinkje, talan nem veletlenul.

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Egyrészt a manban és sok helyen is az van, h .a-t (is) keres.
Másrészt a kérdés erről szól, hogy miért nem azt mondja hogy magát a .so-t nem találja, miért a symbol-ra rinyál?

Így érthető a kérdés? :)

Valahol írtam egy példát hogy szándékosan elírtam a lib nevét, pl "-lsakiCrypt1"-re, és ekkor jelezte h nem találja.

a.

Szerinted a gcc adja át az ld-nek a teljes nevet vagy az ld találja ki?

gcc -v, és hajrá.

de borítékolom, hogy egy-az-egyben adja tovább a -l opciókat.

És még mindig ott a kérdés: miért azt mondja h nem találja a szimbólumot, miért nem a file-ra rinyált?

strace -v és hajrá.

van erre is egy tippem: szerintem talál valamit fájlt, azért nem rinyál. csak abban nem az van, mint amit várnál... :)

Szal' mégis gcc bug?
A bugreporttal szembeni komplexusomat az okozza gcc esetében, hogy egyszer vmi overlock-olt gépen (amiről nem tudtam h az) állandóan lehalt a kernel fordítás, mindig máshol, én meg bejelentettem...

Így aztán most alaposan felmérném a saját hülyeség-faktoromat mielőtt nekiállnék riportolgatni, de most hogy írjátok hogy ez tényleg lehet akár rendellenes is, még meggondolom :)

Köszi:

a.

( tomi66 | 2010. 04. 16., p – 18:31 )

Ez pontosan mire jó ? ...csak érdeklődés szintjén.

Régebben Inter-Európa Bank volt, most már CIB az egyik bank, aki lehetőséget ad kártyás fizetésekre webáruházakból pl. Ennek van egy protokollja, amit 1999-ben írtak le (korábban, de ez az utolsó verzió), és adtak egy "dev" "csomagot" :), amivel lehet C-ben fejleszteni, ergo (majd') mindenhová be tudod ágyazni (PHP, Python, ...).
(Működik Windowson is, vannak külön *BSD, Solaris binárisok).

Van egy minta progi is ami le van fordítva statikusan és dinamikusan linkelve is (ez is a csomag része), a statikusat használom is, de jó lenne nem exec()-el hívogatni ezt a programot.
(a dinamikus valamiért nem futott, már nem emlékszem miért hagytam abba a küzdelmet vele)

HTH:

a.