CLR und Static MFC

[Thomas Freudenreich]

Ist es tats�chlich nicht m�glich ein VC-Programm mit /clr und statisch
gelinkter MFC zu erstellen?
Thomas

[Jochen Kalmbach [MVP]]

Hallo Thomas!

> Ist es tats�chlich nicht m�glich ein VC-Programm mit /clr und statisch
> gelinkter MFC zu erstellen?

Ja, leider...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Jochen Kalmbach [MVP]]

>> Ist es tats�chlich nicht m�glich ein VC-Programm mit /clr und statisch
>> gelinkter MFC zu erstellen?
>
> Ja, leider...

Der Hintergrund ist vermutlich die "Loader-Lock-Problematik". Dies kann
durch DLLs umgangen werden.

Die letzte Version, die noch statisch linken konnte war VS2003 (und
somit .NET 1.1).

Ab .NET 2.0 (VS2005) kann man nur noch gegen die DLL-Version der CRT linken.

[Thomas Freudenreich]

Am Thu, 15 Oct 2009 07:41:48 +0200 schrieb Jochen Kalmbach [MVP]:

>>> Ist es tats�chlich nicht m�glich ein VC-Programm mit /clr und statisch
>>> gelinkter MFC zu erstellen?
>>
>> Ja, leider...
>
> Der Hintergrund ist vermutlich die "Loader-Lock-Problematik". Dies kann
> durch DLLs umgangen werden.
>
> Die letzte Version, die noch statisch linken konnte war VS2003 (und
> somit .NET 1.1).
>
> Ab .NET 2.0 (VS2005) kann man nur noch gegen die DLL-Version der CRT linken.

Danke Jochen. Schade ich habe ein Projekt auf dem Tisch da k�nnte ich etwas
aus .net gut gebrauchen, aber ich muss auch eine lib verwenden die statisch
gegen MFC gelinkt ist. Wenn ich mein Projekt jetzt die MFC dynamisch linke
bekomme ich zu Hauf: libcmtd.lib error LNK2005: xxx ist bereits definiert
Das kann man ja noch mit /FORCE:MULTIPLE umgehen aber am Ende meint er
LNK2019 nicht aufgel�stes Symbol _main in Funktion __tmainCRTStartup.
Ich denke da habe ich keine Chance. Oder ?
Thomas

[Martin Richter [MVP]]

Hallo Thomas!

> Danke Jochen. Schade ich habe ein Projekt auf dem Tisch da k�nnte ich etwas
> aus .net gut gebrauchen, aber ich muss auch eine lib verwenden die statisch
> gegen MFC gelinkt ist. Wenn ich mein Projekt jetzt die MFC dynamisch linke
> bekomme ich zu Hauf: libcmtd.lib error LNK2005: xxx ist bereits definiert
> Das kann man ja noch mit /FORCE:MULTIPLE umgehen aber am Ende meint er
> LNK2019 nicht aufgel�stes Symbol _main in Funktion __tmainCRTStartup.
> Ich denke da habe ich keine Chance. Oder ?

Doch Du hast eine Chance!
Dieser Linker Fehler tritt auf, wenn Du Libs hast, die evtl. nicht die
selben Compiler Einstellungen f�r die CRT benutzen.
FORCE/MULTIPLE ist das schlechteste Mittel der Wahl.

Benutze die Linker Option /VERBOSE um das Modul zu finden, das andere
CRT Einstellungen hat.

--
Martin Richter [MVP] WWJD http://blog.m-ri.de
"A well-written program is its own heaven; a poorly written
program is its own hell!" The Tao of Programming
FAQ: http://www.mpdvc.de Samples: http://www.codeproject.com

[Jochen Kalmbach [MVP]]

Hallo Martin!

