Monessa C -ohjelmassa on kääntöjärjestelmänä autoconf/automake.
Mutta OpenSSL:ssä tekijöille ei kelvannut tämäkään, vaan piti koodata Perlillä oma kääntöjärjestelmä.
Yksinkertaisia C -ohjelmia voi kääntää näin:
gcc -c paaohjelma.c
gcc -c aliohjelmia.c
Windowsissa:
gcc paaohjelma.o aliohjelmia.o -o paaohjelma.exe
Linuxissa:
gcc paaohjelma.o aliohjelmia.o -o paaohjelma
Miksi esim. OpenSSL:n kääntämistä ei voi(si) tehdä noin, vaan miksi siihen tarvitaan mittava kääntöjärjestelmä ?
JOS OpenSSL:ssä on/tarvitaan osia, jotka riippuvat käyttöjärjestelmästä, miksei olisi voinut tehdä näin
(OSL = lyhenne sanasta OpenSSL)
Tiedoston OSL_riippuvatosat.c sisältö:
#include OSL_os_semi_dependent.h
#ifdef mswindows
OSL_win.c
#endif
#ifdef linux
OSL_linux.c
#endif
#ifdef macos
OSL_macos.c
#endif
// tiedosto OSL_riippuvatosat.c loppuu tähän
Tuossa OSL_os_semi_dependent.h otsikkotiedostossa sitten olisi OpenSSL -funktioiden prototyypit, jotka ovat samat kaikissa käyttöjärjestelmissä.
Esimerkki:
int OSL_gen_cryptostrong_random(void *randomdata, int datalength);
Ja sitten tiedostossa OSL_win.c olisi sellainen funktion OSL_gen_cryptostrong_random määrittely, joka toimii windowsissa (voi käyttää vaikkapa Windows API -kutsua CryptGenRandom).
vastaavasti:
Ja sitten tiedostossa OSL_linux.c olisi sellainen funktion OSL_gen_cryptostrong_random määrittely, joka toimii linuxissa (voi vaikkapa lukea laitetiedostoa /dev/random tai/dev/urandom ).
Näin muut osat OpenSSL:stä olisivat käyttöjärjestelmäriippumattomia, ja muut osat kryptografisesti vahvoja satunnaislukuja tarvitessaaan kutsuisivat funktiota OSL_gen_cryptostrong_random.
Niiden muiden osien siis EI tarvitse tietää, miten nuo kryptografisesti vahvat satunnaisluvut missäkin käyttöjärjestelmässsä tehdään, vaan samanniminen funktio ( eli esim. OSL_gen_cryptostrong_random ) toimii aina, ja sen tarkempi määrittely on sitten tiedostoissa:
OSL_win.c
OSL_linux.c
OSL_macos.c
mutta toki vain 1 näistä on oikeasti osa kääntämistä kussakin käyttöjärjestelmässä, eli esim. windowsissa tuossa OSL_win.c -tiedostossa on windowsissa toimiva tapa, ja windows -käännöksessä ei mukaan tule lainkaan noita OSL_linux.c ja OSL_macos.c, koska #ifdef -lauseen argumentti on tällöin false.
Noin toimimalla koko homma olisi voitu tehdä ilman Perl -skriptiä ja myös ilman automakea / autoconfia.
Miksi homma pitää ehdoin tahdoin tehdä vaikeaksi ????
Ja jos vaikkapa sama tapa toimii sekä linuxissa että macOS:ssa, mutta ei windowsissa, niin eihän mikään estä laittamasta sekä OSL_linux.c että OSL_macos.c -tiedostoon lausetta:
#include OSL_linux_and_macos.c
Silloin ei tarvitse samoja funktioita turhaan kirjoittaa kahteen kertaan noihin, mutta sensijaan windowsissa taas voi olla eri toteutus, suoraan tiedostossa
OSL_win.c
Näin olisin itse asian hoitanut jos olisin OpenSSL:n päätekijä.
Hyvä kysymys: Miksi näin ei ole tehty ????
Miksi OpenSSL monimutkainen kääntöjärjestelmä ?
18
818
Vastaukset
- Anonyymi
Noin paljon paljastavia asiavirheitä sait sopimaan avaukseen, tarkistapa kirjoituksesi paikkansa pitävyys.
- Anonyymi
Eipä ole ensimmäistäkään asiavirhettä. Vastauksesi = Aiheeton mustamaalausyritys !
- Anonyymi
Anonyymi kirjoitti:
Eipä ole ensimmäistäkään asiavirhettä. Vastauksesi = Aiheeton mustamaalausyritys !
GNU Compiler Collection (yleensä GCC).
Suorita kokoaminen (gcc -Wall -c "hello.c") käyttäen -Wall optiota, joka mahdollistaa varoitusten näytön.
Ja vasta sitten kun kokoaminen menee virheettömästi suoritat kääntämisen:
gcc -Wall -o "hello" "hello.o"
Ymmärrätkö tuosta yhtään mitään. - Anonyymi
Anonyymi kirjoitti:
Eipä ole ensimmäistäkään asiavirhettä. Vastauksesi = Aiheeton mustamaalausyritys !
Eihän tuossa pitkässä tarinassasi mikään pidä paikkaansa, täyttä soopaa koko juttu.
- Anonyymi
Anonyymi kirjoitti:
GNU Compiler Collection (yleensä GCC).
Suorita kokoaminen (gcc -Wall -c "hello.c") käyttäen -Wall optiota, joka mahdollistaa varoitusten näytön.
Ja vasta sitten kun kokoaminen menee virheettömästi suoritat kääntämisen:
gcc -Wall -o "hello" "hello.o"
Ymmärrätkö tuosta yhtään mitään.Niin:
kun ITSE kirjoitat koodia C -kielellä, suositellaan -Wall -optiota, joka varoittaa suunnilleen kaikista mahdollisista virheistä / epäjohdonmukaisuuksista (jotka puolestaan voivat olla tai olla olematta varsinaisia virheitä).
Sensijaan, jos haluat kääntää jonkun toisen kirjoittamaa C -koodia, tilanne on yleensä se, että koodissa ei ole (tai ei ainakaan pitäisi olla) vakavia virheitä.
Tällöin -Wall -option käytöllä tai käyttämättä jättämisellä ei ole merkitystä. Miksi haluaisin toisen henkilön kirjoittamaa koodia kääntäessäni nähdä pitkän listan varoituksia, joille en tosiasiassa kuitenkaan itse tekisi mitään, kuten on tilanne jo valmiiksi kirjoitetua OpenSSL -kirjastoa käännettäessä.
En todellakaan halua nähdä niitä varoituksia kun ne ei ketään kiinnosta.
Jos kiinnostaisi, ehkä sen OpenSSL:n alkuperäiset tekijät olisivat tuota -Wall -optiota käyttäneet ja muokanneet koodiaan sellaiseksi, ettei niitä varoituksia tule.
Esittämäni tapa käyttää #include ja #ifdef -direktiivejä on aivan toimiva.
Jos itse olisin koodannut OpenSSL:n C -kielellä, olisin nimenomaan toiminut esittämälläni tavalla, ja mitään Perl -skriptiä ei kääntämiseen tällöin tarvittaisi.
OpenSSL ei sisällä ns. käyttöliittymäkoodia. Siksi sen sisältämästä koodista alle 1% pitäisi olla millään tavalla käyttöjärjestelmästä riippuvaa.
Ainoa, joka riippuu käyttöjärjestelmästä, on
1) Kryptovahvojen satunnaislukujen tuottaminen
ja
2) TCP/IP -kommunikointi
Kaikki muu onkin (tai ainakin pitäisi olla) sitten käyttöjärjestelmästä riippumatonta koodia.
Ainoana poikkeuksena mahdollinen debug -tarkoituksiin tiedon raportointi.
Sen toteuttaisin itse näin:
Koodi oletuksena tulostaa sen konsoliin printf -funktiolla. Koska se on osa standardi C -kirjastoa, se toimii ohjelmakoodin näkökulmasta samoin kaikissa käyttöjärjestelmissä.
Kuitenkin niin, että voisi olla vaikkapa:
SetErrorPrintFunction (TErrorPrintFunction *F);
-funktio, joka ottaa argumentikseen käyttäjän määrittelemän funktion, jonka käyttäjä itse määrittelee (jos aikoo käyttää muuta virhetiedon raportointia kuin oletyuksena oleva printf) näin:
int PrintErrorInformation(const char * ErrorMessage);
Vaikkapa niin, että jos palautetaan 0, mitään erityistä ei tapahdu.
Palautusarvo = -1 merkitsee, että ko. toiminto perutaan (ja sen kutsujalle palautetaan virhekoodi).
Palautusarvo = -2 merkitsee, että koko ohjelma lopetetaan.
Tässäkään ei ole mitään käyttöjärjestelmäriippuvaa ! - Anonyymi
Anonyymi kirjoitti:
Niin:
kun ITSE kirjoitat koodia C -kielellä, suositellaan -Wall -optiota, joka varoittaa suunnilleen kaikista mahdollisista virheistä / epäjohdonmukaisuuksista (jotka puolestaan voivat olla tai olla olematta varsinaisia virheitä).
Sensijaan, jos haluat kääntää jonkun toisen kirjoittamaa C -koodia, tilanne on yleensä se, että koodissa ei ole (tai ei ainakaan pitäisi olla) vakavia virheitä.
Tällöin -Wall -option käytöllä tai käyttämättä jättämisellä ei ole merkitystä. Miksi haluaisin toisen henkilön kirjoittamaa koodia kääntäessäni nähdä pitkän listan varoituksia, joille en tosiasiassa kuitenkaan itse tekisi mitään, kuten on tilanne jo valmiiksi kirjoitetua OpenSSL -kirjastoa käännettäessä.
En todellakaan halua nähdä niitä varoituksia kun ne ei ketään kiinnosta.
Jos kiinnostaisi, ehkä sen OpenSSL:n alkuperäiset tekijät olisivat tuota -Wall -optiota käyttäneet ja muokanneet koodiaan sellaiseksi, ettei niitä varoituksia tule.
Esittämäni tapa käyttää #include ja #ifdef -direktiivejä on aivan toimiva.
Jos itse olisin koodannut OpenSSL:n C -kielellä, olisin nimenomaan toiminut esittämälläni tavalla, ja mitään Perl -skriptiä ei kääntämiseen tällöin tarvittaisi.
OpenSSL ei sisällä ns. käyttöliittymäkoodia. Siksi sen sisältämästä koodista alle 1% pitäisi olla millään tavalla käyttöjärjestelmästä riippuvaa.
Ainoa, joka riippuu käyttöjärjestelmästä, on
1) Kryptovahvojen satunnaislukujen tuottaminen
ja
2) TCP/IP -kommunikointi
Kaikki muu onkin (tai ainakin pitäisi olla) sitten käyttöjärjestelmästä riippumatonta koodia.
Ainoana poikkeuksena mahdollinen debug -tarkoituksiin tiedon raportointi.
Sen toteuttaisin itse näin:
Koodi oletuksena tulostaa sen konsoliin printf -funktiolla. Koska se on osa standardi C -kirjastoa, se toimii ohjelmakoodin näkökulmasta samoin kaikissa käyttöjärjestelmissä.
Kuitenkin niin, että voisi olla vaikkapa:
SetErrorPrintFunction (TErrorPrintFunction *F);
-funktio, joka ottaa argumentikseen käyttäjän määrittelemän funktion, jonka käyttäjä itse määrittelee (jos aikoo käyttää muuta virhetiedon raportointia kuin oletyuksena oleva printf) näin:
int PrintErrorInformation(const char * ErrorMessage);
Vaikkapa niin, että jos palautetaan 0, mitään erityistä ei tapahdu.
Palautusarvo = -1 merkitsee, että ko. toiminto perutaan (ja sen kutsujalle palautetaan virhekoodi).
Palautusarvo = -2 merkitsee, että koko ohjelma lopetetaan.
Tässäkään ei ole mitään käyttöjärjestelmäriippuvaa !No teeppä sitten silleen, kuin haluat.
- Anonyymi
Anonyymi kirjoitti:
Niin:
kun ITSE kirjoitat koodia C -kielellä, suositellaan -Wall -optiota, joka varoittaa suunnilleen kaikista mahdollisista virheistä / epäjohdonmukaisuuksista (jotka puolestaan voivat olla tai olla olematta varsinaisia virheitä).
Sensijaan, jos haluat kääntää jonkun toisen kirjoittamaa C -koodia, tilanne on yleensä se, että koodissa ei ole (tai ei ainakaan pitäisi olla) vakavia virheitä.
Tällöin -Wall -option käytöllä tai käyttämättä jättämisellä ei ole merkitystä. Miksi haluaisin toisen henkilön kirjoittamaa koodia kääntäessäni nähdä pitkän listan varoituksia, joille en tosiasiassa kuitenkaan itse tekisi mitään, kuten on tilanne jo valmiiksi kirjoitetua OpenSSL -kirjastoa käännettäessä.
En todellakaan halua nähdä niitä varoituksia kun ne ei ketään kiinnosta.
Jos kiinnostaisi, ehkä sen OpenSSL:n alkuperäiset tekijät olisivat tuota -Wall -optiota käyttäneet ja muokanneet koodiaan sellaiseksi, ettei niitä varoituksia tule.
Esittämäni tapa käyttää #include ja #ifdef -direktiivejä on aivan toimiva.
Jos itse olisin koodannut OpenSSL:n C -kielellä, olisin nimenomaan toiminut esittämälläni tavalla, ja mitään Perl -skriptiä ei kääntämiseen tällöin tarvittaisi.
OpenSSL ei sisällä ns. käyttöliittymäkoodia. Siksi sen sisältämästä koodista alle 1% pitäisi olla millään tavalla käyttöjärjestelmästä riippuvaa.
Ainoa, joka riippuu käyttöjärjestelmästä, on
1) Kryptovahvojen satunnaislukujen tuottaminen
ja
2) TCP/IP -kommunikointi
Kaikki muu onkin (tai ainakin pitäisi olla) sitten käyttöjärjestelmästä riippumatonta koodia.
Ainoana poikkeuksena mahdollinen debug -tarkoituksiin tiedon raportointi.
Sen toteuttaisin itse näin:
Koodi oletuksena tulostaa sen konsoliin printf -funktiolla. Koska se on osa standardi C -kirjastoa, se toimii ohjelmakoodin näkökulmasta samoin kaikissa käyttöjärjestelmissä.
Kuitenkin niin, että voisi olla vaikkapa:
SetErrorPrintFunction (TErrorPrintFunction *F);
-funktio, joka ottaa argumentikseen käyttäjän määrittelemän funktion, jonka käyttäjä itse määrittelee (jos aikoo käyttää muuta virhetiedon raportointia kuin oletyuksena oleva printf) näin:
int PrintErrorInformation(const char * ErrorMessage);
Vaikkapa niin, että jos palautetaan 0, mitään erityistä ei tapahdu.
Palautusarvo = -1 merkitsee, että ko. toiminto perutaan (ja sen kutsujalle palautetaan virhekoodi).
Palautusarvo = -2 merkitsee, että koko ohjelma lopetetaan.
Tässäkään ei ole mitään käyttöjärjestelmäriippuvaa !"En todellakaan halua nähdä niitä varoituksia kun ne ei ketään kiinnosta.
Jos kiinnostaisi, ehkä sen OpenSSL:n alkuperäiset tekijät olisivat tuota -Wall -optiota käyttäneet ja muokanneet koodiaan sellaiseksi, ettei niitä varoituksia tule."
On sitä varmaan käytetty mutta edelleenkin kyse on 22 vuotta vanhasta ohjelmasta, että sinä aikana on yleisesti käytössä olevat staattiset koodin tarkistukset parantuneet ja C-kielen standardi päivittynyt myös.
"Jos itse olisin koodannut OpenSSL:n C -kielellä, olisin nimenomaan toiminut esittämälläni tavalla, ja mitään Perl -skriptiä ei kääntämiseen tällöin tarvittaisi."
Millä tavalla teit vuonna 1998 alustariippumattomaksi C-kielisen avoimen lähdekoodin ohjelman käännöksen konfiguroinnin?
"Kaikki muu onkin (tai ainakin pitäisi olla) sitten käyttöjärjestelmästä riippumatonta koodia."
Paitsi kääntäminen itse. Esimerkiksi unixit, BeOS, DOS, ja Windows olivat aika erilaisia silloin vuonna 1998. Makefile kun on riippuvainen shellistä. Sitten tietysti on sellaisia asioita kuin vaikka eri prosessoriarkkitehtuurit. - Anonyymi
Anonyymi kirjoitti:
GNU Compiler Collection (yleensä GCC).
Suorita kokoaminen (gcc -Wall -c "hello.c") käyttäen -Wall optiota, joka mahdollistaa varoitusten näytön.
Ja vasta sitten kun kokoaminen menee virheettömästi suoritat kääntämisen:
gcc -Wall -o "hello" "hello.o"
Ymmärrätkö tuosta yhtään mitään.Mitä mitä, kuvittelin aina että tuo Wall = "seinä", mutta sekö onkin warnings all yms? hahah!
- Anonyymi
Anonyymi kirjoitti:
Mitä mitä, kuvittelin aina että tuo Wall = "seinä", mutta sekö onkin warnings all yms? hahah!
Se ei kuitenkaan ollut se asia jonka avausta arvostelevassa kommentissani halusin tuoda esille, vaa se oli tämä:
AVAAJA VÄITTI NÄIN
Yksinkertaisia C -ohjelmia voi kääntää näin:
gcc -c paaohjelma.c
Ja tuohan ei vielä tuota käännöstä, vaan objekti tiedoston "paaohjelma.o", jonka pohjalta vasta suoritetaan lopullinen kääntäminen:
gcc -Wall -o "paaohjelma" "paaohjelma.o"
Niin kontitiedostoa *.o luodessa kuten myös lopullista suoritettavaa tiedostoa luodessa on tärkeää seurata virheitä, eikä se seuraamisen tarve millään tavalla vähene jos lähdekoodin on toisen tekemä.
Tämä ja kaikki muu joka avauksessa otettiin esille on HUUH Haata, täyttä soopaa. Epäilen että tämä tehtiin tahallisesti näin typeräksi. - Anonyymi
Anonyymi kirjoitti:
Se ei kuitenkaan ollut se asia jonka avausta arvostelevassa kommentissani halusin tuoda esille, vaa se oli tämä:
AVAAJA VÄITTI NÄIN
Yksinkertaisia C -ohjelmia voi kääntää näin:
gcc -c paaohjelma.c
Ja tuohan ei vielä tuota käännöstä, vaan objekti tiedoston "paaohjelma.o", jonka pohjalta vasta suoritetaan lopullinen kääntäminen:
gcc -Wall -o "paaohjelma" "paaohjelma.o"
Niin kontitiedostoa *.o luodessa kuten myös lopullista suoritettavaa tiedostoa luodessa on tärkeää seurata virheitä, eikä se seuraamisen tarve millään tavalla vähene jos lähdekoodin on toisen tekemä.
Tämä ja kaikki muu joka avauksessa otettiin esille on HUUH Haata, täyttä soopaa. Epäilen että tämä tehtiin tahallisesti näin typeräksi.Lisätäänpä vielä syykin tuolle epäilylle. Syynä saattaa olla halu saada aikaan kiihkeä ja pitkä keskustelu vääristelemällä tosiasioita.
- Anonyymi
Anonyymi kirjoitti:
Lisätäänpä vielä syykin tuolle epäilylle. Syynä saattaa olla halu saada aikaan kiihkeä ja pitkä keskustelu vääristelemällä tosiasioita.
Ei, vaan tarkoitus oli:
a) kysyä, miksi yleensä pitää tehdä C -kielisen koodin kääntämisestä (tässä tapauksessa Windows DLL:ksi) niin monimutkaista ?
ja
b) Kysyä, josko jollakulla olisi jokin vinkki, miten voin tuottaa 32-bittisen Windows DLL:n OpenSSL -lähdekoodista ilmaiseksi saatavana olevilla työvälineillä ????
Tällä hetkellä tilanne on tämä:
Strawberry PERL olisi ilmainen, mutta sillä kun yrittää kääntää, tulee kasa virheilmoituksia.
Ja se OpenSSL -koodaajien suosittelema Perl ei ole Strawberry PERL, vaan sen kilpailija ActiveState Perl v5.20.2
MUTTA:
Tuo ActiveState Perl on nykyisin ilmainen vain 64 -bittisen version osalta, 32-bittisestä ActiveState Perlistä pitää maksaa !
Siis: Miten voin tuottaa 32-bittisen Windows DLL:n OpenSSL -lähdekoodista ilmaiseksi saatavana olevilla työvälineillä ?
Tähän kysymykseen ei toistaiseksi ole löytynyt vastata.
tuo -Wall -optiosta jauhaminen vie keskustelun täysin sivuraiteille. OpenSSL -koodissa ei pitäisi olla vakavia virheitä, ja jos sellaisia on, en kuitenkaan osaisi tehdä niille mitään - siispä en halua nähdä turhanpäiväisiä varoituksia.
Ärsyttää vain äärettömästi se, että jos teen (itse valitsemallani ohjelmointikielellä) ohjelman, joka käy läpi kaikki OpenSSL -hakemiston (ja sen alihakemistojen) ".c" -päätteiset tiedostot, ja ajaa jokaiselle erikseen:
gcc -c tiedostonimi.c
niin voiko noista tuloksena olevista .o
-tiedostoista koostaa DLL:n esim näin:
gcc -static -shared t1.o t2.o t3.o t4.o -o OpenSSL.DLL
-shared -optio siis siksi kun ei haluta tehdä EXEä, vaan DLL.
Ja -static -optio siksi, että käännetyn DLL:n pitää toimia sellaisenaan koneessa, johon on juuri asennettu Windows -käyttöjärjestelmä, mutta ei mitään muuta.
Ilman -static -optiota tuloksena on todennäköisesti DLL, joka vaatii toimiakseen yhden tai useamman muun sellaisen DLL:n, joka ei asennu automaattisesti Windows -käyttöjärjestelmän asennuksen yhteydessä.
Kun ei haluta rasittaa loppukäyttäjää velvollisuudella asennella kaiken maailman apu-DLL:iä, niin siksi tuo -static, silloin tehdyn DLL:n ei pitäisi olla riippuvainen mistään sellaisesta muusta DLL:stä, jota kohdekoneella ei ole.
Joten: voiko tuon OpenSSL:n kääntää siten, että käännetään jokainen OpenSSL -hakemistopuusta löytyvä ".c" -tiedosto ?
Entä, jos jokin käännös päättyy virheeseen?
Voiko silloin päätellä, että tämä ".c" -tiedosto liittyy johonkin toiseen käyttöjärjestelmään, eikä ole tarkoitettu käytettäväksi 32 -bittistä Windows -versiota käännettäessä ? - Anonyymi
Anonyymi kirjoitti:
"En todellakaan halua nähdä niitä varoituksia kun ne ei ketään kiinnosta.
Jos kiinnostaisi, ehkä sen OpenSSL:n alkuperäiset tekijät olisivat tuota -Wall -optiota käyttäneet ja muokanneet koodiaan sellaiseksi, ettei niitä varoituksia tule."
On sitä varmaan käytetty mutta edelleenkin kyse on 22 vuotta vanhasta ohjelmasta, että sinä aikana on yleisesti käytössä olevat staattiset koodin tarkistukset parantuneet ja C-kielen standardi päivittynyt myös.
"Jos itse olisin koodannut OpenSSL:n C -kielellä, olisin nimenomaan toiminut esittämälläni tavalla, ja mitään Perl -skriptiä ei kääntämiseen tällöin tarvittaisi."
Millä tavalla teit vuonna 1998 alustariippumattomaksi C-kielisen avoimen lähdekoodin ohjelman käännöksen konfiguroinnin?
"Kaikki muu onkin (tai ainakin pitäisi olla) sitten käyttöjärjestelmästä riippumatonta koodia."
Paitsi kääntäminen itse. Esimerkiksi unixit, BeOS, DOS, ja Windows olivat aika erilaisia silloin vuonna 1998. Makefile kun on riippuvainen shellistä. Sitten tietysti on sellaisia asioita kuin vaikka eri prosessoriarkkitehtuurit.No kun EI TARVITA mitään erillistä konfigurointia !
vaan tekstitiedosto, jossa on tämäntapaisia rivejä:
gcc -c tiedosto1.c
gcc -c tiedosto2.c
gcc -c tiedosto3.c
gcc -c tiedosto4.c
ja lopuksi:
gcc -shared -static tiedosto1.o tiedosto2.o tiedosto3.o tiedosto4.o -o openssl.so
tai windowsille:
gcc -shared -static tiedosto1.o tiedosto2.o tiedosto3.o tiedosto4.o -o openssl.dll
Ja olen jo aiemmin esittänyt idean siitä, että:
Tiedoston OSL_riippuvatosat.c sisältö:
#include OSL_os_semi_dependent.h
#ifdef mswindows
OSL_win.c
#endif
#ifdef linux
OSL_linux.c
#endif
#ifdef macos
OSL_macos.c
#endif
// tiedosto OSL_riippuvatosat.c loppuu tähän
Tuolla tavalla C -kääntäjä osaa noiden #ifdef -lauseiden ohjaamana ihan ITSE (siis ilman ulkoista kääntöjärjestelmää) esim ottaa mukaan käännökseen
OSL_win.c silloin , kun käännetään windowsille ja vastaavasti:
OSL_linux.c
Onko olemassa jokin sellainen käyttöjärjestelmä, jossa ei ole komentorivilistatiedostoja kuten kaanna.BAT (MS-Windows)
tai kaanna (ilman tiedostopäätettä, linux) ?
Linuxissahan tuo kaanna usein alkaa näin:
#!/bin/bash
Silloin riittäisi tämän saman komentotiedoston uudelleennimeäminen BAT -päätteiseksi (Windows) tai että siihen lisätään tuo
#!/bin/bash
uudeksi ensimmäiseksi riviksi (Linux).
Onko todella olemassa niin alkeellisia käyttöjärjestelmiä, joilla vastaavaa toiminnallisuutta kuin .BAT -tiedosto windowsissa ei ole ???
Erilliselle kääntöjärjestelmälle ei siis ole todellista tarvetta, vaan sillä vain tehdään asiat vaikeammaksi ! - Anonyymi
Anonyymi kirjoitti:
Ei, vaan tarkoitus oli:
a) kysyä, miksi yleensä pitää tehdä C -kielisen koodin kääntämisestä (tässä tapauksessa Windows DLL:ksi) niin monimutkaista ?
ja
b) Kysyä, josko jollakulla olisi jokin vinkki, miten voin tuottaa 32-bittisen Windows DLL:n OpenSSL -lähdekoodista ilmaiseksi saatavana olevilla työvälineillä ????
Tällä hetkellä tilanne on tämä:
Strawberry PERL olisi ilmainen, mutta sillä kun yrittää kääntää, tulee kasa virheilmoituksia.
Ja se OpenSSL -koodaajien suosittelema Perl ei ole Strawberry PERL, vaan sen kilpailija ActiveState Perl v5.20.2
MUTTA:
Tuo ActiveState Perl on nykyisin ilmainen vain 64 -bittisen version osalta, 32-bittisestä ActiveState Perlistä pitää maksaa !
Siis: Miten voin tuottaa 32-bittisen Windows DLL:n OpenSSL -lähdekoodista ilmaiseksi saatavana olevilla työvälineillä ?
Tähän kysymykseen ei toistaiseksi ole löytynyt vastata.
tuo -Wall -optiosta jauhaminen vie keskustelun täysin sivuraiteille. OpenSSL -koodissa ei pitäisi olla vakavia virheitä, ja jos sellaisia on, en kuitenkaan osaisi tehdä niille mitään - siispä en halua nähdä turhanpäiväisiä varoituksia.
Ärsyttää vain äärettömästi se, että jos teen (itse valitsemallani ohjelmointikielellä) ohjelman, joka käy läpi kaikki OpenSSL -hakemiston (ja sen alihakemistojen) ".c" -päätteiset tiedostot, ja ajaa jokaiselle erikseen:
gcc -c tiedostonimi.c
niin voiko noista tuloksena olevista .o
-tiedostoista koostaa DLL:n esim näin:
gcc -static -shared t1.o t2.o t3.o t4.o -o OpenSSL.DLL
-shared -optio siis siksi kun ei haluta tehdä EXEä, vaan DLL.
Ja -static -optio siksi, että käännetyn DLL:n pitää toimia sellaisenaan koneessa, johon on juuri asennettu Windows -käyttöjärjestelmä, mutta ei mitään muuta.
Ilman -static -optiota tuloksena on todennäköisesti DLL, joka vaatii toimiakseen yhden tai useamman muun sellaisen DLL:n, joka ei asennu automaattisesti Windows -käyttöjärjestelmän asennuksen yhteydessä.
Kun ei haluta rasittaa loppukäyttäjää velvollisuudella asennella kaiken maailman apu-DLL:iä, niin siksi tuo -static, silloin tehdyn DLL:n ei pitäisi olla riippuvainen mistään sellaisesta muusta DLL:stä, jota kohdekoneella ei ole.
Joten: voiko tuon OpenSSL:n kääntää siten, että käännetään jokainen OpenSSL -hakemistopuusta löytyvä ".c" -tiedosto ?
Entä, jos jokin käännös päättyy virheeseen?
Voiko silloin päätellä, että tämä ".c" -tiedosto liittyy johonkin toiseen käyttöjärjestelmään, eikä ole tarkoitettu käytettäväksi 32 -bittistä Windows -versiota käännettäessä ?"a) kysyä, miksi yleensä pitää tehdä C -kielisen koodin kääntämisestä (tässä tapauksessa Windows DLL:ksi) niin monimutkaista ?"
Windows ei ole unix.
"b) Kysyä, josko jollakulla olisi jokin vinkki, miten voin tuottaa 32-bittisen Windows DLL:n OpenSSL -lähdekoodista ilmaiseksi saatavana olevilla työvälineillä ????"
Oletko Debiania kokeillut jos ristiinkääntämällä tekisi?
"Siis: Miten voin tuottaa 32-bittisen Windows DLL:n OpenSSL -lähdekoodista ilmaiseksi saatavana olevilla työvälineillä ?"
Pidän lähes 100% todennäköisenä sitä, että yrität tehdä jotain tyhmää. Parempia neuvoja voisi antaa jos tietää mitä liiketoiminta tms. ongelmaa yrität ratkaista.
- Anonyymi
"Miksi esim. OpenSSL:n kääntämistä ei voi(si) tehdä noin, vaan miksi siihen tarvitaan mittava kääntöjärjestelmä ?"
Käytännössä kaikki ohjelmat tarvitsevat sen kääntöjärjestelmän kun niitä käännettäviä ja linkattavia tiedostoja on kuitenkin niin paljon. Lisäksi ei haluta turhaan kääntää kaikkia tiedostoja jos muutetaan vain yhtä.
Kääntöjärjestelmä on tehty Perlillä siksi kun se on noin vanha ja Autoconf ei riittänyt. Ilmeinen syy näkyy olevan siinä, että haluttu skripti mikä konfiguroi ja tuo sitten kääntyy muuallekin kuin unixeihin, koska Autoconf on kuitenkin sidoksissa unixeihin.- Anonyymi
Ite tein projektiini oman kääntöjärjestelmä-ohjelman, joka kääntää koodi-tiedostoja rinnakkain, niin monta kuin prossu pystyy säikeitä käsittelemään, esim. 8 kpl. Projekti sisältää nykysin yli 46 000 riviä koodia ja koko projektin kääntö puhtaalta pöydältä vie lähemmäksi 35 sek (debug -moodissa), parhailla optimoinneilla jo useampi minuutti.
Se miksi päädyin tähän on kun koodaan D-kielellä ja tuo make tuntui aika köykäiselle, jurnutti juurikin yhtä tiedostoa kerralla kääntäen. Toki D-kielelle on Dub, tuohon pitänee joskus tutustua.
- Anonyymi
Jaa että toisen tekemässä koodissa ei ole virheitä eikä ole syytä tarkistaa?
Oliko muita vitsejä?
Kuulostaa samalta kuin miksi en aikanaan lähtenyt Liima-tukkailuun.
1993 opiskelelssani Helsingissä koulussa toki oli jotain Linuksen hangaround tyyppejä ja heillä oli hauska tapa kääntää tekeleensä c-koodia.
Kun kääntö meni vituiksi kommentoitiin rivejä ulos kunnes kääntö meni läpi.
Noiden iloisten heppujen takia edelleen olen tänään BSD mies.- Anonyymi
Mitäpä vikaa pois-kommentoinnissa? Veikkaan että kyseessä oli jokin driver-moduli, joka ei kääntynyt, jolloin kysymys kuuluu, onko laitteessa em. tukevaa HW:ta? Jos ei, niin sen voi huoletta kommentoida pois vaikkapa sitten koodista, koska se on paikka, jonka kääntäjä suoraan näyttää menevän solmuille. Silloin ei ollut vielä makefile-systeemi yhtä joustava kuin nykyään ja paikan etsiminen makefilesta olisi vaatinut ajaa sen aikaisilla koneilla pitkäkestoisen etsintäkomennon, 3min tai enemmän. Säästi siis aikaa poistaa käyttämätöntä koodia paikasta, jossa sitä ei tarvittu. Koodin korjaaminen taas, no, miten korjata, jos valmistaja kieltäytyy antamasta speksejä ja toisaalta ei omista em. HW:ta? Selkeästi tehtävä sille, joka driverin on alunperinkin koodannut - tai jollekulle jolla em. kortti löytyy..
Olisiko tämä ollut se vitsi, jolle naurettiin eli ympärillä ihmisiä, jotka ei ymmärrä miksi näin voi menetellä? - Anonyymi
""Jaa että toisen tekemässä koodissa ei ole virheitä eikä ole syytä tarkistaa?
Oliko muita vitsejä?""
Onhan tuossa jo vitsiä tarpeeksi, eli olet sen tarkistanut että ei ole virheitä. Mutta eikö sinulle sitten millään mene jakeluun se että, antamasi ohje ei ole vielä käynyt läpi varsinaista kääntämistä, jakelet vääriä ohjeita, vääristelet asioita ja intät inttämisestä päästyäsi aivan järjettömiä asioita.
Ketjusta on poistettu 1 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Mies kateissa Lapualla
Voi ei taas! Toivottavasti tällä on onnellinen loppu. https://poliisi.fi/-/mies-kateissa-lapualla1125855Poliisi tutkii murhaa Paltamossa
Poliisi tutkii Kainuussa sijaitsevassa Paltamon kunnassa epäiltyä henkirikosta, joka on tapahtunut viime viikon perjanta323977- 823332
Jos me voitais puhua
Jos me voitais puhua tästä, mä sanoisin, että se on vaan tunne ja se menee ohi. Sun ei tarvitse jännittää mua. Mä kyllä182956Jenna meni seksilakkoon
"Olen oppinut ja elän itse siinä uskossa, että feministiset arvot omaava mies on tosi marginaali. Todennäköisyys, että t2502007Joo nyt mä sen tajuan
Kaipaan sua, ei sitä mikään muuta ja olet oikea❤️ miksi tämän pitää olla niin vaikeaa?881974- 1411758
Jere, 23, ja Aliisa, 20, aloittavat aamunsa Subutexilla tai rauhoittavilla: "Vaikka mä käytän..."
Jere, 23, ja Aliisa, 20, ovat pariskunta, joka aloittaa aamunsa Subutexilla tai rauhoittavilla. Jere on ollut koko aikui391705Olipa ihana rakas
❤️🤗😚 Toivottavasti jatkat samalla linjalla ja höpsöttelykin on sallittua, kunhan ei oo loukkaavaa 😉 suloisia unia kau81686Vain yksi elämä
Jonka haluaisin jakaa sinun kanssasi. Universumi heitti noppaa ja teki huonon pilan, antoi minun tavata sinut ja rakastu881539