# [risolto] dev-libs/pth su armv7a

## VeLuca93

Ciao a tutti.

Ho un problema installando gentoo su un Toshiba ac100.

Tentando di installare kde, questo ha tra le dipendenze gnupg, che a sua volta dipende da dev-libs/pth.

Ma questo causa il seguente errore di compilazione:

```
pth_mctx.c: In function '__pth_mctx_set':

pth_mctx.c:480:2: error: #error "Unsupported Linux (g)libc version and/or platform"

```

Le linee di codice che causano l'errore sono:

```
/*

 * VARIANT 3: LINUX SPECIFIC JMP_BUF FIDDLING

 *

 * Oh hell, I really love it when Linux guys talk about their "POSIX

 * compliant system". It's far away from POSIX compliant, IMHO. Autoconf

 * finds sigstack/sigaltstack() on Linux, yes. But it doesn't work. Why?

 * Because on Linux below version 2.2 and glibc versions below 2.1 these

 * two functions are nothing more than silly stub functions which always

 * return just -1. Very useful, yeah...

 */

#include <features.h>

intern int pth_mctx_set(

    pth_mctx_t *mctx, void (*func)(void), char *sk_addr_lo, char *sk_addr_hi)

{

    pth_mctx_save(mctx);

#if defined(__GLIBC__) && defined(__GLIBC_MINOR__) \

    && __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 0 && defined(JB_PC) && defined(JB_SP)

    mctx->jb[0].__jmpbuf[JB_PC] = (int)func;

    mctx->jb[0].__jmpbuf[JB_SP] = (int)sk_addr_hi;

#elif defined(__GLIBC__) && defined(__GLIBC_MINOR__) \

    && __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 0 && defined(__mc68000__)

    mctx->jb[0].__jmpbuf[0].__aregs[0] = (long int)func;

    mctx->jb[0].__jmpbuf[0].__sp = (int *)sk_addr_hi;

#elif defined(__GNU_LIBRARY__) && defined(__i386__)

    mctx->jb[0].__jmpbuf[0].__pc = (char *)func;

    mctx->jb[0].__jmpbuf[0].__sp = sk_addr_hi;

#else

#error "Unsupported Linux (g)libc version and/or platform"

#endif

    sigemptyset(&mctx->sigs);

    mctx->error = 0;

    return TRUE;

}

```

glibc è installato, la versione è maggiore della 2.0, ma non sono definiti JB_PC nè JB_SP da nessuna parte in /usr/includeLast edited by VeLuca93 on Tue Dec 06, 2011 7:46 pm; edited 1 time in total

----------

## djinnZ

Strano.

Saresti così gentile da riportare qualcosa del genere *emerge -pv sys-libs/glibc dev-libs/pth sys-kernel/linux-headers sys-kernel/hardened-sources wrote:*   

> [ebuild   R   ] sys-kernel/linux-headers-2.6.39 
> 
> [ebuild   R   ] dev-libs/pth-2.0.7-r3  USE="-debug" 
> 
> [ebuild   R   ] sys-kernel/hardened-sources-3.1.3  USE="-build -deblob -symlink" 
> ...

  e, se riporta qualcosa, procedere alla stessa cosa con -aNDuv? Se hai da aggiornare gli headers ed il kernel fallo prima di provare a compilare pth e gnupg

Verifica anche che non hai dimenticato roba del genere CONFIG_CRYPT* o CONFIG_*CRC* etc.

----------

## VeLuca93

```
[ebuild   R    ] sys-kernel/linux-headers-2.6.39  4,583 kB

[ebuild  N     ] dev-libs/pth-2.0.7-r3  USE="-debug" 638 kB

[ebuild   R    ] sys-libs/glibc-2.13-r4  USE="nls -debug -gd -glibc-omitfp (-hardened) (-multilib) -profile (-selinux) -vanilla" 16,081 kB               
```

Quanto al kernel, uso una 3.0.8 compilata su un'altra macchina (cross-compiler) -- in ogni caso, ho copiato i sorgenti compilati in /usr/src/linux e non ha funzionato comunque