>> Danke Jochen. Schade ich habe ein Projekt auf dem Tisch da k�nnte ich
>> etwas
>> aus .net gut gebrauchen, aber ich muss auch eine lib verwenden die
>> statisch
>> gegen MFC gelinkt ist. Wenn ich mein Projekt jetzt die MFC dynamisch
>> linke
>> bekomme ich zu Hauf: libcmtd.lib error LNK2005: xxx ist bereits definiert
>> Das kann man ja noch mit /FORCE:MULTIPLE umgehen aber am Ende meint er
>> LNK2019 nicht aufgel�stes Symbol _main in Funktion __tmainCRTStartup.
>> Ich denke da habe ich keine Chance. Oder ?
>
> Doch Du hast eine Chance!
> Dieser Linker Fehler tritt auf, wenn Du Libs hast, die evtl. nicht die
> selben Compiler Einstellungen f�r die CRT benutzen.
> FORCE/MULTIPLE ist das schlechteste Mittel der Wahl.
>
> Benutze die Linker Option /VERBOSE um das Modul zu finden, das andere
> CRT Einstellungen hat.

Thomas weiss doch schon, welche LIB es ist ;) er will die LIB aber
trotzdem verwenden ;)

[Thomas Freudenreich]

Am Thu, 15 Oct 2009 10:43:03 +0200 schrieb Martin Richter [MVP]:

> Hallo Thomas!
>
>
>> Danke Jochen. Schade ich habe ein Projekt auf dem Tisch da k�nnte ich etwas
>> aus .net gut gebrauchen, aber ich muss auch eine lib verwenden die statisch
>> gegen MFC gelinkt ist. Wenn ich mein Projekt jetzt die MFC dynamisch linke
>> bekomme ich zu Hauf: libcmtd.lib error LNK2005: xxx ist bereits definiert
>> Das kann man ja noch mit /FORCE:MULTIPLE umgehen aber am Ende meint er
>> LNK2019 nicht aufgel�stes Symbol _main in Funktion __tmainCRTStartup.
>> Ich denke da habe ich keine Chance. Oder ?
>
> Doch Du hast eine Chance!
> Dieser Linker Fehler tritt auf, wenn Du Libs hast, die evtl. nicht die
> selben Compiler Einstellungen f�r die CRT benutzen.
> FORCE/MULTIPLE ist das schlechteste Mittel der Wahl.
>
> Benutze die Linker Option /VERBOSE um das Modul zu finden, das andere
> CRT Einstellungen hat.

Hallo Martin
EIgentlich hast Du recht (/FORCE..). Aber in diesem Fall wei� ich das die
LIB GisFunc.lib statisch gegen genau diesselbe MFC/CRT gelinkt ist gegen
die ich jetzt dynamisch linken will/muss. D.h. z.B. wenn immer er ein
Verweis auf die Funktion _malloc sucht verwendet er die die er zuerst
findet aber die m�sste sich absolut identisch verhalten. Deshalb denke ich
das hier ruhig FORCEMULTIPLE verwenden kann. Nur den Fehler
libcmtd.lib(crt0.obj) : error LNK2019: Verweis auf nicht aufgel�stes
externes Symbol "_main" in Funktion "___tmainCRTStartup".
verstehe ich nicht so recht. Er m�sste doch eher melden das er mehrere
_main findet ?

Wie Jochen richtig anmerkt ist mir die LIB bekannt. Die und ihren
Programmierer kenne ich. Die Quellen bekomme ich aber nicht. Er meinte auch
das er diese statisch gegen MFC linken muss weil er wiederum ANSI-C Libs
benutzt und das nicht anders ginge.
Wenn ich keine Funktionen aus der LIB benutze l�sst sich das Programm auch
einwandfrei mit /Clr �bersetzen.
Thomas

[Martin Richter [MVP]]

Hallo Thomas!

> EIgentlich hast Du recht (/FORCE..). Aber in diesem Fall wei� ich das die
> LIB GisFunc.lib statisch gegen genau diesselbe MFC/CRT gelinkt ist gegen
> die ich jetzt dynamisch linken will/muss. D.h. z.B. wenn immer er ein
> Verweis auf die Funktion _malloc sucht verwendet er die die er zuerst
> findet aber die m�sste sich absolut identisch verhalten. Deshalb denke ich
> das hier ruhig FORCEMULTIPLE verwenden kann. Nur den Fehler
> libcmtd.lib(crt0.obj) : error LNK2019: Verweis auf nicht aufgel�stes
> externes Symbol "_main" in Funktion "___tmainCRTStartup".
> verstehe ich nicht so recht. Er m�sste doch eher melden das er mehrere
> _main findet ?

