windows - mangler zlib.dll

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg bygger en win32 eksekverbar. Kompilatoren er den nyeste version af MinGW. Bibliotekets afhængigheder er GLUT og libpng.


Jeg testede først på en Windows 7-maskine, og måtte få libpng3.dll og freeglut32.dll. Imidlertid måtte jeg (i tillæg) erhverve zlib1.dll på XP.


XP-maskinen var en VM med en frisk installation, så jeg formoder, at en ny win7-maskine også mangler zlib1.


Mit spørgsmål er, hvordan skal jeg finde ud af, hvilke dll'er jeg skal distribuere? Hvordan ved jeg, a priori , hvilke dynamiske biblioteker er nødvendige for at mit program kan køre på et bestemt system? Jeg formoder, at dette er, hvad installationsprogrammer er til ... Jeg gætter på, at hvad installationsprogrammet gør, er at se igennem systemet for at finde ud af, hvilke afhængigheder der er utilfredse, og så giver dem. Så hvis jeg skulle distribuere mit program, kunne jeg kontrollere, om brugerens maskine allerede har zlib1.dll, og jeg vil ikke installere zlib1.dll hvis den allerede findes i systemkatalogen. Men jeg har aldrig fundet en dokument, der sagde til mig specifikt, 'libpng kræver zlib', og indtil da jeg testede eksekverbarheden på en maskine, der manglede zlib, var jeg ikke klar over denne afhængighed. Hvordan kan jeg oprette min afhængighedsliste uden at have en frisk installation af hver version af hvert operativsystem til test af?


En idé jeg har, er at dekompilere den eksekverbare eller gennem en metode undersøge forbindelsesprocessen for at finde alle de biblioteker, der knyttes i forbindelse med runtime. Problemet bliver nu ved at finde ud af, hvilke af disse der allerede skal være der, og hvilke af dem jeg kunne forventes at levere i distributionen.


Rediger: Okay, jeg kiggede, og installationen af ​​libpng, jeg downloadede, gav zlib1.dll inde i sin bin-mappe. Så ikke med det er stort set min skyld. Daniel's svar er under alle omstændigheder endelige.

Bedste reference


Dependendy Walker viser alle depper af dit program. [1]

Andre referencer 1


Det korrekte svar på dette spørgsmål er efter min opfattelse at starte ved kilden snarere end at omdanne løsningen med Dependency Walker, fantastisk og nyttigt værktøj, selvom det utvivlsomt er.


Problemet med Dependency Walker er, at det kun fortæller dig, hvad en bestemt kørsel af programmet kræver på det operativsystem, som du kører det på. Hvis du har dynamiske belastningsafhængigheder i din app, vil du kun vælge dem, hvis du sørgede for at du profilerede appen med Dep. Walker og tvang den gennem disse dynamiske belastninger.


Min foretrukne tilgang til dette problem er at starte med din egen kildekode og analysere og forstå, hvad det afhænger af. Det er ofte let nok til at gøre det, fordi du ved det godt.


Du skal forstå, hvad der er implementeringskravene til din compiler. Du har normalt muligheder for at forbinde statisk og dynamisk til C ++ runtime. Et dynamisk link resulterer tydeligvis i et implementeringsbehov.


Du vil også sandsynligvis linke til 3rd party kode. Et eksempel er Windows-komponenter. Disse har typisk ikke brug for implementering, du kan tage dem som allerede på plads. Nogle gange er det ikke sandt, f.eks. GDI + på Windows 2000.


Nogle gange vil du forbinde statisk med tredjepartskode (igen let), men hvis du linker dynamisk, betyder det et implementeringsbehov.