VS2005 vs VS2008: brauch ich unterschiedliche import-.libs ?

[ponx]

Hallo zusammen !
Ich biete eine Library als .DLL an, die dann über eine statische import .lib reingeladen werden soll. Jetzt frag ich mich, ob ich für verschiedene Visual C++ - Versionen jeweils eine eigene import .lib bauen und im SDK zur Verfügung stellen muss ? Bei boostPro beispielsweise gibt's von den boost-libs ja immer jeweils eigene Versionen für vc8 und vc9. Andererseits bietet z.B. die FMOD Engine nur eine einzelne (import-)lib für alle Visual Studio-Versionen, und es gibt auch immer nur eine gemeinsame .DLL.
Jetzt bin ich verwirrt: Wann brauch ich eigene Versionen der .libs ? Sind statische import-libs für DLLs irgendwie ein Sonderfall ? Ist bei den eigentlichen .DLLs noch was zu beachten ?

Für jede Erklärung wie immer sehr dankbar:
andy / ponx

[Aramis]

Soweit ich weiß, sind die .lib's schon mit mehreren VS-Releases verwendbar. Das Problem ist die ABI-Kompatibilität mit dem in den Libs enthaltenen Code, insbesondere STL und Laufzeitbibliothek. Der muss zum Compiler und auch zum Rest deines Programms passen, sonst kracht es (entweder beim Linken oder bei der Ausführung). Daher sind statische Libs *mit* Objektcode kritisch. Wenn eine .lib nur die von einer DLL exportierten Symbole auflistet, gibt es eigentlich keine Probleme bzw. die Libs sollten zumindest abwärtskompatibel sein.

[Schrompf]

.. und wenn die DLL nur C-Funktionen enthält. Sobald C++ drin ist (überladene Funktionen, Klassenmethoden), könnte das Name Mangeling auch eine Wiederverwendung der Lib verhindern.

[ponx]

vielen Dank euch beiden ! Aramis du meintest, statische Libs mit Objektcode sind kritisch - ich lass diese import libs einfach automatisch generieren (in den Properties unter "Linker->Advance->Import Library"), also ich hoffe mal da wird nichts anderes drinstehen als die DLL-Symbole.
@Schrompf: da steht ausschließlich C++ drin, und ich benutze überladene Methoden :? wenn die jenigen, die meine Library importieren, dann auch alle C++ benutzen, kann es dann trotzdem Probleme geben ? Oder bedeutet das wirklich, dass man bei C++ dann grundsätzlich lieber eigene Versionen für alle Compiler-Versionen anbietet ? Ich hatte gehofft, diese Name Mangeling wäre standardisiert..!