Sorry, za trochu odbočující komentář - dotaz. Píšu *.so knihovnu - PAM modul do linuxu pro přihlašování přes kartičku a dělá, co bych od něj očekával (zatím jen přečte login a heslo a odsouhlasí to). Když ho ale dynamicky slinkuju s -lpthread (aniž bych jakoukoli pthread funkci volal), přestane fungovat a zatuhne to po přečtení hesla, tj. nejspíš při uvolňování té so knihovny. Přitom mi normálně v jiných programech (dynamicky přilinkované) pthread fungují a navíc tomu modulu nevadí staticky přilinkovaná libpthread.a ani jiná dynamicky přilinkovaná knihovna (zkoušel jsem třeba -lm nebo -ljpeg). To jsem zvědavý, jestli mi někdo poradí, byl bych moc vděčný.
Jak mas stary glibc? Nemas nahodou Debian ?
Je to stejnej problem jako s kombinaci ORACLE+PHP+APACHE. V podtste jde o to, ze fce jako fclose apod. nejsou thread safe. A kdyz natahnes do pameti libpthread tak se dynamicky prilinkujou jejich thread safe alternativy(zmeni se tabulka pointeru na fce). Kdyz pak odloadujes tu knihovnu, tak to hodi segfalt v okamziku, kdyz sahnes na prvni socket otevrenej tou thread safe variantou.
U glibc 2.1 nejde libpthread odloadovat. Prej to neni chyba. A nikdo to nebude opravovat. V nejnovejsich verzich glibc uz to prej funguje.
Dík moc. Nešlo mi to na SuSE 8.2, glibc-2.3.2-6, o víkendu jsem se na to kouknul na svém obstarožním domácím MDK 9.0 (pokud vím glibc-2.2) a normálně mi to fungovalo. Což je divný, čekal bych, že čím novější glibc, tím líp. Ovšem "fungovalo" znamená, že prošel můj jednoduchý testík, třeba se to nezakouslo jen náhodou.
Taky je dost divné, že když si napíšu vlastní PAM aplikaci (která jen ověřuje login a heslo a nic potom nedělá), tak s tím mým modulem (co ho linkuju -lpthread) normálně funguje i na tom SuSE 8.2 s glibc 2.3, zatímco su neprojde a zakousne se. Zdá se, že lpthread + SuSE 8.2 + su = velká ostuda.
ČLÁNKY DO MAILU