Programmare sotto Linux

[marco.r]

Originariamente inviato da arara

Se, ad esempio, vuoi usare la libreria xml2, devi scaricare il pacchetto libxml2-devel. Quando poi compili il programma devi indicare al linker che stai usando quella libreria col parametro -l:
gcc -lxml2 main.c
se la libreria non si trova nel path standard devi indicare il percorso in cui si trova col parametro -L:
gcc -L/path/libxml2 -lxml2 main.c

Soprattutto quando si tratta di "roba GNOME" e' il caso di evitare parametri espliciti e farsi aiutare da pkg-config, tanto piu' che sotto Ubuntu funziona con quasi tutto:

gcc `pkg-config --cflags libxml-2.0` -c main.c -o main.o
gcc `pkg-config --libs libxml-2.0` main.o -o main

(ovviamente va bene anche tutto su una unica riga).
Con certe librerie le flag da impostare possono essere numerose:

# pkg-config --cflags libxml++-2.0
-I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  
# pkg-config --libs libxml++-2.0
-lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0

Eviterei sistemi di build integrati nell'IDE, perche' ti legano all'ambiente di sviluppo. Meglio uno esterno, che tanto di solito non e' difficile integrarlo con l'editor.

[71104]

Originariamente inviato da -Slash

per quanto riguarda il discorso c, io penso sia piu adatto per un kernel. e poi vorrei vedere le persone che in questo momento stanno smerdando torvalds a scrivere un kernel, visto quanto sono bravi.

perché, Torvalds invece ne ha mai scritto uno???
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.

[cdimauro]

Originariamente inviato da -Slash

per quanto riguarda il discorso c, io penso sia piu adatto per un kernel.

Pensi male, visto che il C++ è un SUPERSET del C, per cui puoi fare ALMENO le stesse cose del C, e... di più, se se ne sfruttano le caratteristiche peculari.

In soldoni: non c'è alcun motivo per preferire il C al C++.

e poi vorrei vedere le persone che in questo momento stanno smerdando torvalds a scrivere un kernel, visto quanto sono bravi.

Se ti fossi preso la briga di leggere il thread di cui ho postato il link in precedenza, ti saresti accorto di due cose.

La prima è che si tratta di una domanda piuttosto banale dietro cui si rifugia chi non è in grado di argomentare altrimenti.

La seconda è che... ci troveresti la risposta.

Originariamente inviato da khelidan1980

il fatto è che tutta la merda che si tira dietro non è infondata alle volte,come ha detto cdimauro nell'altro thread,ha avuto al fortuna di avere dietro a se persone con le OO,guarda come ha fatto fuori Con kolivas dopo tutto il lavoro che ha fatto per Linux,o meglio sarebbe da dire come non lo ha mai ufficialmente considerato

*

Originariamente inviato da mindwings

Hai appena detto che i programmatori linux usando C sono scarsi.

Hai appena dimostrato che la logica non è dominio di tutti.

Il linguaggio è soltanto uno strumento che ti può facilitare o meno la vita

Ed è uno strumento MOLTO importante, che a volte può anche fare la differenza.

Ecco perché la sua scelta non è affatto banale.

ciò che conta sono le capacità di design che si acquistano con l'esperienza. Le discussioni precedenti non sono LA bibbia
le opinioni si possono condividere o meno e discuterne altre 20/50/1000 volte può aiutare a sviluppare un senso
critico purchè si apportino pareri senza ostentarli per LA VERITA'

Di come stiano le cose sull'argomento linguaggio di programmazione C vs C++ ne abbiamo già AMPIAMENTE parlato nel thread in questione (e anche in precedenza).

Quanto alle capacità di design di cui parli, non si acquistano soltanto con l'esperienza: spesso si tratta di una dote innata.
Vedi le alterne vicende dell'audio sotto Linux, ad esempio, che sono un ottimo esempio di come tali "doti" si sprechino...

Generalizzare fa male di programmatori ce ne sono di bravi e meno bravi sia su piattaforma gnu/linux che windows .

Anche intestardirsi sull'uso di linguaggi poco produttivi e maggiormente proni a errori come il C fa piuttosto male.

Per il resto, è vero: programmatori più o meno bravi si trovano su entrambe le piattaforme.

Originariamente inviato da Pixel452

pygtk se non ho capito male si basa su phyton? Sinceramente non è che mi ispiri molto, a questo punto preferisco rimanere sul C/C++.

Python è un ottimo linguaggio: provalo.

Ad esempio alcuni manager di pacchetti sono scritti in Python, come pure alcuni installer (di distro).

