Manglende forståelse af linkage: Dynamisk vs. statisk

Hvis du linker statisk, betyder det at funktionerne linkes(copieres) ind i din exe fil, og dermed bliver en del af dit program.  (Stortset paa linie med de funktioner du selv har skrevet).
En statisk linket exe fil, vil saaledes aldrig referer til statiske library naar den koere.

Med dynamisk linking, vil exe filen, naar den koere kalde funktionerne(kode) der ligger i det dynamiske library. Dette medfoere saa at hvis man opdatere/aendre det dynamiske linkede library(I dette tilfaelde din dll fil), vil exe filen kalde de nye funktioner, og at det dynamiske library, skal findes for at programmet virker.

Hej Tiller,

jeg er sikker på du har ret, men det er noget lidt andet jeg spørger om. Jeg må hellere prøve at forklare lidt bedre og jeg beklager jeg ikke fik det formuleret rigtigt først.
Måske skal jeg splitte detop i delspørgsmål:

1. En funktion (for exemplets skyld: strcmpi) findes både i crtdll. dll og i den statiske libcrtdll.a  . Hvis jeg vælger at inkludere libcrt.dll til linkeren betyder det så at den bruger strcmpi fra det statiske bibliotek i stedet for det i crtdll.dll?

2. En funktion (for exemplets skyld: strcmpi) findes både i crtdll. dll og i den statiske libcrtdll.a  . Hvis jeg vælger at inkludere libcrt.dll til linkeren, kan jeg så tvinge compåileren til at sørge for at exe-filen bruger crtdll.dll for netop denne funktion selvom den findes i mit lib som der linkes til?

Tusind tak og endnu en gang beklager jeg for manglende evne til at forklare mig.

Y.

.... og i tilgift lige følgende, der tyjener til opklaring:

3. Når compileren støder på en headerfil der specificerer en funktion X, vil den så først lede efter X blandt de biblioteker som linkes til, og hvis den ikke findes der, så udstede instruks om at importere den fra crtdll.dll ved runtime??

Y.

Jeg er lidt forvirret.

Mig bekendt linker du aldrig direkte mod en .dll.

Du kan linke mod en fuld .a og faa hele funktionaliteten inkluderet i din .exe
eller du kan linke mod en .a som indeholder en stub der bruger .dll via
LoadLibrary og GetProcAddress.

Og du bestemmer hvilken ved at angive hvilket library du linker mod.

Hej Arne,

tak for din kommentar.
Jeg prøver lige at omformulere mig igen.
I string.h finder vi følgende functionsproto:
_CRTIMP int __cdecl    strcmpi (const char*, const char*);

...og i _mingw.h følgende:

#ifndef __GNUC__
# ifndef __MINGW_IMPORT
#  define __MINGW_IMPORT  __declspec(dllimport)
# endif
# ifndef _CRTIMP
#  define _CRTIMP  __declspec(dllimport)
# endif
# define __DECLSPEC_SUPPORTED
# define __attribute__(x) /* nothing */
#else /* __GNUC__ */
# ifdef __declspec
#  ifndef __MINGW_IMPORT
  /* Note the extern. This is needed to work around GCC's
      limitations in handling dllimport attribute.  */
#  define __MINGW_IMPORT  extern __attribute__ ((dllimport))
#  endif
#  ifndef _CRTIMP
#  ifdef __USE_CRTIMP
#    define _CRTIMP  __attribute__ ((dllimport))
#  else 
#    define _CRTIMP
#  endif
#  endif
(med mere).

Hvad er det disse linjer specificerer  omkring _CRTIMP??

Lad os sige jeg gerne vil bruge strcmpi fra crtdll.dll men *samtidig* vil jeg også gerne bruge strcat fra libcrtdll.a. Strcat findes også i drtdll.dll og strcmpi findes også i libcrtdll.a og det er her jeg gerne vil forstå hvorledes compilation og linkage fungerer.

Hvis jeg linker til libcrtdll.a betyder det så at så vil det altid blive strcmpi fra libcrtdll.a der anvendes og ikke fra crtddl.dll som jeg ønskede? Jeg ved det lyder hypotetisk og uklart hvorfor jeg skulle ville ønske at gøre sådan, men jeg vil gerne
forstå hvad der sker.

Y.

Som jeg forstår det, så:
  - linker du altid med libcrtdll.a
  - koden i libcrtdll.dll bruger crtdll.dll