[gelöst] statisch gegen CRT linken? Warum nicht?

[john]

Hallo Leute,

denke, dass ich hier richtig bin. Meine Frage:

Warum wird eigentlich immer wieder davor gewarnt, Qt gegen die CRT statisch zu linken?

Welche Auswirkung kann das allgemein (nicht nur auf Qt bezogen) haben, wenn man sein Programm gegen die CRT statisch linkt?

Vielen Dank,
LG john

[Christian81]

Das Problem ist nicht das eigentliche Statische linken sondern das mischen von beiden. Ein putenv() wirkt sich dann z.B. nur auf das statische oder dynamische crt aus - je nachdem von wo es aufgerufen wird.

[john]

Hallo Christian81,

hm, also so ganz verstehe ich es noch nicht. Aber danke, es ist zumindest ein Ansatz!

Also, wenn man ein Programm komplett statisch gegen die CRT linkt, dann hat man kein Problem. Aber sobald man fremde Librarys verwendet (DLL'S) könnten Probleme auftreten? Wie zum Beispiel das mit Umgebungsvariablen usw... ?

Habe ich das ungefähr so richtig verstanden?

Vielen Dank!

LG john

[Christian81]

richtig.
libxml2/xslt z.B. lesen infos per getenv() aus. Wenn ich sie in meinem Programm per putenv() setze und dann die xml-Funktionen aufrufe kann es sein dass er die gesetzten Werte nicht sieht da es eine andere CRT ist. Einfach grauenhaft

[john]

herzlichen Dank für die Aufklärung!

[RHBaum]

libxml2/xslt z.B. lesen infos per getenv() aus. Wenn ich sie in meinem Programm per putenv() setze und dann die xml-Funktionen aufrufe kann es sein dass er die gesetzten Werte nicht sieht da es eine andere CRT ist.

Sicher ?

Ich mein was und wo die Prozessumgebung liegt, bestimmt das BS ...
Die Laufzeit Umgebung sollte keinerlei auswirkungen haben, was und wo irgendwas abgelegt wird, oder ob zwischengespeichert oder ned, erst recht ned bei prozessrelevanten dingen ....

woher soll nen fork/system denn wissen, wo die prozessumgebung liegt ?

also wenn sich das unterschiedlich verhaelt, iss was anderes faul oder es ist nen bug.

putenv ist zum beispiel teil der betriebssystem API, in windows der winapi, unter linux isses in posix spezifiziert, das heisst deine runtime wird da gar nix machen, sondern der aufruf geht 1:1 ans "BS" durch ...

Es gibt trotzdem gute gruende das ned zu mixxen ....
wenn man eh dll/so verwendet, warum dann grad die runtime, die eigentlich generischste, ned auch als dll ? und warum die runtime funktionen direkt an das binary pappen, wenn das referenzierte .so die runtime funktionen sich aus der dynamischen runtime holt ? gewonnen hat man dann gar nix ....
Einige Typen sind auch ned kompatibel, je nachdem mit was fuer einer runtime man arbeitet. multithread und nicht multithreaded haben oftmals andere symbole fuer gleiche dinge, was beim compilieren dann aufschlaegt .... besonders wenn man importlibs fuer dlls verwendet.

Ciao ...

[Christian81]

getenv() schreibt in die msvcrt. Da libxml2 msvcrt.dll benutzt und Du z.B. msvcrtd.dll oder msvcrt80.dll dan haste Pech gehabt.
Deswegen kann man auch keinen FILE* - Pointer von einer msvcrt zur anderen mitnehmen.

[RHBaum]

Hab grad noch mal nachgelesen, es ist noch viel schlimmer

man bekommt direkten zugriff auf die environ ... oO
man kann sogar 2 versionen in einem prozess haben, eine Ansi und eine unicode variante, welche nicht zwingend gleich sein muessen .... wuerg.

Kein wunder das jeder lieber alle seine settings in die registry schreibt ....

trotzdem versteh ich das problem mit dem *File pointer noch ned ganz ....

Die libxml2 verwendet irgendwie nen Filepointer, den es in der ENV ablegt ...
und man kann von aussen (also innerhlab des prozesses oder seiner childs) diesen pointer auswerten ???
Iss das ned mega fehlertraechtig ? weisst du wann die lib den eintrag schreibt, und in welchen zustand der filepointer ist ??? Gibts dafuer ned andere wege ? Wird da irgendwie geforkt (createprocess) weswegen die env verwendet wird ?

Ciao ...

[Christian81]

libxml2 verwendet keine FILE* - das ist ein anderes Beispiel.
libxml2 verwendet nur getenv() und das Programm drumrum setzt Vars mit putenv(). libxml2 ist aber gegen msvcrt.dll gelinkt, das drumrum gegen msvcrt80(d).dll

[RHBaum]

ahhh ok.

trotzdem ned wirklich sauber ....
eigentlich verwendet man die env, um daten seinen "childs" zu vererben ...
macht im selben prozess eher weniger sinn das zu verwenden, besonders wenn ich funktionen direkt aufrufen könnte ...

Ciao ...

[Christian81]

Ich kann nichts dafür wie libxml2 die Infos anfordert. Was er da benutzt sind aber auch Linux-Umgebungsvariablen. D.h. sie können auch von extern gesetzt sein und müssen nicht zwangsläufig vom aufrufenden Programm kommen.