Parlando d'altro, YouTube è realizzato quasi interamente in Python, e in Google viene spesso usato (uno dei loro più recenti progetti, Google App Engine, è scritto in Python e almeno supporta soltanto Python come linguaggio di sviluppo).

Originariamente inviato da khelidan1980

pygtk sono per python,ovviamente se non ti piace il linguaggio c'è poco da fare,io la vedo come una semplificazione notevole piuttosto che sviluppare in C,però si sa degustibus!

Concordo in toto.

Originariamente inviato da 71104

perché, Torvalds invece ne ha mai scritto uno???
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.

Ne avevamo parlato anche qui un po' di anni fa, e i motivi erano due: l'immaturità del g++ disponibile all'epoca, e l'incapacità di Torvalds di comprendere il C++ e usarlo, quindi, in maniera appropriata.

[-Slash]

Originariamente inviato da Pixel452

Grazie per le risposte.

apt-file funziona, non male, grazie.
Ho aggiunto le librerie libgnome-dev e libgsf-gnome-1-dev, inutilmente perchè gli header mancanti erano anche in librerie che avevo già. Quelle incluse in Anjuta sono già installate.

Magari domani provo Eclipse che mi sembra un attimino più famigliare al VS.
pygtk se non ho capito male si basa su phyton? Sinceramente non è che mi ispiri molto, a questo punto preferisco rimanere sul C/C++.
I Build-Essential da quello che ho visto servono solo in determinati casi.
Mi sa che i miei problemi sono dovuti ad anjuta più che a librerie mancanti, provo eclipse e vedo come va, visto che KDevelop non posso usarlo perchè sono su GNOME.

build-essential contiene gcc e g++, ossia i compilatori, quindi serve sempre

Originariamente inviato da 71104

perché, Torvalds invece ne ha mai scritto uno???
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.

Lo ha iniziato lui ed ancora oggi è sviluppatore attivo. Poi mi sembra abbastanza chiaro che un progetto di quelle dimensioni non lo puoi gestire da solo a meno che non sei superman. Avrà sicuramente incontrato programmatori piu bravi di lui che lo hanno aiutato, ma cio non toglie che un kernel di successo come linux non si crea solo con il culo.

Originariamente inviato da cdimauro

Pensi male, visto che il C++ è un SUPERSET del C, per cui puoi fare ALMENO le stesse cose del C, e... di più, se se ne sfruttano le caratteristiche peculari.

In soldoni: non c'è alcun motivo per preferire il C al C++.

Era ovvio che mi riferivo alla programmazione ad oggetti del c++. Volendo posso anche scrivere un programma di 5000 milioni di righe di codice in c, e poi lo compilo come cpp, come si fa in tutte le università all'inizio negli esami di fondamenti. Ma quello alla fine è sempre c

[arara]

A parte le sparate di Torvalds, siete veramente sicuri che non ci sia veramente un valido motivo per cui viene ancora usato il C?
In fondo torvalds non è che abbia scritto tutto sto gran codice, interi sottosistemi di Linux sono scritti/gestiti/mantenuti da altre aziende o programamtori. Difficile credere che siano tutti coglioni, visto che in ballo ci sono aziende come IBM, Intel, HP o Sun.
Ad esempio SELinux è stato scritto dalla NSA, lo stack wireless da un'azienda specializzata che lavora nel settore, Xen da XenSource, lo stack TCP/IP da Alan Cox (credo), etc

Un motivo potrebbe essere questo: Linux gira su decine di piatatforme e architetture diverse, dai dispositivi embemmed ai supercomputer alle grid di Playstation3. Forse viene ancora usato il C perche è il "minimo comun denominatore" tra tutte le varie e disparate architetture su cui Linux gira. Usando il C++ magari non potrebbero usarlo su tutte. Soprattutto considerando che un compilatore C++ è molto piu complesso di un compilatore C, non è detto che possa essere implementato su tutte le piattaforme. Linux ad esempio viene usato anche in sistemi micro embemmed, dove magari è disponibile solo il compilatore C.

E solo un'ipotesi, comunque qua c'è l'elenco delle architetture su cui è stato portato Linux che rende l'idea:

* Alpha architecture:
o DEC Alpha
o Samsung Alpha CPU
* Analog Devices
o Blackfin (since 2.6.22)
* Argonaut RISC Core (ARC) from ARC International
* ARM architecture:
o Acorn Archimedes and Risc PC series
o DEC StrongARM
o Marvell (formerly Intel) XScale
o Sharp Zaurus
o iPAQ
o Palm, Inc.'s Tungsten Handheld[1]
o Gamepark Holdings' GP2X
o Nokia 770 Internet Tablet
o Nokia N800
o Nokia N810
o gumstix
o Nintendo DS via DSlinux
o Sony Mylo
o Psion 5, 5MX, Series 7, netBook
o Some Models of Apple iPods (see iPodLinux)
o OpenMoko Neo1973
o Freescale's (formerly Motorola) i.MX multimedia processors
* Atmel AVR32
* Axis Communications' ETRAX CRIS
* Freescale 68k architecture (68020, 68030, 68040, 68060):
o Some Amigas: A1200, A2500, A3000, A4000
o Apple Macintosh II, LC, Quadra, Centris and early Performa series
o Sun Microsystems 3-series workstations (experimental, uses Sun-3 MMU)[citation needed]
* Fujitsu FR-V
* Hewlett-Packard's PA-RISC family
* H8 architecture from Renesas Technology, formerly Hitachi.
o H8/300
o H8/500
* IBM
o System/390 (31-bit)
o zSeries and System z9 mainframes (64-bit)
* Intel IA-64 Itanium, Itanium II
* x86 architecture:
o IBM PC compatibles using IA-32 and x86-64 processors:
+ Intel 80386, 80486, and their AMD, Cyrix, Texas Instruments and IBM variants
+ The entire Pentium series and its Celeron and Xeon variants
+ The Intel Core processors
+ AMD 5x86, K5, K6, Athlon (all 32-bit versions), Duron, Sempron
+ x86-64: 64-bit processor architecture, now officially known as AMD64 (AMD) or Intel64 (Intel); supported by the Athlon 64, Opteron and Intel Core 2 processors, among others
+ Cyrix 5x86, 6x86 (M1), 6x86MX and MediaGX (National/AMD Geode) series
+ VIA Technologies Eden (Samuel II), VIA C3, and VIA C7 processors
o Microsoft's Xbox (Pentium III processor), through the Xbox Linux project
o SGI Visual Workstation (Pentium II/III processor(s) with SGI chipset)
o Sun Microsystems Sun386i workstation (80386 and 80486)
o Support for 8086, 8088, 80186, 80188 and 80286 CPUs is under development (the ELKS fork)[2]
* M32R from Mitsubishi
* MIPS architecture:
o Infineon's Amazon & Danube Network Processors
o Jazz
o Cobalt Qube, Cobalt RaQ
o DECstation
o Godson (MIPS-like), Godson II, and Godson IIE from BLX IC Design Ltd (China)
o Some PlayStation 2 models, through the PS2 Linux project
o PlayStation Portable uClinux 2.4.19 port [1]
o Broadcom wireless chipsets
* NEC v850e[citation needed]
* OpenRISC open core processor series:
o Beyond Semiconductor OR1200
o Beyond Semiconductor OR1210
* Power Architecture:
o IBM Servers
* PowerPC architecture:
o IBM's Cell
o Most pre-Intel Apple computers (all PCI-based Power Macintoshes, limited support for the older NuBus Power Macs)
o Clones of the PCI Power Mac marketed by Power Computing, UMAX and Motorola
o Amigas upgraded with a "Power-UP" card (such as the Blizzard or CyberStorm)
o AmigaOne motherboard from Eyetech Group Ltd (UK)
o Samantha from Soft3 (Italy)
o Amy'05 PowerPC motherboard from Troika
o IBM RS/6000, iSeries and pSeries systems
o Pegasos I and II boards from Genesi
o Nintendo GameCube, through Nintendo GameCube Linux
o Project BlackDog from Realm Systems, Inc.
o Sony Playstation 3
o V-Dragon CPU from Culturecom.
o Virtex II Pro Field Programmable Array (FPGA) from Xilinx with PowerPC cores.
* SPARC
o SPARC (32-bit):
+ Sun-4/SPARCstation/SPARCserver series
o SPARC (64-bit):
+ Sun Ultra series
+ Sun Blade
+ Sun Fire
+ SPARC Enterprise systems based on the UltraSPARC T1 and UltraSPARC T2 processors
+ Clones made by the Tatung Company and others[citation needed]
* SuperH
o Sega Dreamcast (SuperH SH4)
o HP Jornada 680 through Jlime distribution (SuperH SH3)

[jappilas]

Originariamente inviato da 71104

