Visual C++ Express 2008 - problème de symboles non résolus: __ftol2_sse et __chkstk

Version imprimable

26/07/2009, 19h02
peter3000

Visual C++ Express 2008 - problème de symboles non résolus: __ftol2_sse et __chkstk

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 !
26/07/2009, 20h37
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 :

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".
26/07/2009, 21h15
peter3000

Merci.

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

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 ?
26/07/2009, 21h39
Mac LAK

Citation:

Envoyé par peter3000

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 ???

Citation:

Envoyé par peter3000

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).

Citation:

Envoyé par peter3000

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.
26/07/2009, 22h03
peter3000

Citation:

Envoyé par Mac LAK

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).

Citation:

Envoyé par Mac LAK

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.

Citation:

Envoyé par Mac LAK

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...
26/07/2009, 22h33
Mac LAK

Citation:

Envoyé par peter3000

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...

Citation:

Envoyé par peter3000

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.

Citation:

Envoyé par peter3000

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...

Citation:

Envoyé par peter3000

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).
27/07/2009, 11h46
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)

Citation:

Envoyé par Mac LAK

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).
27/07/2009, 12h03
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.
27/07/2009, 12h10
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 ?
27/07/2009, 12h14
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
27/07/2009, 14h31
Mac LAK

Citation:

Envoyé par peter3000

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.

Citation:

Envoyé par peter3000

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.

Citation:

Envoyé par peter3000

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...

Citation:

Envoyé par peter3000

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.

Citation:

Envoyé par peter3000

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.

Citation:

Envoyé par peter3000

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...

Citation:

Envoyé par peter3000

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.

Citation:

Envoyé par 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

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

Citation:

Envoyé par peter3000

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.

Citation:

Envoyé par peter3000

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...

Citation:

Envoyé par peter3000

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...).