Discussion :

[knives07]

Bonjour,

Je suis début avec visual studio (2010) et j'ai besoin de générer une librairie en version debug (live555) avec nmake. Après beaucoup de recherche je ne trouve pas comment générer cela. (option de nmake / makefile / ...)

La compilation de mon projet en mode debug me génère l'erreur suivante

error LNK2038: discordance détectée pour '_ITERATOR_DEBUG_LEVEL'*: la valeur '0' ne correspond pas à la valeur '2' in imageprocess.obj

qui est sur le fichier "libgroupsock.lib" de la librairie live555 après quelque recherche j'ai compris que cela venais du type de librairie utilisé (debug/release)

Ou y a t'il une autre solution pour pouvoir "forcer" la compilation avec cette librairie en release ?

J'ai pas de souci pour la faire en release mais pour développer c'est pas la joie.

Merci d'avance

Knives

[bacelar]

Vous ne pouvez pas (ou très très difficilement) mélanger du code binaire (lib, obj) qui utilisent des C-Runtime différentes, et, pas de bol, en Release et en Debug, c'est des C-Runtime différentes.

Donc, si vous voulez compiler live555.lib (ou mieux live555d.lib) en Debug, il faut que vous donniez au linker, que des lib en version Debug.

Vous n'indiquez pas sur quel type de projet l'erreur se produit, voici une personne qui avez une discordance entre les options de génération de ça lib et de son exécutable :
http://georgik.sinusgear.com/2011/10...match-value-2/

Dans ce cas, la correction est simple.

nmake pour un butant sous VS2010, c'est pas super logique.

Pourquoi n'utilisez vous pas l'IDE, ou MSBUILD à la rigueur, pour vos projets, plutôt que nmake ?

[knives07]

Vous ne pouvez pas (ou très très difficilement) mélanger du code binaire (lib, obj) qui utilisent des C-Runtime différentes, et, pas de bol, en Release et en Debug, c'est des C-Runtime différentes.

Justement c'est la où ma compilation bloque en mode débug (je n'ai pas de version débug de la lib)

Donc, si vous voulez compiler live555.lib (ou mieux live555d.lib) en Debug, il faut que vous donniez au linker, que des lib en version Debug.

C'est justement ce que je cherche à faire je me suis lancé dans un autre type de compilation avec mingw (retour au classique )

Vous n'indiquez pas sur quel type de projet l'erreur se produit, voici une personne qui avez une discordance entre les options de génération de ça lib et de son exécutable :
http://georgik.sinusgear.com/2011/10...match-value-2/

Dans ce cas, la correction est simple.

Chercher mais pas trouvé comment mettre cette option /MD si je l'ajoute dans propriété projet -> éditeur de liens -> ligne de commande rien ne change

nmake pour un butant sous VS2010, c'est pas super logique.

c'est pas faux

Pourquoi n'utilisez vous pas l'IDE, ou MSBUILD à la rigueur, pour vos projets, plutôt que nmake ?

Les makefile générés ne peuvent pas être ouvert par l'ide je suis condamné à nmake mais la je vais tester d'autre route cygwin/mingw pour me générer d'autre type de librairie

Sinon question c / c++ sont des C-Runtime différent ?

Merci pour les pistes et l'aide

ps : c'est mon premier projet avec VS2010 en c++

Knives

[bacelar]

Justement c'est la où ma compilation bloque en mode débug (je n'ai pas de version débug de la lib)

Il faut que vous maitrisiez les dépendances sur toute la chaine logicielle, vous devez savoir quel version de lib va avec telle autres. Et vous devez avoir toutes les versions nécessaires. C'est l'un des rares avantages des makefiles fait à la main, c'est de prendre conscience de toutes ces dépendances.

Chercher mais pas trouvé comment mettre cette option /MD si je l'ajoute dans propriété projet -> éditeur de liens -> ligne de commande rien ne change

L'intégration de nmake dans VS c'est light (et là, je suis super genti).
En gros, nmake n'utilise quasiment que ce qui est dans les makefile.
Il faut donc modifier le makefile ou la ligne du makefile qui spécifie les options du linker.

Les makefile générés ne peuvent pas être ouvert par l'ide je suis condamné à nmake mais la je vais tester d'autre route cygwin/mingw pour me générer d'autre type de librairie

