mingw-gcc / DLL

"harmi, että tätäkin on gcc:n dokumentaatiosta todella vaikeaa löytää."

Siis miten niin vaikea löytää?

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options

Aivan helposti löytyy.

"Open sourcena et maksa rahaa, mutta maksat turhautumisen ja heikkolaatuisen, puutteellisen ja/tai harhaanjohtavan dokumentoinnin muodossa."

Ei tämä eroa mitenkään Microsoftin dokumentaatiosta:

https://msdn.microsoft.com/en-us/library/19z1t1wy.aspx

Siellä on vastaavalla tavalla linking options.

Yritätkö siis sanoa, että maksamalla Microsoftille lisnssimaksua makaa myös turhautumisesta, heikkolaatuisesta, puutteellisesta ja harhaanjohtavasta dokumentaatiosta?

niin:

gnu gcc:n dokumenteistä pitäisi siis erikseen aktivoida SEKÄ

-shared

että

-static

Veikkaanpa, että microsoftin kääntäjälle riittä yksi optio: tuota DLL exe:n sijasta.

Eli MS kääntää tuskin edes yrittää oletuksena rakentaa sellaista DLL:ää, joka tarvitsee tukun muita DLL:iä toimiakseen.

gcc:ssä taas on oletuksena tuo muiden DLL:ien vaatiminen, ja vain
-static -optiolla tuon hölmön oletuksen saa kumottua.

jotenkin sekava muutenkin tuo gcc:n systeemi.

Kun -shared tarkoittaa tuon käännöksen lopputulosta (eli -shared = DLL, ilman ko. valitsinta exe).

Ja -static taas pitäisi olla oletus, mutta jostain syystä oletuksena onkin lopputulos, joka ei toimi ilman apu-DLL-iä, ja vielä niiden osalta sijoitusta oikeaan hakemistoon ja/tai path -ympäristömuuttujan käpistelyä yms.

Eli siis maksullisissa kääntäjissä yleensä oletukset ovat järkeviä, ei tarvitse etsiä mistä löytyis dokumentaatio , ja maksullisissa dokumentaation vaan on selkeämmin tehty.

Microsoft -hypetystä?

no EI!

esim. Delphissä asia on todella helppo:

jos lähdekoodimoduli alkaa:

program Ohjelma;

niin syntyy Ohjelma.exe

ja jos lähdekoodimoduli alkaa:

library Kirjasto;

niin syntyy Kirjasto.dll

ei tarvitse yhtään kääntäjäoptiota kiraston tuottamiseen !

Ja oletuksena Delphi ei koskaan tee ns. vajaata EXEä tai DLL:ää (siis sellaista, joka tarvitsee apu -DLL:iä toimiakseen).

Toki Delphissäkin saa (esim. Delphi 7) tehtyä normaalia pienikokoisemman EXE:n tai DLL:n, jos erikseen määrittää, että sovellus tai kirjasto tarvitsee myös VCLD70.DLL toimiakseen.

Mutta tuollainen ns. pikku-EXE:n (tai pikku-DLL:n) tuottaminen on Delphissä poikkeustapaus, joka pitää erikseen aktivoida käyttöön jos tuollaisen haluaa. Oletuksena Delphi ei tee moista hälmöilyä.

Olen itsekin käyttänyt tuollaisen pikku-EXE:n tuottamisoptiota Delphillä, mutta siinä oli kyse ihan siitä, että ohjelman tuotantovaiheessa piti toimittaa uusia versioita asiakkaan luona koekäytettäväksi, ja kun 1990 -luvulla oli vielä sähkäpostin lähetyksessä nettiyhteytenä 33600 bps modeemi, niin oli eduksi lähettää pienikokoinen EXE. Toki tähän piti varautua asentamalla ko. koneelle tuo em. VCLD50.DLL (niin, 50 = Delphi 5, 70 =Delphi 7).

Mutta oletuksena on typerää tuottaa tuollaista ns. vajaata EXEä tai vajaata DLL:ää, joka vaatii aputiedostoja toimiakseen.

Oikein tehdyssä kääntäjässä pitäisi aina olla oletus se, että tuotetaan ns. täysi exe tai dll, jos ei käännösvaiheessa toisin määrätä.

Mutta gcc:n maailmaan tuntuu kuuluvan tietynlainen nihilismi, jossa asiat tarkoituksella tehdään vaikeiksi laittamalla oletus niin päin, että apu-DLLiä tarvitaan, kun oletus pitäisi olla se, että niitä ei tarvita.

delphikoodaaja kirjoitti:

niin:

gnu gcc:n dokumenteistä pitäisi siis erikseen aktivoida SEKÄ

-shared

että

-static

Veikkaanpa, että microsoftin kääntäjälle riittä yksi optio: tuota DLL exe:n sijasta.

Eli MS kääntää tuskin edes yrittää oletuksena rakentaa sellaista DLL:ää, joka tarvitsee tukun muita DLL:iä toimiakseen.

gcc:ssä taas on oletuksena tuo muiden DLL:ien vaatiminen, ja vain
-static -optiolla tuon hölmön oletuksen saa kumottua.

jotenkin sekava muutenkin tuo gcc:n systeemi.

Kun -shared tarkoittaa tuon käännöksen lopputulosta (eli -shared = DLL, ilman ko. valitsinta exe).

