013
26.09.2003, 10:25 Uhr
virtual
Sexiest Bit alive
(Operator)
|
| Zitat: |
RHBaum postete
Aber du bist sicher, dass das, was der gcc da raushaut, ne wirkliche Win32 DLL ist ? , mit export map etc ? So aufn ersten blick sieht es so aus, als wuerd er die dll A. irgendwie statisch behandeln, oder B. ne ganze menge notwendigen COde irgendwie, irgendwo verstecken ....
Kommt man von deinem Beispiel irgendwie an das codefragment ran, wo die LoadLibrary -Winapi Function aufgerufen wird ???
Wo versteckt er die DllMain und DllCanUnloadNow Funktionen ?
Wo gibst du die Versionsinformationen fuer die Dll an ? Gibts da auch sowas wien RessourceFile fuer ? Kannst da ueberhaupt resssourcen reinkompilieren ?
Testweise sollte man mal versuchen, von nem anderen Prog aus, deine erzeugte DLL mit Loadlibrary zu laden ... und mal schauen, was genau er ueberhaupt exportiert ....
Also ich bin echt sehr Skeptisch !!! :-)
|
Nein natürlich erzähle ich die Ganze Zeit Unsinn und es kommt was Statisches raus 
Mit Resourcedateien weiß ich nicht, kann mir aber beim besten Willen keinen Hinderungsgrundvorstellen. Die DllMain, DllConUnloadNow und so weiter Funktionen mußt Du selber schreiben, sind ja nur triviale Eintrittpunkte in die DLL (die halt mit einer gewissen Semantik vordefiniert sind). Sind auch nicht zwingend erforderlich; jedenfalls habe ich hier dutzende DLLs rumfliegen, die das nicht brauchen (es mag Situationen geben, wo man das braucht, ja. Versionsinfos vermutlich dito. Aber dafür arbeite ich zuwenig unter Windows, um da eine komplett fundierte Aussage zu treffen.
Generell - ganz unabh. von der Frage DLL oder Statisch und welches Betriebssystem - ist es so, daß nirgendwo standardisiert ist, wie C++ Symbole in einer DLL, Library usw. genamemangled ( ) werden: im Gegensatz zu C, wo es eine Klare vereinbarung gibt, ist dies bei C++ generell nicht festlegt. Dh. konkret, wenn eine Library, eine Objektdatei oder eben eine DLL mit Compiler A compilierst, dann funktioniert diese nicht zwingend mit Compiler B. Nur das ist eben ein generelles Problem mit C++, weil das C++ Linkage nicht standardisiert ist. Dies ist auch der Grund, weshalb man - grade wenn die DLLs von einem Kunden benutzt werden - lieber mit C Linkage arbeitet (und daher auf den Export von Klassen verzichtet).
Insofern sind Deine Zweifel berechtigt.
Ich nehme einfach mal an, daß Intel, Borland, und VC sich da an den VC "Standard" halten und gleichen Namemangling fabrizieren. Der gcc benutzt definitiv ein anderes - Du kannst auch Unter AIX, HP, und wie die ganzen UNIXe alle heißen, keine g++ libraries/objekte gegen dinge Linken, die mit dem jeweiligen nativen C++ Compiler gebaut werden
Allerdings hat das wieder nichts mit ImportLibraries zu tun, weil diese ImportLibraries dich nicht von diesem Übel befreien: Da stehen die Namen genauso genamemangled drin, wie in der DLL.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21) |