Si vous avez une bonne maitrise des outils de génération des makefiles, vous devriez pouvoir facilement les convertir pour générer des "makefile" MSBUILD.

Sans être identique aux makefiles, les fichiers MSBUILD sont conceptuellement assez proches. En plus MSBUILD permet des trucs bien plus sympas que les makefiles.

Sinon question c / c++ sont des C-Runtime différent ?

Oui et non.

Elles sont dans des Dll différentes, mais chaque C++-Runtime utilise une C-Runtime, donc vous ne pouvez pas utiliser une C++-Runtime sans utiliser la C-Runtime associée.

De plus, il n'a quasiment rien dans une C++-Runtime et ne wrappe pas les fonctionnalités de la C-Runtime, le compilateur liera systèmatique une C-Runtime à un module binaire.

Exemple, "new", c'est du C++, mais l'implémentation du new est "codé" dans le compilateur, celle-ci utilisera le malloc de la C-Runtime.
Résultat : il n'y aura aucun lien avec une C++-Runtime mais juste avec une C-Runtime.

En résumé, une C++-Runtime, c'est presque rien et c'est très peu utilisée, même en C++.

[knives07]

C'est tout bon j'ai trouvé
il fallait trouver la ligne a commenté dans les makefiles pour que nmake génère de débug ensuite il fallait aussi savoir que le /MD c'est au niveau de la compilation et non du linkage ... ainsi que le /EHsc

sinon pour info la version des librairies généré avec mingw ne fonctionne pas facilement à cause des différentes règles de compilation (nommage etc...) comme j'ai compris c'est configurable mais j'ai pas chercher comment faire

Sinon question c / c++ sont des C-Runtime différent ?

Oui et non.

Elles sont dans des Dll différentes, mais chaque C++-Runtime utilise une C-Runtime, donc vous ne pouvez pas utiliser une C++-Runtime sans utiliser la C-Runtime associée.

De plus, il n'a quasiment rien dans une C++-Runtime et ne wrappe pas les fonctionnalités de la C-Runtime, le compilateur liera systèmatique une C-Runtime à un module binaire.

Exemple, "new", c'est du C++, mais l'implémentation du new est "codé" dans le compilateur, celle-ci utilisera le malloc de la C-Runtime.
Résultat : il n'y aura aucun lien avec une C++-Runtime mais juste avec une C-Runtime.

En résumé, une C++-Runtime, c'est presque rien et c'est très peu utilisée, même en C++.

Mouai pas convaincu... en gros une dll c'est un code binaire je suis d'accord et que ce soit du c, c++, java c'est quasiment la même exécution niveau cpu

Je demandais plutôt C-Runtime au niveau "version" parce qu'il y a plusieurs compilateurs gcc, g++ etc qui sont pour c ou c++ et on peut voir des warnings dans le genre "utilisation d'une fonction c dans un programme c++" qui peuvent suivant la configuration générer des erreurs de compilation.

Merci pour l'aide

Knives

[bacelar]

Mouai pas convaincu...

Pas convaincu de quoi ?
Je ne fais qu'exposer des faits.

en gros une dll c'est un code binaire je suis d'accord et que ce soit du c, c++, java c'est quasiment la même exécution niveau cpu

Le C-Runtime, c'est une librairie ou une bibliothèque qui implémente des fonctionnalités de base comme malloc et free avec l'aide des primitives systèmes Win32 (VirtualAlloc, ...).

Le code d'une Dll peut ne pas utiliser ces fonctionnalités mais cela reduit beaucoup ses possibilités ou il y aura beaucoup de code à ajouter. L'API Win32 ne permet d'allouer que des page de 4Ko, alors essayez dimaginé l'implémentation des containers STL sans malloc mais seulement avec VirtualAlloc.

L'API du système Windows c'est Win32 et c'est une API C, qui respecte les conventions C. La C-Runtime a donc un statu très particulier dans le développement sous Windows.

Il ya des millier de manière d'implémenté une paire de fonction malloc/delete, et quand on mélenge des C-Runtime c'est avoir la possibilité d'avoir le code d'une fonction delete qui essayé de détruire les structures en mémoires mise en place par un malloc totalement inconnu. Probabilité de gros plantage 99,99999% (en étant optimiste).

