kompilere svært? hvorfor?

[gtr]

Der er noget omkring kompilering, jeg gerne vil have en forklaring på.

Hvis en programmør kan programmere et program, hvordan kan det da være, at han ikke kan kompilere det
færdigt til de forskellige systemer?
Hvori består det svære?

Hvis man fx har viden til at programmere programmet, og fx kan kompilere det til windows, så brugere
kan hente programmet som en exe fil til windows, men også udbyder sourcekoden, hvorfor
kan programmøren da ikke nemt lave en deb pakke, rpm pakke eller en pakke til mac?

Er det fordi det kræver, at han har et indgående kendskab til de forskellige systemer?

Noget tyder på, at det må være vanskeligt at kompilere til diverse systemer, fordi på nogle
hjemmesider kan jeg se, at dem, der har programmeret sourcekoden, takker dem, der har kompileret
til et system udtrykkeligt?

For mig virker det mere rationelt, hvis den, der udbyder sourcekoden, også foretager kompileringen,
i stedet for hver enkelt bruger skal finde ud af at kompilere, hver for sig.

Tak.

[gaffa]

Det simple svar er at det kræver tid og ressourcer. Hvis bare en bruger sørger for at dele sine fremskridt med alle sine medmennesker så, behøver alle andre brugere ikke at kompilere. Vi er allesammen udviklere og vi laver det vi har lyst til i vores fritid.

Jeg laver gerne arbejde for andre, hvis jeg får løn for det

[AJenbo]

Det er noget sværere at komme til at kompilere kode på Windows og det er største delen af brugerne der benytter Windows så der for er tide for programmøren ofte godt givet ud ved at lave en exe.

Hvis programmøren kompilere er resultatet heller ikke optimeret til det enkelte system men mere generelt. For at teste det skal han også have et system kørende og det er nogle gange også et krav for at kompilere. Et program kompilere til Debian 7 kan ikke nødvendigvis køre på Debian 6, selv om den godt ville kunne kompileres til det. Windows har fære versioner, men man inkludere også ofte afhængigheder med programmet, fordelen er at det kan køre på flere udgaver men hvert program inkludere alle biblioteker og kræver derfor mere af maskinen.

Det kræver viden og arbejder at lave en korrekt rpm, og lige så meget at lave en deb, pkg, pup, ebuild, slp, osv. Og så skal de løbende testes og vedligeholdelse, både når programmet opdateres men også når det pågældende system ændres, og der skal muligvis laves flere varianter for at understøtte forskellige systemer som bruger samme pakke format.

Så jo mindre brugt et system er og jo mere tekniske dets brugere er jo mindre er chancen for at et program kommer i et format til det.

Er der interesse nok fra et systems brugere kan det dog ske noget laver pakker til programmet eller ligefrem får det med i det officielle arkiv

[lath]

Der er noget omkring kompilering, jeg gerne vil have en forklaring på.

Hvis en programmør kan programmere et program, hvordan kan det da være, at han ikke kan kompilere det
færdigt til de forskellige systemer?
Hvori består det svære?

Hvis man fx har viden til at programmere programmet, og fx kan kompilere det til windows, så brugere
kan hente programmet som en exe fil til windows, men også udbyder sourcekoden, hvorfor
kan programmøren da ikke nemt lave en deb pakke, rpm pakke eller en pakke til mac?

Er det fordi det kræver, at han har et indgående kendskab til de forskellige systemer?

De andre har besvaret nogle af dine andre spørgsmål, så jeg vil gerne uddybe på "Hvori består det svære?" spørgsmålet.
Linux styresystemer såsom Linux er på visse punkter meget forskellig i virkemåde i forhold til Windows.
Af den årsag så skal det samme program til forskellige styresystemer normalt bruge forskellige styresystem-afhængige kodebaser i programmets I/O (Input/Output) del af programmet. Hver styresystem-afhængige kodebase er helt forskellig fra de andre, og deler oftest ikke kode med de andre.

Selv indenfor Windows versioner kan der være tale om helt forskellige styresystem-afhængige kodebaser. Tænk Fra Windows XP til Windows 7.
Region Hovedstadens sygehuse er netop i gang med den øvelse for et par 1000 Windows programmer til klinisk IT - og de programmer skal bare virke, da der potentielt ellers kan mistes menneskeliv.