Ja -static taas pitäisi olla oletus, mutta jostain syystä oletuksena onkin lopputulos, joka ei toimi ilman apu-DLL-iä, ja vielä niiden osalta sijoitusta oikeaan hakemistoon ja/tai path -ympäristömuuttujan käpistelyä yms.

Eli siis maksullisissa kääntäjissä yleensä oletukset ovat järkeviä, ei tarvitse etsiä mistä löytyis dokumentaatio , ja maksullisissa dokumentaation vaan on selkeämmin tehty.

Microsoft -hypetystä?

no EI!

esim. Delphissä asia on todella helppo:

jos lähdekoodimoduli alkaa:

program Ohjelma;

niin syntyy Ohjelma.exe

ja jos lähdekoodimoduli alkaa:

library Kirjasto;

niin syntyy Kirjasto.dll

ei tarvitse yhtään kääntäjäoptiota kiraston tuottamiseen !

Ja oletuksena Delphi ei koskaan tee ns. vajaata EXEä tai DLL:ää (siis sellaista, joka tarvitsee apu -DLL:iä toimiakseen).

Toki Delphissäkin saa (esim. Delphi 7) tehtyä normaalia pienikokoisemman EXE:n tai DLL:n, jos erikseen määrittää, että sovellus tai kirjasto tarvitsee myös VCLD70.DLL toimiakseen.

Mutta tuollainen ns. pikku-EXE:n (tai pikku-DLL:n) tuottaminen on Delphissä poikkeustapaus, joka pitää erikseen aktivoida käyttöön jos tuollaisen haluaa. Oletuksena Delphi ei tee moista hälmöilyä.

Olen itsekin käyttänyt tuollaisen pikku-EXE:n tuottamisoptiota Delphillä, mutta siinä oli kyse ihan siitä, että ohjelman tuotantovaiheessa piti toimittaa uusia versioita asiakkaan luona koekäytettäväksi, ja kun 1990 -luvulla oli vielä sähkäpostin lähetyksessä nettiyhteytenä 33600 bps modeemi, niin oli eduksi lähettää pienikokoinen EXE. Toki tähän piti varautua asentamalla ko. koneelle tuo em. VCLD50.DLL (niin, 50 = Delphi 5, 70 =Delphi 7).

Mutta oletuksena on typerää tuottaa tuollaista ns. vajaata EXEä tai vajaata DLL:ää, joka vaatii aputiedostoja toimiakseen.

Oikein tehdyssä kääntäjässä pitäisi aina olla oletus se, että tuotetaan ns. täysi exe tai dll, jos ei käännösvaiheessa toisin määrätä.

Mutta gcc:n maailmaan tuntuu kuuluvan tietynlainen nihilismi, jossa asiat tarkoituksella tehdään vaikeiksi laittamalla oletus niin päin, että apu-DLLiä tarvitaan, kun oletus pitäisi olla se, että niitä ei tarvita.

Lue lisää

"gnu gcc:n dokumenteistä pitäisi siis erikseen aktivoida SEKÄ

-shared

että

-static"

Niin? Siellä ohjeessahan selvästi lukee mitä ne vivut tekee.

"gcc:ssä taas on oletuksena tuo muiden DLL:ien vaatiminen, ja vain "

Ihan järkevä oletus se on kun:
1. Normaalisti kirjastot ovat käyttöjärjestelmässä valmiina ja koodia jaetaan koko järjestelmän laajuisesti.
2. Samassa paketissa voi olla useita ajettavia ohjelmia jolloin koodia jaetaan näiden ohjelmien kesken.
3. Joidenkin kirjastojen lisensointi voi kieltää staattisen linkkaamisen.

"Ja -static taas pitäisi olla oletus"

Ei tosiaankaan! Sehän tekee bloattia kun dynaamisella linkkauksella käytetään samaa kirjastoa järjestelmän laajuisesti. Sehän ei johdu mitenkään GCC:stä, että Windowsissa ei niitä kirjastoja ole.

"mutta jostain syystä oletuksena onkin lopputulos, joka ei toimi ilman apu-DLL-iä, ja vielä niiden osalta sijoitusta oikeaan hakemistoon ja/tai path -ympäristömuuttujan käpistelyä yms."

Ei tämä ole mikään GCC:n vika vaan Windowsiin liittyvä asia. Windowsissa kun ei ole niitä kirjastoja mitä normaalisti on vakiona ja Windowsissa kansiorakenteessa ei myöskään ole sitä kirjastoille tarkoitettua vakiokansiota mihin ne asennetaan. GCC:ssä kun ei ole rajoitteita käyttöjärjestelmän suhteen.

"esim. Delphissä asia on todella helppo:"

Delphi on IDE, ei kääntäjä. Delphissä ei ole mitään kummallista helppoutta mihinkään muuhun IDE:n nähden.

"Mutta oletuksena on typerää tuottaa tuollaista ns. vajaata EXEä tai vajaata DLL:ää, joka vaatii aputiedostoja toimiakseen."

Se aputiedostojen tarve liittyy Windowsiin mistä puuttuu vaikka se VCLD70.DLL Windows kun perinteisesti ollut sellainen, että siihen asennetaan milloin mitäkin VBRUN, Visual C runtime, DirectX, Java jne. härpäkettä joita päivitetty ja ylläpidetty erikseen ja sitten ne ajettavat sovellukset lisäksi.