Discussion :

[peter3000]

Bonjour,

J'ai du code C que je compile sous Visual C++ Express 2008 pour en faire des librairies statiques (des .lib).

J'utilise ensuite ces .lib pour créer un éxécutable, dans un autre environnement.

Lors du link de ces .lib (dans un environnement hors Visual), j'ai 2 symboles non résolus:
__ftol2_sse et
__chkstk

Je suis convaicu que c'est Visual qui a inséré ces symboles au moment de la génération de mes librairies, mais je n'arrive pas à savoir quelles propriété de des mes projets (qui font des .lib) je dois modifier pour faire disparaître ces symboles.

Merci pour votre aide !

[Mac LAK]

Une de tes librairies statiques utilise simplement elle-même une librairie, que tu n'as pas incluse dans ton projet exécutable.

Un début de réponse sur cette page, j'ai vu aussi pas mal de choses concernant l'utilisation de DirectX dans une application console comme cause d'une telle erreur de link.


A priori, cela peut se régler en effectuant cette opération :

To solve this open the Project Properties, then goto:
C/C++ -> Code Generation
... and change:
Basic Runtime Checks from "Both (/RTC1, equiv. to /RTCsu)" to "Default".

[peter3000]

Merci.

J'ai déjà fait la manip de la citation:

Envoyé par Forum MSDN
To solve this open the Project Properties, then goto:
C/C++ -> Code Generation
... and change:
Basic Runtime Checks from "Both (/RTC1, equiv. to /RTCsu)" to "Default".

Cela ne résoud que les symboles __RTC_Shutdown ou __RTC_InitBase (ainsi que quelques autres)...

Ceux dont je parle restent.