I bonus kommer så at grafiske toolkits og andre APIs også er helt forskellige.
Det er derfor at f.eks. C++ toolkittet der hedder Qt er populært blandt C++ udviklere til at lave Linux, Windows, og MAC OS desktop programmer med.
Den føromtalte styresystem-afhængige kodebase findes dybt nede i Qt softwarebiblioteket, sådan at man som C++ programmør kun har behov for bruge et (=Qt's) API. API er Application Programming Interface og er funktionalitet i et softwarebibliotek der kan bruges af kode udenfor softwarebiblioteket.
APIet er defineret af dem der har lavet Qt softwarebiblioteket.

Noget tyder på, at det må være vanskeligt at kompilere til diverse systemer, fordi på nogle
hjemmesider kan jeg se, at dem, der har programmeret sourcekoden, takker dem, der har kompileret
til et system udtrykkeligt?

Det har ikke noget med programmering at gøre.
Det er ophavsret, altså IT-jura.

Kigger du nederst her i tråden, så kan du se at der har udviklerne af phpBB softwaren skrevet ophavsret information. phpBB er navnet på forum softwaren, som bruges af ubuntudanmark.dk.
Det er ret meget standard at skrive ophavsretinformation nederst på en web side.

Desuden så oversætter (det du kalder kompileret) man normalt ikke web software til maskinkode, som så afvikles. Det bliver i stedet fortolket (engelsk: interpreted).
Meget ofte er det PHP kildekode der fortolkes af en PHP fortolker. PHP fortolkeren kaldes ofte af en Apache web server.

/Lars

[AJenbo]

Noget tyder på, at det må være vanskeligt at kompilere til diverse systemer, fordi på nogle
hjemmesider kan jeg se, at dem, der har programmeret sourcekoden, takker dem, der har kompileret
til et system udtrykkeligt?

De takker for den tid folk har brugt på at test og vedligeholde den specifikke pakke, hvilket sådan set er fair nok uanset hvor meget eller lidt tid det tager. Det gør jo at programøren kan fokusere mere på at programmere

Meget ofte er det PHP kildekode der fortolkes af en PHP fortolker. PHP fortolkeren kaldes ofte af en Apache web server.

Apache er en Webserver, mens PHP-fortolkeren er en PHP fortolker Apache er dog oftest den webserver der bruges til at kalde PHP-fortolkeren og sende resultatet il browseren. Altså står Apache kun for kommunikationen mellem browseren og PHP og ikke for selv fortolkningen af php-koden.
En alternativ PHP fortolker er HipHop som bruges på Facebook.

[thj01]

Problemet med kompilering er egentlig afledt af frihed - friheden til at vælge den distribution man ønsker - og de programmer man ønsker.

Fordelen er, at man ikke behøver at vente på at nogen får pakket dem "rigtigt" ned, men at man kan tage kildekoden direkte og med det samme - ja endda lave småændringer selv.

Hvis man holder sig til standard softwaren, så er det alt sammen lavet ordentligt - og derfor behøver man aldrig at kompilere. Det er når man ønsker at få noget ekstra at man skal.

Så egentlig så får du muligheden for at få noget, som dem i windowsverdenen ikke har adgang til - adgang direkte til kilden.

så f.eks. med jailkit

Kode: Vælg alt

apt-get install gcc make
cd /tmp
wget http://olivier.sessink.nl/jailkit/jailkit-2.17.tar.gz
tar -zxvf jailkit-2.17.tar.gz
cd jailkit-2.17
./configure
make install

og bingo så har du den nyeste version installeret


Frihed er en bitch... for det giver så mange valg..... og muligheder

[gtr]

Tak for svar.

Den der kan programmere source softwaren, kan måske ikke kompilere til de forskellige styresystemer,
men måske kun et.
Source softwaren skal evt kompileres, eller måske snarere klargøres til forskellige versioner af et styresystem. Evt til opdateringer indenfor et styresystems version.

Det giver mange variabler. Og det er altså derfor noget software ikke lader sig installere.

Fx cryptsync er open source. Men der er alene en msi udgave.
Jeg spurgte ham, om der kom en linux udgave. Det gør der ikke.
Dvs softwaren kommer kun til linux, hvis der er en, der kan finde ud af den kompilering?

Der kom en ny version af linphone. Indtil nu har jeg ikke fået linphone til at virke på ubuntu 12.04.

Jeg læste README i filen. Af den fremgik, at linphone kan installeres på ubuntu.
Da installering kun forudsætter terminal, prøvede jeg at installere.

Men den gik ikke. Der var en bunke dependecies fejl, hvor pakker eller subpakker skulle
downgrades.
Hvis de ikke har lavet linphone til ubuntu 12.04, ved jeg ikke, hvilken det er lavet til.
Når der skal downgrades, kan det vel kun være ældre versioner af ubuntu?

Men dvs softwaren vil kun virke, hvis den ændres, så linphone anvender pakker, der er en del af
ubuntu's nuværende repositories?

[lath]

Hvis de ikke har lavet linphone til ubuntu 12.04, ved jeg ikke, hvilken det er lavet til.
Når der skal downgrades, kan det vel kun være ældre versioner af ubuntu?

Downgrade betyder at en pakke går ned i versionsnummer. Det er noget hø at gøre sådan noget for så er der næsten helt sikkert at en anden pakke der ikke virker.

Det er et problem der er tæt relateret til det der har det lidet flatterende navn "dll hell", og kommer fra Windows styresystemet, der før har været meget plaget af det problem.

Men dvs softwaren vil kun virke, hvis den ændres, så linphone anvender pakker, der er en del af
ubuntu's nuværende repositories?

Et program i en bestemt version har afhængigheder af en bestemt version. Hvis en afhængighed er nyere men er bagud kompatibel, så kan programmet godt bruge den - rent API mæssigt. En afhængighed er dog ikke nødvendigvis binær kompatibel selv om afhængigheden er API kompatibel.
Den slags løser man ved at linke op imod den nyere afhængighed ved at gen-oversætte kildekoden.

Hvis du har kilde koden til programmet og alle dets afhængigheder kan du lave det der i it lingo kaldes en "static linked executable", hvilket bare er et program med 0 (nul) afhængigheder.
Sådan er fil er meget praktisk idet at du bare dropper den i en af de mapper der er nævnt i PATH miljø-variablen, og derefter starter du så bare programmet, som så virker knas-frit (hvis der altså ikke er nogen programmeringsfejl i kildekoden).

Jeg plejer at placere mine egne programmer i en undermappe til min egen hjemmemappe.
Den skal kalde den mappe for bin, hvis du vil have Ubuntu til automatisk at inkludere den i PATH miljø variablen.

/Lars

[gtr]

Tak for svar.

lath
Jeg mener, jeg har forstået det, som du skriver.

Når en deb pakke, der er en dependenci for et program, updates, kan det gøres på en måde,
så den updatede pakke stadig gør det muligt for programmer at bruge pakken, selvom de
ikke er skrevet til den opdaterede deb pakke, men den forrige, eller hvor langt tilbage den
updaterede deb pakke går.
Dvs alle de softwareprogrammer, der blev skrevet til den tidligere udgave af deb pakken vil stadig
fungere. Man opnår at alle disse programmer ikke stopper med at fungere.


static linked executable
Hvis man har et program, og har alle dependenci pakkerne separat, kan man ændre programmet,
så det ikke bruger nogen af ubuntu's deb pakker. Man skal da placere de dependencies pakker,
som programmet forudsætter, i en folder.

//Den skal kalde den mappe for bin, hvis du vil have Ubuntu til automatisk at inkludere den
i PATH miljø variablen.
Den sætning forstår jeg ikke.

I home folderen har jeg en folder, der hedder Bin.
I den er der en folder, der hedder livesuit. Et program jeg ville teste.

Fx linphone har ikke et forum. De har et emailsystem, hvor man kan skrive, og se om
nogen svarer.

Jeg skrev i en email, at jeg synes, det var noget pjat, at de i README'en specifikt henviser til
ubuntu, når man ikke kan installere linphone pakken på ubuntu 12.04, der må være den mest udbredte
ubuntu version.
Jeg fik kun et svar. Han svar var uklart. Men det virkede som om, at en eller flere pakker,
som linphone 3.7.0 forudsætter, er på vej ind i debian, og dermed ubuntu. Og han skrev, at man
på nuværende tidspunkt ikke kan forvente, at linphone 3.7.0 kan installeres på alle linux
distroer.
Det skulle de skrive i README'en.

[lath]

Tak for svar.

lath
Jeg mener, jeg har forstået det, som du skriver.

Når en deb pakke, der er en dependenci for et program, updates, kan det gøres på en måde,
så den updatede pakke stadig gør det muligt for programmer at bruge pakken, selvom de
ikke er skrevet til den opdaterede deb pakke, men den forrige, eller hvor langt tilbage den
updaterede deb pakke går.

Det en opdateret pakke gør er at den linker op imod en eksisterende version fra en pakke som er i arkiverne.

Dvs alle de softwareprogrammer, der blev skrevet til den tidligere udgave af deb pakken vil stadig
fungere. Man opnår at alle disse programmer ikke stopper med at fungere.

Det er rigtigt at Ubuntu faktisk understøtter at man kan have den samme pakke i flere versioner installeret.
Det virker naturligvis kun, hvis filnavnene på afhængighederne som bor i en lib*.so.* fil har forskellige filnavne.

static linked executable
Hvis man har et program, og har alle dependenci pakkerne separat, kan man ændre programmet,
så det ikke bruger nogen af ubuntu's deb pakker. Man skal da placere de dependencies pakker,
som programmet forudsætter, i en folder.

Man ændrer ikke i programmet.

Det en linker gør rent teknisk er at den kopierer objekt koden for programmet og objekt koden for alle afhængigheder ind i den samme fil. Den fil er så programmet, og det program har så ingen afhængigheder.
Objekt kode er den rå maskinkode som er resultatet fra compilerens oversættelse af kildekode. Objekt kode har i den her forbindelse således ikke noget med objekt orienteret programmering at gøre.

//Den skal kalde den mappe for bin, hvis du vil have Ubuntu til automatisk at inkludere den
i PATH miljø variablen.
Den sætning forstår jeg ikke.

I home folderen har jeg en folder, der hedder Bin.
I den er der en folder, der hedder livesuit. Et program jeg ville teste.

Mappen i din hjemmemappe til dine egne programmer skal hedde bin og ikke Bin.
Først når du har en mappe der hedder bin bliver den automatisk inkluderet i PATH miljø variablen.
PATH miljø variablen er en liste af mapper, som er adskilt af et kolon (:). PATH fortæller Ubuntu hvor den skal kigge efter programmer.

Du kan selv inkludere flere stier i PATH miljø variablen ved at tilføje mapperne i bunden af din .profile fil.
Hvis livesuit programmet rent faktisk ligger inde i $HOME/Bin/livesuit/bin, så skal du tilføje den her linie nederst i din
.profile fil:

Kode: Vælg alt

PATH=$PATH:$HOME/Bin/livesuit/bin

Ændringen er først aktiv ved næste login.
ADVARSEL!: Du må ikke glemme $-tegnet (sigil tegnet) foran PATH for så kan du ikke logge ind, fordi at din login manager ikke kan finde det program der starter din desktop eller din shell/terminal.
Det er også en rigtig dårlig ide at glemme colon-tegnet, for så kan Ubuntu ikke finde programmer fra den sidste mappe i PATH: Der ville i mit Ubuntu styresystem være alle programmer i /usr/local/games mappen.

Fx linphone har ikke et forum. De har et emailsystem, hvor man kan skrive, og se om
nogen svarer.

Jeg skrev i en email, at jeg synes, det var noget pjat, at de i README'en specifikt henviser til
ubuntu, når man ikke kan installere linphone pakken på ubuntu 12.04, der må være den mest udbredte
ubuntu version.
Jeg fik kun et svar. Han svar var uklart. Men det virkede som om, at en eller flere pakker,
som linphone 3.7.0 forudsætter, er på vej ind i debian, og dermed ubuntu. Og han skrev, at man
på nuværende tidspunkt ikke kan forvente, at linphone 3.7.0 kan installeres på alle linux
distroer.
Det skulle de skrive i README'en.

Det er vigtigt at notere sig README filens dato, fordi det er sikkert den Ubuntu version fra det tidspunkt de skriver om.

Du kan se om de har en irc kanal på f.eks. FreeNode. I Xchat kunne du jo prøve at søge med ordet "linphone" for at finde kanalen.

/Lars