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.