Sous Visual C++ Express, j'ai fait un "main" et je viens lui linker les librairies. Pas de soucis SAUF si dans Propriétés/Propriété de configuration/C C++/Génération de code je choisis dans le champ de mettre "non" (/NODEFAULTLIB) dans "Activation de la génération minimale" (au lieu de "oui (Gm)")
Auquel cas, je retouve mes soucis de link (plus d'autres).
Quelle est la(les) lib(s) qui me manque(nt) ? Où est(sont)-elle(s) sur le PC ?

Je ne comprends pas ce qu'il se passe car je n'ai pas les symboles en question dans mon code: c'est donc Visual qui les y ajoute à la création de la librairie... Cela a pour conséquence la création d'une librairie non exportable. Il doit bien y voir un moyen de ne pas ajouter ces choses ?

[Mac LAK]

Sous Visual C++ Express, j'ai fait un "main" et je viens lui linker les librairies. Pas de soucis SAUF si dans Propriétés/Propriété de configuration/C C++/Génération de code je choisis dans le champ de mettre "non" (/NODEFAULTLIB) dans "Activation de la génération minimale" (au lieu de "oui (Gm)")
Auquel cas, je retouve mes soucis de link (plus d'autres).

Dans ce cas, question bête : pourquoi le fais-tu ???

Quelle est la(les) lib(s) qui me manque(nt) ? Où est(sont)-elle(s) sur le PC ?

Vu les préfixes, elles sont dans les runtimes de Visual (double underscore en début d'identifiant).

Je ne comprends pas ce qu'il se passe car je n'ai pas les symboles en question dans mon code: c'est donc Visual qui les y ajoute à la création de la librairie... Cela a pour conséquence la création d'une librairie non exportable. Il doit bien y voir un moyen de ne pas ajouter ces choses ?

Visual les a insérés parce que tu as utilisé des fonctions qui les utilisent... Apparemment, la cause principale est l'utilisation de composants DirectX dans une application console : est-ce ton cas ?

La fonction "ftol2_sse", d'après son nom, utiliserait les registres SSE du processeur pour convertir un nombre à virgule flottante en un entier long.
La fonction "chkstk", elle, est destinée à la vérification de la pile lorsque tu as plus de 4 ko de variables locales sur la pile.

Dans les deux cas, si tu ne linkes pas la bonne librairie runtime (et en général, il vaut mieux laisser le compilateur tranquille à ce sujet), tu n'auras pas ces fonctions.

[peter3000]

Dans ce cas, question bête : pourquoi le fais-tu ???.

Je dois livrer à quelqu'un des .lib qui seront utilisées en dehors de l'environnement Visual (dans Matlab pour être précis, et l'utilisateur n'a pas visual). J'utilise Visual pour faire ces .lib et les tester (mais dès que je quitte Visual, pb de link).

Visual les a insérés parce que tu as utilisé des fonctions qui les utilisent... Apparemment, la cause principale est l'utilisation de composants DirectX dans une application console : est-ce ton cas ?

Je n'en sais rien du tout Je ne suis pas trop spécialiste. Ce que je sais c'est que je fais des librairies statiques .lib - et j'imagine que c'est dans une application console car je crée un main (dans un autre projet) qui tient lieux d'éxécutable (et il fait appel aux fichierc C dont j'ai fait des .lib). Je teste tout ça avec le débug de Visual C++ Express.

Dans les deux cas, si tu ne linkes pas la bonne librairie runtime (et en général, il vaut mieux laisser le compilateur tranquille à ce sujet), tu n'auras pas ces fonctions.

N'est-il pas possible que le compilateur Visual me crée la lib qui contienne mon code ET ses besoins (au lieu de créer dans la lib des symboles qui viennent d'ailleurs, il pourrait aussi y inclure leur définition) ?

Je me sens un peu largué, mais je vois ici et là que bcp ont ce pb (même si je ne vois pas la solution). Je peux faire moi même un link en plus, mais il faudrait connaître les bonnes librairies... et leur emplacement...

[Mac LAK]

Je dois livrer à quelqu'un des .lib qui seront utilisées en dehors de l'environnement Visual (dans Matlab pour être précis, et l'utilisateur n'a pas visual). J'utilise Visual pour faire ces .lib et les tester (mais dès que je quitte Visual, pb de link).

Des .LIB ?? Étonnant... Ce sont plutôt des DLL que l'on file aux autres programmes, habituellement...

Je teste tout ça avec le débug de Visual C++ Express.

Normalement, c'est une application console, tu n'as pas accès aux MFC (et donc aux applications graphiques) via la version Express.

N'est-il pas possible que le compilateur Visual me crée la lib qui contienne mon code ET ses besoins (au lieu de créer dans la lib des symboles qui viennent d'ailleurs, il pourrait aussi y inclure leur définition) ?

Justement, non : un .LIB ne contient QUE le code correspondant aux sources compilés et mis dedans, et absolument AUCUN code additionnel provenant d'une quelconque dépendance... Ce qui t'oblige parfois à linker des librairies additionnelles quand tu utilises une librairie statique, même si apparemment elles n'ont aucun rapport avec le schmilblik...

Je me sens un peu largué, mais je vois ici et là que bcp ont ce pb (même si je ne vois pas la solution). Je peux faire moi même un link en plus, mais il faudrait connaître les bonnes librairies... et leur emplacement...

Ton .LIB ne sera pas autonome pour autant, et ne le sera jamais. Ce ne sera possible que si tu fais une DLL (éventuellement avec un .LIB d'importation, certes).

[peter3000]

Si je comprends bien:

1) La décoration des fonctions n'étant pas standard, il n'est pas possible d'utiliser des libs d'un compilateur pour un autre en général.

Il semble donc que le fait de faire des .lib avec Visual C++ Express ne soit pas compatible d'une utilisation de ces .lib avec un autre compilateur (lcc par exemple, sous Matlab).

Pour info, j'ai compilé mes fichiers .c avec gcc et sous Matlab le lien non résolu que j'ai c'est "__alloca" (ou un truc dans le genre).

Si quelqu'un sait comment on fait des .lib ou des . a avec lcc ça peut aider.

2)

