référence non définie à sync_fetch_and_add_4

Question

Chaque fois que j'essaie d'utiliser __sync_fetch_and_add avec -m32 sur une machine 64 bits, j'obtiens l'erreur suivante, alors qu'il compile bien avec un 64 bits normal. J'utilise le compilateur gcc 4.1.2. Quel peut être le problème et quelle est la solution ?

replication.cpp:(.text+0xb3b): undefined reference to `__sync_fetch_and_add_4'
replication.cpp:(.text+0xb82): undefined reference to `__sync_fetch_and_add_4'
replication.cpp:(.text+0xcc2): undefined reference to `__sync_fetch_and_add_4'
/tmp/cc7u9FLV.o: In function `potential_barrier_leader(unsigned int, pthread_barrier_t*)':
replication.cpp:(.text+0xd3f): undefined reference to `__sync_fetch_and_add_4'
replication.cpp:(.text+0xd54): undefined reference to `__sync_fetch_and_add_4'
/tmp/cc7u9FLV.o:replication.cpp:(.text+0xdb0): more undefined references to `__sync_fetch_and_add_4' follow
collect2: ld returned 1 exit status
make: *** [all] Error 1

Answer 1

L'utilisation -mars=i486 a fait l'affaire pour moi.

Answer 2

Essayez d'utiliser un compilateur GCC plus récent (par exemple GCC 4.6). J'ai essayé de compiler avec gcc -S -O3 -m32 -fverbose-asm sync-3.c le fichier test gcc/testsuite/gcc.c-torture/compile/sync-3.c et cela fonctionne. Mon gcc (sur Debian/Sid/AMD64) est le compilateur système gcc 4.6.2.

Answer 3

Hahah ! il y a 5+ "librairies atomiques standard" (+ support du noyau) c'est loin d'être de l'atomique mais n'en tenez pas compte, ce n'est qu'une distraction opportune.

Donc vous construisez, c'est à dire la glibc et vous obtenez cette erreur (c'est mon cas).

glibc-2.11.x s'attend à ce que gcc-4.4.x le définisse en interne, et vous avez gcc sans bu Il est probable que vous n'ayez pas spécifié l'arc que gcc accepte (à cause des directives lacunaires). glibc aime le 786, gcc veut du 386 et des chiffres 786 peut-etre. utiliser "nativ opt(march) et opt(mtune) SONT NON OPTIONNELS gcc construit mal sans eux (probablement). sans eux (probablement)

vous ne trouverez pas d'en-tête ou de libfoo qui le définisse (pour ainsi dire)

pour linux-gnu vous pouvez utiliser (une construction simple pour moi)

cd gcc-4.4.foo
./configure --with-glibc-version=2.11 --enable-threads=posix \
--disable-cloog --disable-ppl --disable-libssp --enable-__cxa_atexit \
--disable-rpath --disable-nls --disable-bootstrp --disable-multilib \
--with-system-libunwind

IMPORTANT : si vous compilez gcc sans mtune march correctement, gcc ne définira pas sync_fetch_and_add (p.s. glibc sync_fetch_and_add_4 est juste une macro pour sync_fetch_and_add qui, aga glibc s'attend à ce qu'il soit défini)

De plus, si vous remplacez gcc-3.foo par gcc-4.4.foo et que vous compilez, vous pouvez avoir besoin de :

[ -n "$newgnu" ] && CFLAGS="$CFLAGS -march=native -mtune=native "
[ -n "$newgnu" ] && \
CFLAGS="$CFLAGS -std=gnu89 " && CPPFLAGS="$CPPFLAGS -std=gnu89 "

Je viens d'en avoir besoin (newgnu) pour construire binutils-ver/ : -Wstrict-aliasing=0

cd glibc-2.foo/
./configure  --with-headers=/usr/src/linux/usr/include \
--enable-kernel=2.2.foo \
--disable-profile --disable-sanity-checks --with-tls \
--disable-rpath --disable-nls

• Merci au gars en Hollande d'avoir posté --std qui pourrait être un problème pour les utilisateurs de gcc !

• non grâce aux comités qui changent continuellement et créent aussi des "standards" qui rendent les dépendances problématiques dans gcc :( utilisez .h ou .c de manière appropriée pour foo "builtin" pour ajouter des fonctionnalités que vous voulez dans votre code comme tout le monde ! !!

Amusez-vous bien :)

Answer 4

Avec les anciennes versions de GCC (4.5 par exemple), vous pouvez rencontrer le problème de __sync_fetch_and_add() qui n'est pas déclaré lorsque vous utilisez le pilote g++ au lieu de gcc pour lier une bibliothèque partagée.

Historique : __sync_fetch_and_add est défini dans static libgcc et absent de la bibliothèque partagée libgcc_s.

Il suffit donc d'ajouter -lgcc pour résoudre le problème. Mais il existe une solution plus élégante.

Voir ici pour des informations complètes et des solutions de contournement :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563