CIB EKI API nyomor

 ( airween | 2010. április 16., péntek - 16:42 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Az egy dolog, de az a 3 warning elég csúnya.

Az első kettő csúnya :), a 3. "csak" flegmaság. Bár csak ez lenne a gondom :)

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.

file parancs mit mondd a libre? az meg szokta mondani a libct afaik.
ldconfig -vben feljon a lib amugy?

Őőőő 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

a -l NEM statikban keresi, hanem dynamicban. a statikus .a libeket kezzel ki kell irni, amihez linkelsz.

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.

sokat fejlesztek vele, es nem csak a man paget olvasgatom...
tapasztalatom szerint a -l nem talalja meg az .a -kat normalisan, de .so -kra tokeletesen megy. en valahanyszor staticot akarok linkelni, odairom explicit az .a fajlt.

google meg is erosit ebben (itt)

baz, bingo, ott a pont.
Explicit megadással megy, de nekem a -l után nem fogadja el.
Ha simán megadom a forrásfájl után, akkor statikusan összelinkeli.
Ha készítek egy linket sima .so suffixel a meglevő .so.1-re, akkor a "-l"-lel lefordul és műx.

Köszönöm szépen.

a.

szivesen :-)

csak hogy ne csak negativ repum legyen :D

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

milyen gcc? nem lehet, h bugos?

4.4.1, ez lenne az utolsó gondolatom, h bugos a GCC :)
Bár aztán...

Köszi:

a.

de ez nem gcc-kérdés, mert ezt a linker csinálja!

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.

elvben igazad van, gyakorlatilag meg baromsag, mert az -l -nek NEM CSAK AZT kene keresni a fenti man page alapjan. (en sem hittem el, en is kinyitottma, tenyleg ezt irja).

valaki szolhatna nekik... :)

Erdekes, mert windows alatt pl. .a-kat (pontosabban .a-kat es .dll.a-kat) keres. Lehet, hogy ha letorlod az osszes .so vegut, akkor keres .a-kat is? Nem tudom...
--

()=() 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... :)

Nem, sajnos igaza van, nem talal, mert eselytelen talalni. Valamiert megtalalja a .so.1 tipusu fajlokat is (ezert nincs file not found hibauzi), csak keptelen hasznalni oket.
--

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

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.

Lehet, h gcc bug, de meg nem eskudnek ra.
--

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

fúú, strace már nem tudom hányszor volt, és soha nem szerepel semmi olyan, h megnyitná azt a libet.
A parancssori argumentumok között ott van és hali.

opendir/readdir-t nezz
--

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

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.

Van tiszta PHP-s változatuk is, ami a PHP mcrypt modulját használja.
Kicsit nyúzni kell őket és kiadják neked..

Hello,

köszi, nem PHP-ban kell, inkább Python-ban szeretném megoldani, de megnézem ezt is.

a.

Aha. Köszi.