Justement, non : un .LIB ne contient QUE le code correspondant aux sources compilés et mis dedans, et absolument AUCUN code additionnel provenant d'une quelconque dépendance... Ce qui t'oblige parfois à linker des librairies additionnelles quand tu utilises une librairie statique, même si apparemment elles n'ont aucun rapport avec le schmilblik...

Je me demande si:
a) l'ajout de ces sympoles est évitable, tout comme l'est l'ajout des symboles __RTC_Shutdown, __RTC_InitBase qui sont là si on utilise la Runtime "/RTC1, equiv. to /RTCsu et qui ne le sont pas si on utilise la Runtime "Default" (cf 1ère réponse). Bref, il y a des cas où on peut éviter l'ajout de symboles inutiles à la création de la libraire via la configuration des propriétés du projet. Mais là je sèche un peu (j'ai essayé de désactiver la vérification de sécurité mémoire tampon - en pensant que ça virerait __chkstk - mais ça n'a rien fait; j'ai essayé d'activé le jeu d'instruction amélioré SSE - pour __ftol2_sse - pas d'impact). Bref, je me dis qu'il doit bien y avoir un moyen d'éviter d'ajouter ces symboles.
b) sinon, je veux bien linker en plus des .lib du compilateur Visual qui contiennent ces définitions. Mais dans quelles .lib sont-elles et où se trouvent-elles sur mon PC ?

3) Un petit HS: sous Matlab, le compilo par défaut est lcc. Il me propose de changer de compilateur (mex -setup) mais ne trouve pas d'autres choix sur mon PC (alors qu'il y a gcc et le compilo Visual). Savez vous comment faire ? Auquel cas, il me suffirait d'utiliser le compilo Visual sous Matlab, qui saurait bien résoudre le pb de link (car sous Visual, le link ce fait bien, "implicitement et à mon insu" au sens où ce qu'il rajoute pour utiliser mon code, il le trouve !).

Merci pour les réponses (passées et j'espère à venir).

[peter3000]

Je viens de lire ça à propos de gcc:

D'ou vient ce _alloca ?
Ce _alloca est incorporé par le compilateur pour effectuer des tests d'allocation mémoire sur l'état de la pile, il est possible de spécifier a gcc de ne pas incorporer ce test avec le mot clef -mno-stack-arg-probe

Bref, je suis convaincu que les compilo ajoutent des trucs pas tjrs utiles !
J'étais très confiant avec l'option /Gs- sous visual pour agir sur me symbole __chkstk, mais rien n'y fait.

[peter3000]

une dernière chose: je fais 4 librairies (.lib) avec Visual C++ Express.
Quand je link ces lib ailleurs que sous Visual (sous Matlab):
- deux n'ont pas de problèmes de link
- une a 2 symboles non résolus: __chkstk et __ftol2_sse
- une à 1 seul symbole non résolu: __chkstk

Ces 4 librairies ont les mêmes options de propriétés au niveau de leur projet Visual qui permet leur création. J'en déduis donc que les ajouts ne sont introduits qu'au besoin ? Je n'y comprends rien... Pourquoi mes 4 librairies n'ont pas TOUTES les mêmes symboles non résolus alors qu'elles utilisent les mêmes options de propriétés des projets ?

[peter3000]

Je ne comprends pas ce qui est dit là (aide check_stack):
ms-help://MS.VSCC.v90/MS.msdnexpress.v90.fr/dv_vclang/html/f18e20cc-9abb-48b7-ad62-8d384875b996.htm

Comment ça s'utilise les pragma ?

Mais je pense que c'est une piste pour virer le __chkstk

[Mac LAK]

1) La décoration des fonctions n'étant pas standard, il n'est pas possible d'utiliser des libs d'un compilateur pour un autre en général.

De façon générale, non, les librairies statiques d'un compilateur ne sont pas utilisables avec un autre compilateur. Toutefois, beaucoup de compilateurs / éditeurs de liens acceptent plusieurs formats, il faut juste s'assurer de ce point.