1. Kannst Du nicht sicher sein, dass er einmal statischen Code einbindet
und ein andermal einen DLL Link verwendet.
Du m�sstest garantieren, dass eben die statische CRT nicht verwendet wird.
2. _main m�sste in Deinem Code liegen! Das Problem ist, dass hier
dennoch ein St�ck statische Code eingebunden wird, der dann den Startup
Code in der DLL zieht. _main ist dann der eigenliche Einsprungpunkt
Deiner EXE, wie Dir klar sein d�rfte.

> Wie Jochen richtig anmerkt ist mir die LIB bekannt. Die und ihren
> Programmierer kenne ich. Die Quellen bekomme ich aber nicht. Er meinte auch
> das er diese statisch gegen MFC linken muss weil er wiederum ANSI-C Libs
> benutzt und das nicht anders ginge.

Quark!

> Wenn ich keine Funktionen aus der LIB benutze l�sst sich das Programm auch
> einwandfrei mit /Clr �bersetzen.

Dan mach es doch anders. Bau eine kleine DLL die die CRT dynamisch
benutzt. In der verwendest Du nun C++/CLI.
Die EXE selbst verwendet eben was auch immer.

[Thomas Freudenreich]

>
>> Wenn ich keine Funktionen aus der LIB benutze l�sst sich das Programm auch
>> einwandfrei mit /Clr �bersetzen.
>
> Dan mach es doch anders. Bau eine kleine DLL die die CRT dynamisch
> benutzt. In der verwendest Du nun C++/CLI.
> Die EXE selbst verwendet eben was auch immer.

Jo schon fertig,d.h. das aktuelle Problem ist gel�st. Allerdings hatte ich
gedacht mal irgendwann den GUI Teil einige Programme auf C++/CLI
umzuschreiben und die Arbeit unter der Haube von den Libs (groesstenteils
selbstgeschrieben aber einiges eben auch gekauft oder Opensource) machen zu
lassen. Aber das geht ja dann nur wenn die LIB's auch dynamisch gegen MFC
linke. Richtig? Ich probiere das morgen gleichmal mit nen paar eigenen aus.
Darunter ist auch eine zLib in der ich alle m�glichen
Komprimierungsroutinen zusammengefasst habe auch OpenSource-Source, da
werde ich mal sehen ob ich unserem GIS-LIB Programmierer nicht etwas unter
die Arme greifen kann wenn er meint das geht nicht.

Danke erstmal auch an Jochen
Thomas

[Martin Richter [MVP]]

Hallo Thomas!

> Jo schon fertig,d.h. das aktuelle Problem ist gel�st. Allerdings hatte ich
> gedacht mal irgendwann den GUI Teil einige Programme auf C++/CLI
> umzuschreiben und die Arbeit unter der Haube von den Libs (groesstenteils
> selbstgeschrieben aber einiges eben auch gekauft oder Opensource) machen zu
> lassen. Aber das geht ja dann nur wenn die LIB's auch dynamisch gegen MFC
> linke. Richtig? Ich probiere das morgen gleichmal mit nen paar eigenen aus.
> Darunter ist auch eine zLib in der ich alle m�glichen
> Komprimierungsroutinen zusammengefasst habe auch OpenSource-Source, da
> werde ich mal sehen ob ich unserem GIS-LIB Programmierer nicht etwas unter
> die Arme greifen kann wenn er meint das geht nicht.

ZLib ist da gar kein Problem. Ich linke die ZLib statisch aber dennoch
gegen die CRT als DLL Version.

Normalerweise machen solche Umstellungen keine Probleme.
Ich verwende aus Prinzip nur noch die DLL Versionen der CRT und MFC in
den gro��n Projekten.
Nur Tools, die abgeschlossen aus einer EXE/DLL bestehen werden statisch
gelinkt.