Kevin Kofler (./6) :
Pour ld-tigcc, un relogement vers un symbole de la forme libname@nnnn est toujours une importation, il ne va pas aller chercher le nom du binaire que tu es en train de linker pour vérifier que ce n'est pas le même nom. (D'ailleurs, quand tu exportes un label de la forme libname@nnnn, ld-tigcc ne va pas vérifier la partie libname non plus, tu peux mettre n'importe quoi et il en fera toujours une exportation.) Et évidemment un libcall ne peut pas être PC-relatif, donc forcément ça va foirer.

C'est là que le concept est mauvais :
- il ne filtre pas les exports bogués, tu ne t'en rends compte que par des bugs au run-time, alors qu'il sont détectables à la compilation
- il y a un abus de la directive xdef, qui sert à rendre un label visible globalement tout autant qu'à exporter une adresse dans un binaire (fonction ou variable). Un symbole "export" spécifique pour les dll et les libs statiques aurait évité ce genre de confusions. Mais ça, c'est plus de la faute de l'assembleur.
- les bcc/jsr/jmp lib@xyzt devraient être vérifiés, et assemblés en pc-relatif si "lib" correspond au nom du binaire en cours d'assemblage (et si les adressages sont pc-relatifs pour les jsr/jmp évidemment)

Bref, à mon sens, tout ça est du bricolage. Et ça m'emmerde de devoir suivre ces règles dans mon implémentation pour obtenir une compatibilité source, je trouve ça mal foutu...