zweimal die gleiche Bibliothek?

Hallo,

Ich habe da eine Verständnisfrage:
Was passiert beim linken, wenn zwei verschiedene Versionen einer Bibliothek zur Verfügung stehen?

Zum Hintergrund:
Ich habe ein Projekt, welches ImageMagick und wxWidgets verwendet. Beide implementieren eine JPEG lib. ich habe herausgefunden, dass es die gleiche ist, jedoch ist diejenige von ImageMagick neuer.
Das Projekt linkt ohne Probleme.
Beim konvertieren eines Bildes mittels ImageMagick tritt jedoch ein Fehler auf, der besagt, dass die verwendete JPEG lib nicht die erwartete Versionsnr besitzt. Ich habe im Debugger festgestellt, dass zum Konvertieren des Bildes die JPEG lib von WxWidgets verwendet wird, und nicht die von ImageMagick!!!

Wie kann ich das vermeiden? Hätte es nciht schon ein problem beim linken wg mehrfach definierter symbole geben müssen? Es muss doch einen Weg geben sowohl WxWidgets als auch ImageMagick in einem Projekt zu verwenden, ohne derartige laufzeit fehler zu riskieren!

Falls es hilft:
Ich verwende VC71 zum kompilieren des Projektes.

Vielen Dank für Hilfe

Martin

DocShoe

Eine Bibliothek sollte reichen, am besten die jüngere. Nimm doch einfach mal den Bibliothekspfad für die wxWidgets jpglib aus dem Linker Pfad, dann sollten auch die wxWidgets gegen die neue lib gelinkt werden. Oder du bennenst zu Testzwecken das Verzeichnis der alten jpglib um.

Vielen Dank für den Hinweis. Ich habe den Wx jpg aus dem LinkBibliotheken entfernt und es funktioniert jetzt.

Aber muss ich das jetzt mit allen Bibliotheken machen, die doppelt aufgeführt sind (tiff, png, ...)? Außerdem kann es doch sein, dass Wx seine jpg lib verändert hat und es jetzt in bestimmten fällen zu fehlern kommt. Es muss doch einen Weg geben von vorn herein sicherzustellen, dass die aufrufe von Wx in der Wxjpg lib landen und diejenigen von IM in er IMjpg lib.

Das blöde an der Sache ist nämlich dass sich fehler erst zur laufzeit bemerkbar machen!

grüße Martin

drakon

matlantis schrieb:

Aber muss ich das jetzt mit allen Bibliotheken machen, die doppelt aufgeführt sind (tiff, png, ...)? Außerdem kann es doch sein, dass Wx seine jpg lib verändert hat und es jetzt in bestimmten fällen zu fehlern kommt.

Alles, was in altem Code ging, sollte auch mit neueren Versionen der Lib gehen. Wäre ja schreklich, wenn das nicht so wäre. Abwärtskompatibilität ist imo für eine Lib eines der wichtigsten Punkte. Wäre ja fatal, wenn alle, die die Bibliothek benutzen jedesmal, wenn sie ein Update machen den gesamten Code überarbeiten müssten.

Wenn du aber trotzdem Fehler bekommst (was ich mal nicht hoffe) wegen der neueren Version, kannst du ja einfach mal die alte Bibliothek umbennen und diese dan linken. Das sollte gehen.

hustbaer

drakon schrieb:

Alles, was in altem Code ging, sollte auch mit neueren Versionen der Lib gehen. Wäre ja schreklich, wenn das nicht so wäre. Abwärtskompatibilität ist imo für eine Lib eines der wichtigsten Punkte. Wäre ja fatal, wenn alle, die die Bibliothek benutzen jedesmal, wenn sie ein Update machen den gesamten Code überarbeiten müssten.

Bei vielen C Libs sind neue versionen wirklich "binary compatible" zu alten. Das ist fein.
Ist allerdings bei den wenigsten C++ Libs so. Grund: man verwendet Klassen, und man hat oft private Member in Klassen, die aber in öffentlichen Header-Files stehen. Ändert man etwas am Header-File (z.B. neues Member kommt dazu), dann knallts, wenn man ein Projekt gegen die eine Library compiliert, und dann aber gegen die andere linkt. z.B. alte Header-Files, aber neue .lib.
Die Source-Kompatibilität wird davon nicht beeinflusst. Man muss aber u.u. sein Programm neu compilieren. Und eben sicherstellen, dass alle Programmteile die gleichen Header-Files zum compilieren verwenden, und gegen die selben .lib's linken. (Und natürlich dass diese Headers und das .lib File zusammenpassen).

Zumindest unter Windows gibt es dann natürlich noch eine weitere Möglichkeit, für Libs die nur intern verwendet werden (*): man macht aus den zwei Programmteilen die unterschiedliche Versionen z.B. der libjpeg verwenden einfach DLLs. Oder 1x .exe und 1x .dll.
Die .dll enthält dann die eine Version der libjpeg, und die .exe enthält die andere Version.

*: nur inter verwendet heisst: es dürfen keine Typen der Lib (Structs, Klassen, ...) im Interface des Moduls vorkommen. Nichtmal als "private member".

drakon

Ja, klar. Ein erneutes Kompilieren ist legitim und das kann man Voraussetzen, aber ich habe das so verstanden, dass er Angst hat, dass gewisse Sachen plötzlich anderst funktionieren respektive man andere Resultate bei gleichem Input bekommt. Das sollte definitiv nicht so sein. (Könnte aber hin und wieder vorkommen, wenn die Unit Tests versagen.. )