Il semble donc que le fait de faire des .lib avec Visual C++ Express ne soit pas compatible d'une utilisation de ces .lib avec un autre compilateur (lcc par exemple, sous Matlab).

Non, ce n'est pas ça. Ton problème est simplement situé dans le fait que tu utilises des fonctions qui réclament une librairie runtime supplémentaire. Tu ne peux jamais garantir l'autonomie d'une librairie statique, car elle ne fait pas l'objet d'une édition de liens interne. Seul un exécutable (DLL ou EXE) liant cette librairie statique peut faire l'objet de cette édition de liens.

Pour info, j'ai compilé mes fichiers .c avec gcc et sous Matlab le lien non résolu que j'ai c'est "__alloca" (ou un truc dans le genre).

Là encore, c'est un problème de runtime... Je pense que tu devrais réellement aller voir ce que Matlab demande : une DLL, ou une librairie statique ? Pour ma part, je trouve extrêmement étonnant que ce soit une librairie statique, du moins autre qu'une simple .LIB d'importation de DLL...

Bref, je me dis qu'il doit bien y avoir un moyen d'éviter d'ajouter ces symboles.

Oui, bien entendu : ne pas utiliser les fonctions qui les demandent... Ou produire une DLL.

sinon, je veux bien linker en plus des .lib du compilateur Visual qui contiennent ces définitions. Mais dans quelles .lib sont-elles et où se trouvent-elles sur mon PC ?

C'est ce que je te disais : tu n'as pas à le savoir à priori, car cela concerne l'édition de liens faite par Visual. Normalement, tu n'exportes JAMAIS une librairie statique hors de Visual, mais seulement des DLL.

3) Un petit HS: sous Matlab, le compilo par défaut est lcc. Il me propose de changer de compilateur (mex -setup) mais ne trouve pas d'autres choix sur mon PC (alors qu'il y a gcc et le compilo Visual). Savez vous comment faire ?

Voir sur le forum Matlab, là, je pense...

Bref, je suis convaincu que les compilo ajoutent des trucs pas tjrs utiles !

Ils le sont pourtant, je le répète : c'est exporter une librairie statique qui est "anormal" par rapport à l'usage courant.

une dernière chose: je fais 4 librairies (.lib) avec Visual C++ Express.
Quand je link ces lib ailleurs que sous Visual (sous Matlab):
- deux n'ont pas de problèmes de link
- une a 2 symboles non résolus: __chkstk et __ftol2_sse
- une à 1 seul symbole non résolu: __chkstk

Parce qu'elles n'utilisent pas les mêmes fonctions...

J'en déduis donc que les ajouts ne sont introduits qu'au besoin ?

C'est très exactement ça, surtout si en plus tu as activé l'édition de lien au niveau fonction.

Pourquoi mes 4 librairies n'ont pas TOUTES les mêmes symboles non résolus alors qu'elles utilisent les mêmes options de propriétés des projets ?

Elles n'utilisent pas le même "code"... Par exemple, celles utilisent "ftol2_sse" utilisent les registres SSE du processeur pour convertir un flottant en entier.
Pour lever cette dépendance, soit tu n'utilises plus les registres SSE du processeur (dommage), soit tu vires cette conversion flottant -> entier.
Pour "chkstk", c'est que certaines fonctions utilisent plus de 4 ko de variables locales sur la pile. Là aussi, baisser la quantité de variables locales résoudra l'erreur.

Mais quoi qu'il arrive, renseignes-toi AVANT pour savoir si ce n'est pas une DLL qu'il faut passer au compilateur MatLab...

Comment ça s'utilise les pragma ?

"#pragma ...." dans le code source, comme les #define ou #include. C'est une directive au niveau du préprocesseur.
Sinon, ton lien est foireux, tu es en train de faire un lien vers ton aide locale (clique dessus, t'as une page en chinois ou japonais qui s'affiche...).