Je demandais plutôt C-Runtime au niveau "version" parce qu'il y a plusieurs compilateurs gcc, g++

Les C-Runtime ne sont pas liés à un compilateur, comme une Dll n'est pas lié au compilateur qui l'a généré ( à moins de faire de grosses conneries).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"utilisation d'une fonction c dans un programme c++"

C'est quoi une fonction C dans une Dll ?
Une Dll, c'est un fichier avec des informations pour placer des sections de code binaire dans l'espace d'adressage d'un processus et un ensemble de point d'entrée. Il est un le C là dedans ? ou une fonction ?

C'est quoi un programme C++ ?
Un programme c'est un espace mémoire où des zones de la mémoire ont été remplies avec le contenu du fichier (après modification pour relocation) et un pointeur de programme qui indique l'instruction qui est ou sera en cours d'exécution. Que le contenu du fichier est été généré avec du C du C++, du D ou même du JAVA on sans fout (et la C-Runtime est utilisé dans tous les cas, interpréteur JAVA compris).

[knives07]

Okay y a eu une confusion j'ai pris le mot C-Runtime pour le regroupement de toutes librairies (librairie de base, personnel, distribué, etc ...)

Alors qu'elle représente uniquement les fonctions "native" de l'os en gros c'est LA librairie qui fais tout fonctionner

[bacelar]

On va être plus précis :

L'OS est composé de 2 grandes parties :
- La partie qui tourne en mode Kernel ; ordonnanceur, drivers, mappeur mémoire, chargeur de processus etc...
- La partie qui tourne en mode User qui est composé de Dll qui implémente des fonctionnalités de plus haut niveau.

Le dialogue entre la partie Kernel et User se fait par des interruptions logicielles (gates) (int 2E, un peu comme les int21 du DOS) qui permettent de changer le mode de fonctionnement du CPU (les Ring 0 et Ring 3 des architectures Intel et compatible). En mode Kernel, il n'y a pas de mémoire virtuelle, pas d'espace d'adressage par processus, c'est un peu comme sous DOS, la foire d'empoigne. Le Kernel utilise l'instruction "iret" (retour d'interruption pour revenir en mode User (ring 3).

Ainsi le Kernel ne peut pas être déstabilisé accidentellement par du code "User".

Ces appels via interruption et du code d'assez pas niveau est regroupé dans des dll dites NTAPI. Ces points d'entré ne sont pas l"API officiel de Windows.

Windows a la notion de sous-système :
- le sous-système POSIX, pour le cahier des charges des militaires US
- le sous-système OS2, pour OS2 mais là, c'est de mémoire, et cela fait peut-être 15 ans que M$ ne le supporte plus.
- le sous-système Win32, qui est le plus utilisé des sous-systèmes (et quasi le seul en faits).

Je parle des sous-systèmes car chaque sous-système est composé d'un ensemble de Dll distinctes comme user32.dll ou gdi.dll ou kernel32.dll etc. pour Win32.

Chaque ensemble de Dll (sous-système) est donc indépendant, publie des API compatibles C (convention de nommage et d'appel), mais est langage et runtime agnostique.
Vous n'avez pas de malloc dans aucune de ces Dll. Si vous avez besoin d'allouer de la mémoire pour utiliser ces fonctions, vous passer par d'autre fonctions dédié comme "GlobalAlloc".

Dans tout ça, elle est où l'implémentation de malloc nécessaire à tous les compilateurs C ou C++ ?
Dans aucune de ces Dll. Microsoft fournissait, pour le moins 6 implémentations différentes de ces fonctions nécessaire pour générer du code à partie du C. Une version Debug threadsafe dans une Dll, une version Release Thread-Safe dans une Dll, une version Debug Thread-Safe dans une librairie statique, une version Release Thread-Safe dans une librairie statique, une version Debug Non Thread-Safe dans une librairie statique et une version Release Non Thread-Safe dans une librairie statique.

Mais ces Dll ne font pas partie de l'OS, vous pouvez d'autres implémentation de ce fonction. C'est une des différences avec Unix ou l'implémentation de malloc etc. fait partie du système.