libcryptopp.a git lfs This repository is over its data quota.

[ghost]

Ho installato il pacchetto git-lfs per poter scaricare la libreria statica libcryptopp dal vostro repository ma senza successo. Questo è il messaggio d'errore in fase di clone:

$ git-lfs filter-process
Error downloading object: cie-pkcs11/libcryptopp.a (48c7413): Smudge error: Error downloading cie-pkcs11/libcryptopp.a (48c74132c759246c53ebe9e957a39c3af7876e41e5a9a4b2ff1047506c461dbf): batch response: 
This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

le alternative sono 2:

• inserire la libreria nel repository git compressa con xz che riduce moltissimo, sotto i 100MB (limite di github)
• acquistare da github la banda

Vediamo se da aprile sarà possibile scaricare il repository completo. Comunque nel mio fork ho messo la versione 8.2 compilata dal repository ufficiale e compressa con xz ridotta a 15MB.

[ocampana]

In verità la soluzione corretta sarebbe non embeddare la dipendenza nei sorgenti. Con gli autotools e cmake è possibile controllare la presenza per compilare della libreria nella minima versione richiesta al fine di non avere il problema che firefox non è in grado di risolvere tutti i simboli. Con eclipse CDT sembra essere impossibile: nella documentazione non è citata e l'unica FAQ che ha a che fare con questo tema dimostra che CDT non lo gestisce.

Quindi la soluzione corretta è passare ad un sistema di build in grado di gestire la dipendenza a build time, perché aprirebbe la cosa anche a scenari interessanti, come il porting su ARM.

[ghost]

@ocampana gli autotools e cmake in fase di compilazione si limitano a dare l'errore di assenza libreria, lasciando al sistemista/utente finale di ricompilare la libreria corretta. L'idea di incomporare la libreria all'interno del repository github è solo per comodità che sicuramente ha i suoi inconvenienti, ma alla fine l'utente non perde tempo a capire cosa non va nella compilazione, certo anche una buona documentazione risolverebbe, ma bisogna accontentarsi di quello che si ha.

Per quanto riguarda eclipse CDT è una semplice gui a g++/gcc passando il parametro corretto g++ in fase di compilazione finale della libreria, risolve tutti simboli segnalando quelli mancanti, anche compilando con make/cmake si avrebbe lo stesso problema se il parametro non verrebbe passato. gcc/g++ non lo fanno in automatico bisogna chiederglierlo.

[ocampana]

Non è vero:

• find_package di cmake supporta il riconoscimento delle versioni, come si evince dalla sua documentazione.
• per gli autotools esiste la macro PKG_CHECK_MODULES che controlla la versione, come spiegato nella sua documentazione

Vorrei altresì far notare che cryptlib.h in cascata include config_ver.h che definisce:

• CRYPTOPP_MAJOR
• CRYPTOPP_MINOR
• CRYPTOPP_REVISION

Quindi basterebbero in po' di #if e#error per gestire la compilazione corretta direttamente dal preprocessore, fallendo in modo esplicito.

Non ci sono motivi tecnicamente validi per embeddare una libreria precompilata nel repository.