[c++] programmi compilati e dll

[Q_Q]

Ciao a tutti.
Quando compilo un programma con delphi funziona su ogni pc che ho in casa (xp/vista/win7), con dev-c++ (mingw) o netbeans(cygwin) mi chiede delle dll sugli altri pc... E` una cosa normale e vanno allegate al programma o sbaglio nel compilare ?

[fero86]

di certo non é normale che usi Delphi per compilare programmi C++ :D
che DLL chiede? MSVCRT?

[Q_Q]

lulz con delphi compilo la roba scritta con delphi non c++ :D
cmq uno vuole libgcc_s_dw_2-1.dll e l'altro cygwin1.dll ( anche con solo una main con cout << "ciao" )

[tomminno]

Se non compili il codice staticamente hai bisogno del runtime del compilatore (oltre che di tutte le eventuali librerie utilizzate nel codice) per eseguire il programma.
In caso di compilazione statica invece hai 1 unico eseguibile un pò grossotto. Come se nell'era dei Tera un eseguibile di 5Mb possa essere un problema...

[DanieleC88]

Come se nell'era dei Tera un eseguibile di 5Mb possa essere un problema...

Centinaia di eseguibili linkati staticamente lo sono. :O
E devi ricompilare e ridistribuire tutto ad ogni aggiornamento delle dipendenze, e non condividi il codice in memoria con altre applicazioni, etc.

[Q_Q]

ecco mancava -static nel linker :stordita:
tnx :D

[tomminno]

Centinaia di eseguibili linkati staticamente lo sono. :O
E devi ricompilare e ridistribuire tutto ad ogni aggiornamento delle dipendenze, e non condividi il codice in memoria con altre applicazioni, etc.

Perchè ti pare che nel mondo reale ci sia qualcuno che condivide con altri programmi le versioni delle librerie? Se non sono fornite con il sistema ognuno ha le proprie, anche per motivi di versione.
Ti faccio un esempio: secondo te sqlite fornito con firefox con quanti altri applicativi sarà condiviso? Nessuno. Nemmeno con thunderbird.
Quanti software condividono OpenSSL? Nessuno, ognuno ha la propria versione.
Quanti condividono Qt? Nessuno, ognuno ha la propria versione.

Alla fin fine non hai centinaia di programmi linkati staticamente, ma centinaia di programmi che caricano dll quasi uguali.

[DanieleC88]

Probabilmente in un contesto come quello Windows dove non ci sono "gestori di pacchetti di sistema" e risoluzione di dipendenze di vario tipo, ogni progetto tende a distribuire il suo eseguibile con tutte le dipendenze del caso. Ma non mi sembra una pratica molto buona quella di compilare staticamente: se una dipendenza (che normalmente forniresti come DLL) subisce un aggiornamento per motivi di sicurezza o risoluzione di bug di altro tipo, tu che fai, ridistribuisci l'intero eseguibile linkato staticamente anche alle altre (n-1) dipendenze? Sempre meglio avere una DLL di sistema, dove aggiorni quella e stai a posto per tutti i programmi presenti nel tuo sistema.
Oltretutto, se tu usi Qt staticamente, se io uso Qt staticamente, se lui usa Qt staticamente, allora abbiamo almeno 3 copie di Qt che letteralmente buttano al cesso spazio su disco non necessario (che poi ok, probabilmente ha un costo bassissimo, ma ha un costo).
E via dicendo, insomma...

Mi sembra che gli svantaggi di usare le DLL siano minori dei vantaggi. Poi ognuno fa come vuole. :)
ciao ;)

[tomminno]

Probabilmente in un contesto come quello Windows dove non ci sono "gestori di pacchetti di sistema" e risoluzione di dipendenze di vario tipo, ogni progetto tende a distribuire il suo eseguibile con tutte le dipendenze del caso. Ma non mi sembra una pratica molto buona quella di compilare staticamente: se una dipendenza (che normalmente forniresti come DLL) subisce un aggiornamento per motivi di sicurezza o risoluzione di bug di altro tipo, tu che fai, ridistribuisci l'intero eseguibile linkato staticamente anche alle altre (n-1) dipendenze?


Non essendo un file di sistema per cui l'aggiornamento te lo becchi e basta, è buona norma rieseguire i test e ripubblicare il pacchetto e non affidarsi ciecamente a quello che altri potrebbero aver fatto.


Sempre meglio avere una DLL di sistema, dove aggiorni quella e stai a posto per tutti i programmi presenti nel tuo sistema.


Appunto io sto parlando per dll non di sistema.
Pensa un caso: io sviluppo un software con il CRT di Visual Studio 2008, poi l'utente o un software mi installa il runtime di VS2010, possono nascere delle belle sorprese (vedi safari più avanti).


Oltretutto, se tu usi Qt staticamente, se io uso Qt staticamente, se lui usa Qt staticamente, allora abbiamo almeno 3 copie di Qt che letteralmente buttano al cesso spazio su disco non necessario (che poi ok, probabilmente ha un costo bassissimo, ma ha un costo).
E via dicendo, insomma...


Quello che facevo notare è che anche in caso di link dinamico la condizione è esattamente la stessa:
Ho VLC, Google Earth e 2 Qt Creator, ognuno ha la sua brava copia delle Qt.
Che vantaggio c'è stato con il link dinamico?


Mi sembra che gli svantaggi di usare le DLL siano minori dei vantaggi. Poi ognuno fa come vuole. :)
ciao ;)

Io invece li trovo maggiori in quanto il software è più in balia della configurazione della singola macchina (spero siano finiti i tempi in cui tutti mettevano le proprie dll in system32).
Per farti un esempio: a me che ho tutti i Visual Studio installati dalla 6 alla 2010 con relativi runtime, Safari non funziona (ma non funzionava nemmeno quando non avevo ancora VS2010), manda una sequenza infinita di errori di errata inizializzazione del runtime di visual studio e la finestra rimane bianca.
E stiamo parlando di Safari non dell'ultimo software uscito dalle mani dell'ultimo programmatore sulla faccia della terra.
Anche VLC quando parte integrato nel browser mi mostra lo stesso errore, anche se poi funziona regolarmente.

In ogni caso anche con link dinamico ovviamente nessuna condivisione delle librerie, solo copie "private". Ti ritrovi sempre e comunque con il fatto di dover ritestare il software con la versione aggiornata della dipendenza e comunque a dover fornire un pacchetto di installazione. Non vedo nessuna differenza pratica.

[DanieleC88]

Secondo me la fai troppo tragica: per fare un esempio, nel mio sistema ho installato almeno un paio di programmi Qt, nel caso specifico PokerTH e MiniTube.
Vediamo che libreria usano:
[jmc@gorgoroth ~]$ ldd `which minitube`
[...]
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb6dc1000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb6a3f000)
[jmc@gorgoroth ~]$ ldd `which pokerth`
[...]
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb6a48000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb67db000)
come vedi usano la stessa versione di Qt, e non ne soffrono: ad ogni aggiornamento di Qt continuano a funzionare benissimo. Questo mi consente di risparmiare spazio su disco (che qua non va nell'ordine dei terabyte, purtroppo). Che poi, Qt "ancora ancora", ma se era una cosa tipo Boost il peso si sentiva eccome, fidati.

Il problema del "DLL hell" che sta sul tuo PC mi sembra dovuto al fatto che hai installato versioni di Visual Studio antidiluviane parallelamente a quelle "moderne". Io non ho problemi, visto che tutti i software sul mio PC usano Qt4... Se dovessi distribuire oggi un software che usa Qt2 (inspiegabilmente), allora evidentemente lo linkerei staticamente per non inzozzare il sistema o causare conflitti di quel tipo.

Come se non bastasse, il fatto di usare librerie linkate dinamicamente viene particolarmente utile quando il sistema operativo usa una forma di segmentazione della memoria che consente il riutilizzo dello stesso segmento di codice in memoria RAM (che quella non va nell'ordine dei terabyte) per tutti i processi che ne faranno uso. Tutti i moderni sistemi operativi lo fanno, come conferma anche questo articolo (http://www.linuxquestions.org/linux/articles/Technical/Understanding_memory_usage_on_Linux) nel caso di Linux:

Most major programs on Linux use shared libraries to facilitate certain functionality. For example, a KDE text editing program will use several KDE shared libraries (to allow for interaction with other KDE components), several X libraries (to allow it to display images and copy and pasting), and several general system libraries (to allow it to perform basic
operations). Many of these shared libraries, especially commonly used ones like libc, are used by many of the programs running on a Linux system. Due to this sharing, Linux is able to use a great trick: it will load a single copy of the shared libraries into memory and use that one copy for every program that references it.

A me sembra un ottimo motivo per farne uso.
ciao ;)

[tomminno]

Secondo me la fai troppo tragica: per fare un esempio, nel mio sistema ho installato almeno un paio di programmi Qt, nel caso specifico PokerTH e MiniTube.


Già su linux. Su windows dove ogni programma ha la propria copia locale...


Vediamo che libreria usano:
[jmc@gorgoroth ~]$ ldd `which minitube`
[...]
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb6dc1000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb6a3f000)
[jmc@gorgoroth ~]$ ldd `which pokerth`
[...]
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb6a48000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb67db000)
come vedi usano la stessa versione di Qt, e non ne soffrono: ad ogni aggiornamento di Qt continuano a funzionare benissimo. Questo mi consente di risparmiare spazio su disco (che qua non va nell'ordine dei terabyte, purtroppo). Che poi, Qt "ancora ancora", ma se era una cosa tipo Boost il peso si sentiva eccome, fidati.


Il problema nel caso di linux nascerebbe nel momento in cui un aggiornamento delle qt inserisse un'incompatiblità con il passato, non necessariamente a livello di interfaccia ma anche solo a livello di comportamento, il tuo software smetterebbe di funzionare senza un motivo evidente.


Il problema del "DLL hell" che sta sul tuo PC mi sembra dovuto al fatto che hai installato versioni di Visual Studio antidiluviane parallelamente a quelle "moderne".


Il dll hell ce l'hai anche su linux, la convenzione del nome non ti mette al riparo dal problema. libQtCore.so.4 è qt 4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7 ?
In ogni caso l'installazione di più visual studio contemporaneamente non comporta nessun problema, tant'è che ho altre decine di software che funzionano senza problemi tra cui anche VLC stesso non utilizzato come addin del browser, e i miei.
Se Safari è fatto male non è colpa mia, sta di fatto che quel programma non funziona a causa della mia "particolare" configurazione. Con un link statico non sarebbe successo.


Io non ho problemi, visto che tutti i software sul mio PC usano Qt4... Se dovessi distribuire oggi un software che usa Qt2 (inspiegabilmente), allora evidentemente lo linkerei staticamente per non inzozzare il sistema o causare conflitti di quel tipo.


Ci sono 6 e tra poco 7 versioni di Qt4, ci sono un bel pò di cambiamenti tra la prima e l'ultima release senza bisogno di tornare all'età della pietra.


A me sembra un ottimo motivo per farne uso.
ciao ;)

Su linux specialmente con le infinite possibilità a cui vai incontro, se devi rilasciare un software buono per tutte le stagioni una pensatina al link statico ce la faccio sempre. Sai quante volte su linux non funziona qualcosa perchè c'è conflitto di versioni nelle dll... Ad esempio Trac e PHP sul mio NAS, non funzionano perchè ognuno usa una versione di Sqlite differente e vanno in conflitto, devo trovare il tempo e la pazienza di cross compilare PHP con una versione più recente di Sqlite (anzi no esattamente la stessa usata in Trac, la più recente rappresenta già una terza versione).

Vanno tanto di moda i linguaggi gestiti che utilizzano una quantità abnorme di memoria e mi vieni a fare le pulci su quel poco di memoria in più che potrebbe utilizzare un normale applicativo con il link statico?
Se dovessi avere a che fare con un software decisamente oneroso dal punto di vista delle risorse sicuramente userei il linking dinamico, ma con un applicativo normale che di suo più di 20 o 30 mega non occupa non sto nemmeno a pormi il problema e cerco la tranquillità.

[DanieleC88]

Già su linux. Su windows dove ogni programma ha la propria copia locale...
Già. :)
Il problema nel caso di linux nascerebbe nel momento in cui un aggiornamento delle qt inserisse un'incompatiblità con il passato, non necessariamente a livello di interfaccia ma anche solo a livello di comportamento, il tuo software smetterebbe di funzionare senza un motivo evidente.
Smetterebbe: ma non lo fa. Quali regressioni hai incontrato nei rilasci di Qt che hanno reso non funzionante il software che utilizzava la libreria condivisa? Io personalmente non ne ho incontrato.
Il dll hell ce l'hai anche su linux, la convenzione del nome non ti mette al riparo dal problema. libQtCore.so.4 è qt 4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7?
Certo, può esserci ovunque, non era ciò che intendevo dire: rileggi il post.
Comunque, Qt 4.6.3:
[jmc@gorgoroth ~]$ ls -lh /usr/lib/libQtCore.so*
lrwxrwxrwx 1 root root 18 8 giu 13.56 /usr/lib/libQtCore.so.4 -> libQtCore.so.4.6.3
lrwxrwxrwx 1 root root 18 8 giu 13.56 /usr/lib/libQtCore.so.4.6 -> libQtCore.so.4.6.3
-rwxr-xr-x 1 root root 2,5M 8 giu 13.57 /usr/lib/libQtCore.so.4.6.3
(ed è anche l'unica, per cui nessun "hell".)
In ogni caso l'installazione di più visual studio contemporaneamente non comporta nessun problema, tant'è che ho altre decine di software che funzionano senza problemi tra cui anche VLC stesso non utilizzato come addin del browser, e i miei.
Se Safari è fatto male non è colpa mia, sta di fatto che quel programma non funziona a causa della mia "particolare" configurazione. Con un link statico non sarebbe successo.
Scrivi una mail a Steve Jobs, ho visto che ultimamente si prende la briga di rispondere di persona: magari lo convinci. :)
Ci sono 6 e tra poco 7 versioni di Qt4, ci sono un bel pò di cambiamenti tra la prima e l'ultima release senza bisogno di tornare all'età della pietra.
Di quali regressioni (o gravi incompatibilità) nello specifico stai parlando?
Su linux specialmente con le infinite possibilità a cui vai incontro, se devi rilasciare un software buono per tutte le stagioni una pensatina al link statico ce la faccio sempre. Sai quante volte su linux non funziona qualcosa perchè c'è conflitto di versioni nelle dll... Ad esempio Trac e PHP sul mio NAS, non funzionano perchè ognuno usa una versione di Sqlite differente e vanno in conflitto, devo trovare il tempo e la pazienza di cross compilare PHP con una versione più recente di Sqlite (anzi no esattamente la stessa usata in Trac, la più recente rappresenta già una terza versione).
La tua allora deve essere sfiga, io non ricompilo niente dall'epoca in cui mi feci la prima installazione di una Mandrake 8.0. :D
Vanno tanto di moda i linguaggi gestiti che utilizzano una quantità abnorme di memoria e mi vieni a fare le pulci su quel poco di memoria in più che potrebbe utilizzare un normale applicativo con il link statico?
Questo è un discorso completamente separato e inserito ad capocchiam: la quasi totalità di questi linguaggi gestiti si tirano dietro un interprete ed un framework molto pesanti, ma che gravano solo sul primo software che li usa. (Poi possono essere condivisi.)

Se dovessi avere a che fare con un software decisamente oneroso dal punto di vista delle risorse sicuramente userei il linking dinamico, ma con un applicativo normale che di suo più di 20 o 30 mega non occupa non sto nemmeno a pormi il problema e cerco la tranquillità.
Appunto, tu fai come vuoi, nessuno ti sta obbligando.

ciao ;)

[Albi89]

Già su linux. Su windows dove ogni programma ha la propria copia locale...

Mica vero, sul mio sistema Win ho nel path le directory delle librerie "importanti" (tipo Qt o SDL), e molte altre DLLs sono già nelle directory di sistema di Windows (automaticamente ricercate).
Non sarà un sistema raffinato come quello di Linux, ma va egregiamente: basta non avere copie delle DLLs nelle directory da cui faccio partire i programmi per poter usare la copia comune. Alla faccia della pulizia ;)

Il problema nel caso di linux nascerebbe nel momento in cui un aggiornamento delle qt inserisse un'incompatiblità con il passato, non necessariamente a livello di interfaccia ma anche solo a livello di comportamento, il tuo software smetterebbe di funzionare senza un motivo evidente.

All'interno della stessa Major Release è priorità dei progettisti mantenere un comportamento consono all'interfaccia; in generale, un prodotto ben progettato può tranquillamente rimanere fedele alla sua interfaccia anche a cavallo di due release principali, modificando solo i comportamenti interni e ovviamente aggiungendo funzionalità.
Nulla vieta, però, in caso contrario, di installare due major (es. Qt 3 e Qt 4) per garantire la retrocompatibilità: sarebbero sempre solo 2 librerie invece di n.
Il caso estremo di librerie il cui comportamento (o l'interfaccia) cambiano vistosamente tra sottoversioni penso sia abbastanza trascurabile: se un progetto si basa su una libreria simile, evidentemente si basa su una framework mal sviluppato. Comunque non mi vengono in mente esempi di questo caso.

Il dll hell ce l'hai anche su linux, la convenzione del nome non ti mette al riparo dal problema. libQtCore.so.4 è qt 4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7 ?

A mio parere invece il DLL Hell in Linux è ridottissimo (io non ho mai avuto problemi). In Windows è sicuramente più complesso da gestire, ma si può evitare 1) se gli sviluppatori usano un naming consistente per le versioni successive: in questo modo posso aggiungerle entrambe al path e amen (Qt lo fa, per rimanere nell'esempio) 2) se gli sviluppatori non sono stati consistenti, mantenendo copie nelle directory solo per librerie obsolete (in questo caso ho un esempio: Matlab installa una versione di zlib incompatibile con l'emulatore ZSnes: ho dovuto inserire nella sua cartella una versione compatibile - entrambe avevano lo stesso nome! -).

In ogni caso l'installazione di più visual studio contemporaneamente non comporta nessun problema, tant'è che ho altre decine di software che funzionano senza problemi tra cui anche VLC stesso non utilizzato come addin del browser, e i miei.
Se Safari è fatto male non è colpa mia, sta di fatto che quel programma non funziona a causa della mia "particolare" configurazione. Con un link statico non sarebbe successo.

Qui brancolo nel buio e non so cosa risponderti. Non ho mai utilizzato contemporaneamente più di una versione di VS, ma nel dubbio ti do ragione, quello che dici mi sembra verosimile.

Ci sono 6 e tra poco 7 versioni di Qt4, ci sono un bel pò di cambiamenti tra la prima e l'ultima release senza bisogno di tornare all'età della pietra.

Vero, ma è un dramma di qualsiasi tecnologia legacy. Ammesso che esista il margine per conflitti (naming non consistente), c'è da dire che non conosco software indispensabile basato su versioni obsolete di Qt. E, per quanto obsolete, il loro uso andrebbe semplicemente evitato e il software che le usa aggiornato o lasciato perire. Usando le versioni recenti non c'è rischio di conflitti.

Su linux specialmente con le infinite possibilità a cui vai incontro, se devi rilasciare un software buono per tutte le stagioni una pensatina al link statico ce la faccio sempre. Sai quante volte su linux non funziona qualcosa perchè c'è conflitto di versioni nelle dll...

E col "farci un pensierino" sono anche d'accordo. D'altra parte sono scelte, perché non si dovrebbero valutare tutte e fare i pro e i contro? Di sicuro sotto Linux non ho mai pensato di compilare staticamente: grazie ai gestori di pacchetti non ci vuole niente a risolvere rapidamente le dipendenze (e il 90% delle librerie di uso comune sono preinstallate in tutte le distro).
Viceversa a volte valuto l'idea in Windows: se voglio ridistribuire un piccolo programma, posso distribuire un semplice eseguibile e non una cartella "inscindibile" (nel caso che l'utente non abbia le dipendenze installate).

Vanno tanto di moda i linguaggi gestiti che utilizzano una quantità abnorme di memoria e mi vieni a fare le pulci su quel poco di memoria in più che potrebbe utilizzare un normale applicativo con il link statico?
Se dovessi avere a che fare con un software decisamente oneroso dal punto di vista delle risorse sicuramente userei il linking dinamico, ma con un applicativo normale che di suo più di 20 o 30 mega non occupa non sto nemmeno a pormi il problema e cerco la tranquillità.

Io invece non la vedo così... i linguaggi gestiti hanno l'obiettivo di incrementare l'ordine (ordine del codice, ordine mentale di chi scrive...) così come l'utilizzo di linking dinamico (ordine delle versioni installate, ma anche sicurezza di aggiornamento continuo delle dipendenze di un certo software).
La trovo una soluzione naturale in Linux, artefatta in Windows (per via della necessità di "spulciare" librerie ridondanti nelle cartelle dei software) ma nel complesso solitamente conveniente.

[tomminno]

Smetterebbe: ma non lo fa. Quali regressioni hai incontrato nei rilasci di Qt che hanno reso non funzionante il software che utilizzava la libreria condivisa? Io personalmente non ne ho incontrato.


Questi ad esempio:
http://labs.trolltech.com/blogs/2009/11/12/bc-break-in-46-against-previous-46/
https://bugzilla.redhat.com/show_bug.cgi?id=487075


Certo, può esserci ovunque, non era ciò che intendevo dire: rileggi il post.
Comunque, Qt 4.6.3:
[jmc@gorgoroth ~]$ ls -lh /usr/lib/libQtCore.so*
lrwxrwxrwx 1 root root 18 8 giu 13.56 /usr/lib/libQtCore.so.4 -> libQtCore.so.4.6.3
lrwxrwxrwx 1 root root 18 8 giu 13.56 /usr/lib/libQtCore.so.4.6 -> libQtCore.so.4.6.3
-rwxr-xr-x 1 root root 2,5M 8 giu 13.57 /usr/lib/libQtCore.so.4.6.3
(ed è anche l'unica, per cui nessun "hell".)


Sempre nel tuo caso, io ho diverse versioni di qt 4.5.3,4.6.2, 4.6.3, 4.7 magari a qualche software potrebbe dare fastidio.


Scrivi una mail a Steve Jobs, ho visto che ultimamente si prende la briga di rispondere di persona: magari lo convinci. :)


Per quanto possa interessarmi, ne faccio volentieri a meno di Safari.


Di quali regressioni (o gravi incompatibilità) nello specifico stai parlando?


Non necessariamente di Qt, ma in generale di tutte le librerie che cambiano dal giorno alla notte e che portano a perdere più tempo a ricompilare che altro (o ad abbandonare l'utilizzo del software e a cercare un'alternativa).


La tua allora deve essere sfiga, io non ricompilo niente dall'epoca in cui mi feci la prima installazione di una Mandrake 8.0. :D


Non è sfiga è una casistica.


Questo è un discorso completamente separato e inserito ad capocchiam: la quasi totalità di questi linguaggi gestiti si tirano dietro un interprete ed un framework molto pesanti, ma che gravano solo sul primo software che li usa. (Poi possono essere condivisi.)


Sarà ma se apro 2 istanze di Netbeans non mi occupano meno ram rispetto alla somma dei 2 applicativi lanciati uno alla volta.
Lo stesso vale per 2 versioni o istanze di Visual Studio.
Evidentemente le parti a comune sono veramente minimali.


Appunto, tu fai come vuoi, nessuno ti sta obbligando.

ciao ;)

Io ne facevo solo una questione di stabilità dell'applicativo al variare della moltitudine di configurazioni in cui può imbattersi, oltre al leggero guadagno in pure performance :)

[DanieleC88]

Questi ad esempio:
http://labs.trolltech.com/blogs/2009/11/12/bc-break-in-46-against-previous-46/
https://bugzilla.redhat.com/show_bug.cgi?id=487075
Il primo link riguarda una versione all'epoca ancora non stabile di un nuovo ramo di Qt (quello stabile era il 4.5, che come dice anche il blogger non viene intaccato minimamente).
Il secondo link fa solo da prova che ridistribuire unicamente libreria corregge il bug completamente, su tutto il sistema: se tu avessi linkato staticamente la libreria rotta? :p

Sempre nel tuo caso, io ho diverse versioni di qt 4.5.3,4.6.2, 4.6.3, 4.7 magari a qualche software potrebbe dare fastidio.
Difficile: se ci sono tutte quelle versioni evidentemente hai software che dipende da diverse minor o micro version della libreria, e trovandola presente sul sistema funzioneranno senza problemi.

Per quanto possa interessarmi, ne faccio volentieri a meno di Safari.
Allora il problema non si pone. :D

Non necessariamente di Qt, ma in generale di tutte le librerie che cambiano dal giorno alla notte e che portano a perdere più tempo a ricompilare che altro (o ad abbandonare l'utilizzo del software e a cercare un'alternativa).
Se introducono continuamente cambiamenti che stravolgono API e linking dinamico, magari sono state una scelta infelice. :fagiano:

Sarà ma se apro 2 istanze di Netbeans non mi occupano meno ram rispetto alla somma dei 2 applicativi lanciati uno alla volta.
Lo stesso vale per 2 versioni o istanze di Visual Studio.
Evidentemente le parti a comune sono veramente minimali.
Be' la sezione del codice eseguibile rimane la stessa, ma ognuno deve avere un proprio heap, un proprio stack, etc... A quello non puoi porre rimedio, non ha a che fare con il linking statico o dinamico.
Confronta due istanze di programmi che usano linking dinamico e due programmi che usano linking statico. :)

ciao ;)