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

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:


#define CURL_SIZEOF_LONG __SIZEOF_LONG__

Szerk:
A CURL_SIZEOF_CURL_SOCKLEN_T viszont maradhat, az minden platformon 4 byte. (Itt a 'minden platform' jelentése: linux/x86, linux/x86_64, aixppc/32, aixppc/64)

( uid_194 | 2015. 09. 25., p – 13:34 )

Tobbek kozt ezert celszeru a kulonbozo platformra forditott headereket/libeket kulon konyvtarba (pl /usr/local/{x86-64,x86}/{lib,include}) tenni.

Szerencsere mind a forditonak, mind a dinamikus linkernek meg lehet mondani, hogy megfelelo helyen keresgeljen, anelkul, hogy ezt minden forditasnal el kene neki magyarazni.

--
|8]

Hát igen, ha mondjuk cross-compilationt csinálunk, akkor ez precízen megvan, de ha egyetlen gépen vannak 32- és 64-bites komponensek, akkor rászaladhatunk arra, hogy van pl /usr/local/lib és /usr/local/lib64, de nincs /usr/local/include és /usr/local/include64... persze csinálhatunk magunknak...

Es baj az ha nincs? gcc peldaul (doksi szerint) alapbol keres /usr/$target/include alatt.

Nalam pl egy gepen van 32 es 64-bites libek kevereke, es ezek csak akkor tesznek /usr/include ala valamit, ha az tenyleg platform fuggetlen, egyebkent /usr/include/x86_64-linux-gnu/ ala pakolnak.

Pelda: 


[algernon:~] $ locate tiff.h
/usr/include/i386-linux-gnu/tiff.h
/usr/include/x86_64-linux-gnu/tiff.h
[algernon:~] $ cat test.c
#include <tiff.h>
#include <stdio.h>
int main () { printf ("hi!\n"); return 0; };
[algernon:~] $ gcc test.c -o foo64 ; gcc test.c -o foo32 -m32
[algernon:~] $ file foo64 foo32
foo64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=48901d0e9de008838d77bb81b3d2d6bea72f4da7, not stripped
foo32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=71731f360a3a847181fd6721a2f43f17113eee87, not stripped
[algernon:~] $ ./foo32 && ./foo64
hi!
hi!

--
|8]

Ilyen esetben termeszetesen meg kell adni -I-vel, mint egyebkent, felteve, hogy #include <openssl.h> -t hasznalsz, ha <openssl/openssl.h>, akkor nincs dolgod, mert /usr/local/include alatt keres eloszor, aztan ha ott nincs, akkor /usr/local/x86_64-linux-gnu/include alatt (vagy forditva, ahogy az ember beallitja neki).

--
|8]

Jo kerdes, reg volt, hogy ezzel szorakoztam, mostanaban Debianon ez a default. Ranezesre ./configure kap egy --enable-multiarch-ot, es ennyi. De ./configure --help kimeneteben feltehetoleg van tipp erre.

Persze recompile nelkul is van erre lehetoseg, arrol ilyesmi doksit talaltam hirtelen: http://www.mingw.org/node/25 (ez ugyan mingw-hez irodott, de kis atalakitassal mukodik mashol is).

--
|8]

( persicsb | 2015. 09. 25., p – 14:20 )

Nem értem az int64_t cserét longra. Mi értelme van egy platformfüggetlen adattípust lecserélni egy platformfüggőre, hogy ha cél lenne a platformfüggetlen fordítás? Ez egy olyan változtatás, ami nem jó.

Ezt nem kell érteni, a curl meggenerálja, ahogy neki tetszik; csak amit meggenerál, az vagy 32-bithez jó, vagy 64-bithez, ha mi azt szeretnénk, hogy mindkettőhöz jó legyen egyetlen curlbuild.h header, akkor egy kicsit haxolni kell. Esetünkben a haxolás legjobb módja, ha a 32-bitesre generált header-ben egyetlen sort megváltoztatunk.

PS: disclaimer: azt persze nem tudom garantálni, hogy ez bárki más rendszerében is pont ugyanígy működjön...

Szerk: hozzápiszkáltam az Original Post-hoz, hogy kevésbé zavaros legyen a mese...

Nem én vagyok a curl szóvivője, de pl. el tudom képzelni, hogy a configure script egy listáról dolgozik, annak alapján keresi az első olyan típust, ami az aktuális platformon használható, és 64-bites. Ha pl. a lista úgy néz ki, hogy 'long -- int64_t -- long long -- __int64', akkor 64-bites unixon a 'long' nyer, 32-bites unixon az 'int64_t'

A következő a helyzet: Ha lefordítom a curl-t 32-bitre, keletkezik egy /usr/local/include/curl/curlbuild.h, ami csak 32-bites programokhoz jó.

Ha lefordítom 64-bitre, akkor keletkezik egy header, ami csak 64-bites programokhoz jó.

Történetesen én most benne vagyok egy átmenetben 32->64 bit irányban, ami legalább tíz éve tart, és legalább ugyanannyi van még hátra, tehát azt szeretném, ha 32- és 64-bitre is tudnám fordítgatni a curl-t használó programokat.

Ezért addig nézegettem össze a két curlbuild.h-t míg rá nem jöttem, hogy a 32-bitesen egy sort kell csak meghaxonlni, hogy univerzális eredményt kapjunk.

Ez a változás pedig a CURL_SIZEOF_LONG beállítása, lásd az original post végefelé.

Na de ez nem fog menni úgy, hogy 1 db header file-od van. Pontosabban kurvanagyot hackelgethetsz mindig, de sokkal jobb megadni, hogy a 32 bites programok a 32 bites headert használják, amikor fordulnak, a 64 bitesek meg a 64 biteseket. Ahelyett, hogy minden egyes komponensnél elbaszakodnál azzal, hogy 1 headerrel forduljon minden.

Az off_t 32-bites architekturan alapbol 32 bites, nem 64, de ha -D_FILE_OFFSET_BITS=64 meg van adva, akkor off_t 64 bites, mig long tovabbra is 32: 


[algernon:~] $ cat test.c
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
int main () { printf ("%d %d\n", sizeof(off_t), sizeof(long)); return 0; }
[algernon:~] $ gcc test.c -o foo -m32 && ./foo
4 4
[algernon:~] $ gcc test.c -o foo -m32 -D_FILE_OFFSET_BITS=64 && ./foo
8 4

--
|8]

De a curl_off_t-rol van szo, nem az off_t-rol.

http://opensource.apple.com/source/curl/curl-57/curl/lib/README.curl_of…

Previously, before 7.19.0, the curl_off_t type would be rather strongly
connected to the size of the system off_t type, where currently curl_off_t is
independent of that.

The strong connection to off_t made it troublesome for application authors
since when they did mistakes, they could get curl_off_t type of different
sizes in the app vs libcurl, and that caused strange effects that were hard to
track and detect by users of libcurl.