```
localhost src # cat /usr/src/linux/.config | grep -e CONFIG_CRYPT* -e CONFIG_*CRC*

CONFIG_CROSS_COMPILE="armv7a-hardfloat-linux-gnueabi-"

# CONFIG_CRASH_DUMP is not set

# CONFIG_CRAMFS is not set

CONFIG_CRYPTO=y

CONFIG_CRYPTO_ALGAPI=y

CONFIG_CRYPTO_ALGAPI2=y

CONFIG_CRYPTO_AEAD=m

CONFIG_CRYPTO_AEAD2=y

CONFIG_CRYPTO_BLKCIPHER=y

CONFIG_CRYPTO_BLKCIPHER2=y

CONFIG_CRYPTO_HASH=y

CONFIG_CRYPTO_HASH2=y

CONFIG_CRYPTO_RNG=m

CONFIG_CRYPTO_RNG2=y

CONFIG_CRYPTO_PCOMP=m

CONFIG_CRYPTO_PCOMP2=y

CONFIG_CRYPTO_MANAGER=y

CONFIG_CRYPTO_MANAGER2=y

CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y

CONFIG_CRYPTO_GF128MUL=m

CONFIG_CRYPTO_NULL=m

# CONFIG_CRYPTO_PCRYPT is not set

CONFIG_CRYPTO_WORKQUEUE=y

CONFIG_CRYPTO_CRYPTD=m

CONFIG_CRYPTO_AUTHENC=m

CONFIG_CRYPTO_TEST=m

CONFIG_CRYPTO_CCM=m

CONFIG_CRYPTO_GCM=m

CONFIG_CRYPTO_SEQIV=m

CONFIG_CRYPTO_CBC=y

CONFIG_CRYPTO_CTR=m

CONFIG_CRYPTO_CTS=m

CONFIG_CRYPTO_ECB=y

CONFIG_CRYPTO_LRW=m

CONFIG_CRYPTO_PCBC=m

CONFIG_CRYPTO_XTS=m

CONFIG_CRYPTO_HMAC=y

CONFIG_CRYPTO_XCBC=m

# CONFIG_CRYPTO_VMAC is not set

CONFIG_CRYPTO_CRC32C=y

CONFIG_CRYPTO_GHASH=m

CONFIG_CRYPTO_MD4=m

CONFIG_CRYPTO_MD5=y

CONFIG_CRYPTO_MICHAEL_MIC=m

CONFIG_CRYPTO_RMD128=m

CONFIG_CRYPTO_RMD160=m

CONFIG_CRYPTO_RMD256=m

CONFIG_CRYPTO_RMD320=m

CONFIG_CRYPTO_SHA1=m

CONFIG_CRYPTO_SHA256=m

CONFIG_CRYPTO_SHA512=m

CONFIG_CRYPTO_TGR192=m

CONFIG_CRYPTO_WP512=m

CONFIG_CRYPTO_AES=y

CONFIG_CRYPTO_ANUBIS=m

CONFIG_CRYPTO_ARC4=y

CONFIG_CRYPTO_BLOWFISH=m

CONFIG_CRYPTO_CAMELLIA=m

CONFIG_CRYPTO_CAST5=m

# CONFIG_CRYPTO_CAST6 is not set

CONFIG_CRYPTO_DES=y

CONFIG_CRYPTO_FCRYPT=m

CONFIG_CRYPTO_KHAZAD=m

CONFIG_CRYPTO_SALSA20=m

CONFIG_CRYPTO_SEED=m

CONFIG_CRYPTO_SERPENT=m

CONFIG_CRYPTO_TEA=m

CONFIG_CRYPTO_TWOFISH=m

CONFIG_CRYPTO_TWOFISH_COMMON=m

CONFIG_CRYPTO_DEFLATE=y

CONFIG_CRYPTO_ZLIB=m

CONFIG_CRYPTO_LZO=y

CONFIG_CRYPTO_ANSI_CPRNG=m

# CONFIG_CRYPTO_USER_API_HASH is not set

# CONFIG_CRYPTO_USER_API_SKCIPHER is not set

CONFIG_CRYPTO_HW=y

CONFIG_CRC_CCITT=y

CONFIG_CRC16=y

CONFIG_CRC_T10DIF=y

CONFIG_CRC_ITU_T=m

CONFIG_CRC32=y

CONFIG_CRC7=y

```

----------

## djinnZ

 *VeLuca93 wrote:*   

> cross-compiler

 è un problema specifico della tua architettura Sucsa ma non  avevo fatto caso all'uso di arm e probabilmente du uclibc (incompatibile con pth). Leggi qui e qui (mezza soluzione).

Quando cerchi con google non ti fermare ai primi risultati ...   :Wink:  lo so che cadono le braccia quando ci si trova una serie di post inutili ma alla fine qualcosa salta sempre fuori.

Apri un bug r riporta.

----------

## VeLuca93

Ho risolto aggiungendo 

```
-DJB_SP=8 -DJB_PC=9
```

alle CFLAGS/CXXFLAGS di dev-libs/pth

(i valori sono per qualsiasi toolchain arm-*-linux-gnueabi, almeno credo, e li ho trovati con un po' di uso di google e  ricerca nei sorgenti di glibc)

ho anche eseguito make test per verificare che i valori fossero corretti

----------

## djinnZ

apri un bug per riportare ai devel la situazione.

L'ebuild dovrebbe aggiungerle automaticamente od emettere un avviso alla loro assenza, secondo me.

Comunque è frustrante che la ricerca non fornisca molto di utile in simili casi e si debbano scorrere pagine su pagine.  :Confused: 

----------

## VeLuca93

Aperto il bug: https://bugs.gentoo.org/show_bug.cgi?id=393433

----------

## djinnZ

ok. Vista la tua civiltà ti do un consiglio non richiesto: -g0 nelle cflags (visto che usi -Os) rende impossibile il debug (e qualcuno dice che crea problemi, non ho ancora capito quali) ma fa risparmiare qualcosa in dimensioni.

Non so quanto sulla tua architettura ma puoi fare una prova e vedere di quanto fai dimagrire qualche applicativo.

----------

## VeLuca93

 *djinnZ wrote:*   

> ok. Vista la tua civiltà ti do un consiglio non richiesto: -g0 nelle cflags (visto che usi -Os) rende impossibile il debug (e qualcuno dice che crea problemi, non ho ancora capito quali) ma fa risparmiare qualcosa in dimensioni.
> 
> Non so quanto sulla tua architettura ma puoi fare una prova e vedere di quanto fai dimagrire qualche applicativo.

 

Grazie per il suggerimento  :Wink:  ma qual è la differenza tra -g0 e strippare i risultati?

----------

## djinnZ

Non viene creato alcun elemento di debug, direttamente in fase di compilazione.

La differenza con un binario su cui ha lanciato strip --strip-debug non dovrebbe esserci, ma dovresti metterci meno.

Qualche ricer sostiene che dovrebbe consentire ai nuovi algoritmi di ottimizzazione di operare meglio ma mi pare assai strano.

----------