perché, Torvalds invece ne ha mai scritto uno???
per la cronaca, ci hanno pure provato una volta a portare Linux in C++; non mi sono mai domandato perché abbiano desistito, adesso invece me lo sto domandando (massa di incompetenti? probabile, visto che la storia ci ha dimostrato la possibilità di scrivere un kernel in C++); domani farò una ricerca.

più che "massa di incompetenti" .... forse "massa eterogenea di programmatori ognuno con la propria visione della situazione e il proprio livello e campo di competenze e magari qualche paraocchi" è più appropriato

non ricordo bene quello che è successo sulla mailing list di linux, ricordo però alcuni episodi su quella di freebsd, tra cui quello riassunto e linkato qui, in cui si spaziava tra ( riassumendo)
- "sviluppando in C si possono ottenere gli stessi risultati senza perdere in prestazioni";
- le prestazioni del compilatore C++ rispetto a quello per il plain C
- "C++ è un linguaggio dalla complessità tropo elevata per il kernel"; da questo derivano a loro volta altre argomentazioni:
- - pochi degli attuali kernel developers, potrebbero continuare a contribuire in caso di migrazione ad un diverso linguaggio ;
- - il Runtime da integrare nel kernel necessario per supportare le feature del linguaggio sarebbe troppo:
- - - complesso ( oneroso per quanto concerne svilluppo e integrazione)
- - - ingombrante
- - - oneroso computazionalmente
- - in virtù anche di questo, piuttosto di usare un subset del linguaggio, "tanto vale usare il C" - o un linguaggio ad hoc (DSL) (vedi appunto la proposta di adottare K )

[cdimauro]

Originariamente inviato da -Slash

Era ovvio che mi riferivo alla programmazione ad oggetti del c++. Volendo posso anche scrivere un programma di 5000 milioni di righe di codice in c, e poi lo compilo come cpp, come si fa in tutte le università all'inizio negli esami di fondamenti. Ma quello alla fine è sempre c

E' ovvio che nemmeno tu conosci il C++, visto che C++ != programmazione a oggetti.

Originariamente inviato da arara

A parte le sparate di Torvalds, siete veramente sicuri che non ci sia veramente un valido motivo per cui viene ancora usato il C?
In fondo torvalds non è che abbia scritto tutto sto gran codice, interi sottosistemi di Linux sono scritti/gestiti/mantenuti da altre aziende o programamtori. Difficile credere che siano tutti coglioni, visto che in ballo ci sono aziende come IBM, Intel, HP o Sun.
Ad esempio SELinux è stato scritto dalla NSA, lo stack wireless da un'azienda specializzata che lavora nel settore, Xen da XenSource, lo stack TCP/IP da Alan Cox (credo), etc

Quelle aziende ci sono e investono semplicemente perché ne hanno un tornaconto.

Un motivo potrebbe essere questo: Linux gira su decine di piatatforme e architetture diverse, dai dispositivi embemmed ai supercomputer alle grid di Playstation3. Forse viene ancora usato il C perche è il "minimo comun denominatore" tra tutte le varie e disparate architetture su cui Linux gira. Usando il C++ magari non potrebbero usarlo su tutte. Soprattutto considerando che un compilatore C++ è molto piu complesso di un compilatore C, non è detto che possa essere implementato su tutte le piattaforme. Linux ad esempio viene usato anche in sistemi micro embemmed, dove magari è disponibile solo il compilatore C.

Linux fa uso di GCC come compilatore, e dov'è disponibile il GCC in genere è disponibile anche g++, che è sicuramente più complesso come compilatore, ma niente di eccezionale.

[k0nt3]

trovo abbastanza inutile discutere sulle scelte di Torvalds, alla fine conta il risultato

[cdimauro]

Trovo abbastanza inutile studiare: alla fine conta il risultato.

Torvalds non ha bisogno di avvocati, semplicemente perché è indifendibile.

L'unica cosa che dovrebbe fare per non attirarsi delle ovvie critiche è... tapparsi la bocca su cose di cui dimostra di non avere nemmeno conoscenze di base.

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/200...-in-linux.html

[71104]

Originariamente inviato da -Slash

Lo ha iniziato lui ed ancora oggi è sviluppatore attivo.

dannazione quanto rosico che non riesco a ritrovare quel messaggio dove lui descriveva il suo lavoro odierno...
mi credi sulla parola se ti dico che non è più sviluppatore attivo?

Avrà sicuramente incontrato programmatori piu bravi di lui che lo hanno aiutato,

non ci vuole molto

Poi mi sembra abbastanza chiaro che un progetto di quelle dimensioni non lo puoi gestire da solo a meno che non sei superman. Avrà sicuramente incontrato programmatori piu bravi di lui che lo hanno aiutato, ma cio non toglie che un kernel di successo come linux non si crea solo con il culo.

di tutte le panzane (in termini di codice) che Linus aveva scritto in quel kernel non c'è rimasto più ufficialmente nulla; se usassi Linux aggiungerei "per fortuna"

[Tommo]

Originariamente inviato da cdimauro

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/200...-in-linux.html

Veramente uno schifo ma... torvalds non è mai citato

[khelidan1980]

Originariamente inviato da 71104

dannazione quanto rosico che non riesco a ritrovare quel messaggio dove lui descriveva il suo lavoro odierno...
mi credi sulla parola se ti dico che non è più sviluppatore attivo?

Si questa ormai è cosa nota,comunque se cerchi in giro si trovano facilmente le percentuali di contributi dei vari dev

Tipo qui,si riferisce al kernel 2.6.20:

http://lwn.net/Articles/222773/

[cdimauro]

Originariamente inviato da Tommo

Veramente uno schifo ma... torvalds non è mai citato

Appunto. Invece di sparare cazzate su C & C++ avrebbe fatto meglio a occuparsi della situazione dell'audio di Linux.

[AnonimoVeneziano]

State mandando a ramengo un thread coi soliti discorsi che alla fine si arenano e dove tutti rimangono con le loro idee ...

[marco.r]

Originariamente inviato da cdimauro

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/200...-in-linux.html

Beh... criticare ALSA e' come sparare sulla croce rossa , non capisco perche' andare a complicarsi cosi' la vita... sotto FreeBSD sono anni che il mixing software in OSS viene fatto automaticamente, basta che due programmi aprano contemporaneamente il device della scheda... forse troppo facile ?

[k0nt3]

Originariamente inviato da cdimauro

Anzi, farebbe bene ad affinare le sue "doti" di design: http://insanecoding.blogspot.com/200...-in-linux.html

non ho mai visto tanta ignoranza in un singolo blog
affermare che quel minestrone di OSS è meglio di ALSA è veramente difficile. è anche ovvio che ALSA è nato per essere un backend e non un frontend, quindi non ha senso che sia portabile su altre piattaforme. directx lo è? se vuoi scrivere applicazioni che usano l'audio su linux usi gstreamer o phonon per dirne un paio e magicamente vedrai che il tuo codice diventa portabile (addirittura più di OSS visto che funzionano pure su windows e OSX )

[marco.r]

In che senso OSS e' un minestrone ? Visti i grattacapi che causa piu' probabile lo sia ALSA. Ogni volta che trovo HW audio nuovo c'e' qualcosa da sistemare... che sia il mixer che non va piuttosto che il volume che funziona solo sull'interfaccia OSS perche' su quella ALSA si azzera automaticamente. Certo usando distribuzioni come Ubuntu il piu' dei problemi si risolvono, ma solo perche' c'e' qualcuno che ci mette una pezza sopra.

[71104]

Originariamente inviato da khelidan1980

Si questa ormai è cosa nota,comunque se cerchi in giro si trovano facilmente le percentuali di contributi dei vari dev

Tipo qui,si riferisce al kernel 2.6.20:

http://lwn.net/Articles/222773/

ah però, non pensavo che Linus fosse così bravo a rimuovere il suo codice...
si vede che in fondo ha una coscienza

[AnonimoVeneziano]

linux rulez

[k0nt3]

Originariamente inviato da marco.r

In che senso OSS e' un minestrone ?

non c'è un'api unificata per la gestione in hardware del midi, del mixer e del full duplex, inoltre non è pensata per il multithreading. il che si traduce in minestrone di driver dove ognuno implementa le cose alla sua maniera.

Originariamente inviato da marco.r

Visti i grattacapi che causa piu' probabile lo sia ALSA. Ogni volta che trovo HW audio nuovo c'e' qualcosa da sistemare... che sia il mixer che non va piuttosto che il volume che funziona solo sull'interfaccia OSS perche' su quella ALSA si azzera automaticamente. Certo usando distribuzioni come Ubuntu il piu' dei problemi si risolvono, ma solo perche' c'e' qualcuno che ci mette una pezza sopra.

in realtà l'ultima volta che ho avuto problemi con l'audio su linux è stato quando c'era ancora il kernel 2.4 e quindi OSS (midi non funzionante, suoni che non potevano sovrapporsi, ritardati ecc...)
se la tua scheda audio ha problemi con alsa puoi usare l'emulazione OSS, ma è solo una pezza, non significa che la soluzione sia OSS in generale