Discussion :

[bruno_pages]

Les sources de QT 4.8.7 pour Linux sont accessibles sur Qt Downloads

Si le contexte et mes problèmes initiaux y compris mes états d'âme ne vous intéressent pas, passez directement au message suivant ... que j'écrirais demain, c'est à dire en fait l'année prochaine vu qu'on est le 31 décembre

Contexte

Parler de Qt4 peut sembler iconoclaste alors que Qt5 va lui aussi bientôt cessé d'être maintenu, mais je ne suis peut être pas le seul à avoir jeté l'éponge, fatigué de passer d'une version de QT à la suivante.

Lorsque j'ai commencé le développement de BoUML au début du millénaire en 2007, c'était sous Qt2, puis j'ai dû passé à Qt3, et ensuite à Qt4 (avec support Qt3) dans la douleur, et je me suis arrêté là quelque peu agacé par ces versions incompatibles les unes avec les autres. Même si les choses ne sont pas comparables, j'ai fait en sorte que toutes les versions de BoUML permettent de charger un modèle produit ou modifié avec n'importe qu'elle version antérieure, jusqu'au grand écart permettant à la version 11 faite en 2021 de lire un projet fait avec la version 1 de 2008 ! Et il en est de même au niveau de l'interface avec les plugs-outs, permettant à un vieux plug-out de fonctionner avec un BoUML plus récent.

L'abandon de Qt4 dans les distributions comme par exemple Debian 11 m’empêchait donc de produire BoUML dessus. Cependant il est par contre tout à fait possible d'exécuter sur une Debian 11 ou 12 la version de BoUML faite par exemple pour Debian 10 à partir du moment où on dispose aussi des librairies Qt utilisées, voir Comment utiliser BoUML 7.11 sous Debian à partir de Debian 11 Bullseye (amd64). Cela a aussi participé à ma décision d’arrêter le développement de BoUML, après 15 ans et 382 versions.

BoUML est sorti de ma vie, jusqu'à il y a quelques jours où une professeur de BTS enseignant UML pas très moi de chez moi m'a contacté, et finalement proposé de participer à un de ses cours. Pour ne pas être ridicule après une longue abstinence cumulé à un age de plus en plus avancé, il me parait utile de réutiliser BoUML afin de rafraîchir ma mémoire. Mais depuis plusieurs années ma station de travail est une Raspberry Pi, une Pi5 sous Debian Bookworm depuis peu de temps, et déjà avec ma Pi4 sous Debian Bullseye il était impossible de compiler BoUML.

J'avais bien fait sur une Pi 3 une archive pour utiliser BoUML à partir de Bullseye, mais celle-ci était en 32 bits, alors que ma Pi5 est en 64b.

J'ai donc voulu compiler Qt 4.8.7 sur ma Pi5 Bookworm 64b, en sachant que ce ne serait sans doute pas sans problèmes.

Tentatives

Le début est facile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
wget https://download.qt.io/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz
tar xf qt-everywhere-opensource-src-4.8.7.tar.gz
cd qt-everywhere-opensource-src-4.8.7
./configure

Puis bravement make -j3 et après quelque temps et une flopée de warnings, les premières erreurs de compilations assez bénignes dont je reparlerais.

Mais arrivé sous src/gui c'est la bérézina : les sources à compiler utilisent des noms de membres qui ne sont pas ceux présents dans les fichiers header

Après de vaines recherches je remarque que les headers sont produits par l'outil interne uic, pour avancer je vais sur ma vieille station en multi boot et compile Qt sous Ubuntu 16.04, afin de récupérer les fichiers produits, et il n'y en a pas seulement pour src/gui.

Je passe d'autres problèmes mineurs dont je reparlerais aussi, et j'arrive sous translations sous lequel rien ne va et un autre outil interne râle en disant que le format des fichiers est inconnu. Le but içi est de produire des fichiers qm à partir de fichiers ts.

Rebelote, pour avancer rapidement je récupère les fichiers produits sous Ubuntu.

Arrivé sous src/script il y a des erreurs liées à des définitions dans src/3rdparty/javascriptcore/JavaScriptCore/wtf/TypeTraits.h qui ne sont plus valables depuis C++11. Les résoudre demanderait beaucoup de modifications à différents endroits, et je n'ai pas besoin des scripts, je reconfigure en -no-script (-no-javascript-jit ne suffit pas), et finalement j'arrive à produire Qt

Après un make install je compile BoUML oh miracle sans problème, et je fais quelque tests d’exécution tout à fait concluants. De toute façon comme disait un ancien collègue : ça compile donc ça marche, n'est ce pas ?

Evidemment récupérer des fichiers produits ailleurs ce n'est pas très glorieux, et ne pas connaître la raison de ces deux problèmes majeurs est loin d'être rassurant. Je décide donc de commencer par le problème de production des fichiers de traduction qui semble plus simple, et je vais entrer dans les détails car c'est intéressant. Je fini par comprendre que le foreach de Qt ne va pas plus loin que le 1er élément, d'où le format inconnu car n'étant pas le 1er de la liste des formats définis. En remplaçant la définition de la boucle par une à moi le problème disparaît et les fichiers qm sont bien produits. Mais je veux comprendre pourquoi le foreach ne marche plus alors qu'il marchait avant.

QT défini foreach ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
template <typename T>
class QForeachContainer {
public:
   inline QForeachContainer(const T& t) : c(t), brk(0), i(c.begin()), e(c.end()) { }
   const T c;
   int brk;
   typename T::const_iterator i, e;
};
 
#define Q_FOREACH(variable, container) \
for (QForeachContainer<__typeof__(container)> _container_(container); \
     !_container_.brk && _container_.i != _container_.e; \
     __extension__ ({ ++_container_.brk; ++_container_.i; })) \
     for (variable = *_container_.i;; __extension__ ({--_container_.brk; break;}))
 
#define foreach Q_FOREACH

que j'avais remplacé par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
template <typename T, typename TI>
struct ForEachContainer {
  T c;
  TI it;
  TI e;
  bool brk;
  inline ForEachContainer(const T& t) : c(t), it(c.begin()), e(c.end()), brk(false) {}
};
 
#define Q_FOREACH(v, l) \
for (ForEachContainer<__typeof__(l), __typeof__((l).begin())> _container_(l); \
     _container_.it != _container_.e; \
     ++_container_.it, _container_.brk = false) \
  for (v = *_container_.it; !_container_.brk; _container_.brk = true)
 
#define foreach Q_FOREACH

Je ne connaissais pas la possibilité de faire un break en dehors du corps d'un for ou autre via __extension__, et je simplifie ma définition en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
template <typename T, typename TI>
struct ForEachContainer {
  T c;
  TI it;
  TI e;
  inline ForEachContainer(const T& t) : c(t), it(c.begin()), e(c.end()) {}
};
 
#define Q_FOREACH(v, l) \
for (ForEachContainer<__typeof__(l), __typeof__((l).begin())> _container_(l); \
     _container_.it != _container_.e; \
     ++_container_.it) \
  for (v = *_container_.it;; __extension__ ({break;}))
 
#define foreach Q_FOREACH

et là patatra j'ai le même comportement qu'avec le foreach de Qt

Pour en voir le cœur net j'utilise le tout petit programme suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#include <iostream>
 
int main()
{
  for (int i = 0; i != 5; ++i)
    for (int j = i;; __extension__ ({break;}))
      std::cout << j << std::endl;
}

Sur ma Pi5 cela n'affiche que 0, alors que sur mon Ubuntu 16.04 cela affiche de 0 à 4, et si je remplace le break par un continue sur la Pi 5 j'ai mes 0 à 4

Après avoir demandé de l'aide il s'avère que les vieilles versions de gcc étaient buggées et géraient mal un break/continue à cette position, car elles considéraient qu'il s'applique à la boucle interne et non la boucle englobante.

Le foreach de Qt ne marche donc plus à cause de la correction effectuée dans gcc

Je reviens à la définition de Qt en remplaçant le break par un continue et le tour est joué, la génération des fichiers sous translations se fait bien. A noter qu'il est possible de simplifier la définition de Qt, un peu comme j'ai simplifié la mienne, mais pour minimiser les changements dans le code de Qt je ne l'ai pas fait.

Des foreach il y en a évidemment ailleurs, et j'ai modifié un fichier header inclue un peu partout, je relance donc la compilation à partir du haut, et là deuxième effet kiss cool, mon 1er problème avec uic disparaît également

La suite avec l’ensemble des modifications à faire, et qui finalement sont peu nombreuses, dans le message suivant à venir.

[bruno_pages]

Comme expliqué précédemment je ne peux pas compiler la partie script dont je n'ai de toute façon pas besoin et qui utilise des définitions invalides depuis C++11, donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
wget https://download.qt.io/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz
cd qt-everywhere-opensource-src-4.8.7
./configure -no-script

Cependant les choix de configuration ne sont pas seulement liés aux options de configure, ils dépendant également de ce que vous avez ou non installé par ailleurs, ainsi que le la version de votre OS. Dans mon cas je suis donc sur une Pi5 64b sous l'OS recommandé Debian Bookworm, et la configuration affichée lors de l'exécution de configure -no-script est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Build .................. libs tools examples demos docs translations
Configuration ..........  release largefile stl precompile_header  minimal-config small-config medium-config large-config full-config qt3support accessibility opengl shared reduce_exports ipv6 clock-gettime clock-monotonic mremap getaddrinfo ipv6ifname getifaddrs inotify system-jpeg system-png png system-tiff system-freetype system-zlib iconv glib dbus x11sm xshape xsync xrender mitshm fontconfig xkb icu concurrent multimedia audio-backend svg release
Debug .................. no
Qt 3 compatibility ..... yes
QtDBus module .......... yes (run-time)
QtConcurrent code ...... yes
QtGui module ........... yes
QtScript module ........ no
QtScriptTools module ... no
QtXmlPatterns module ... no
Phonon module .......... no
Multimedia module ...... auto
SVG module ............. yes
WebKit module .......... no
Declarative module ..... no
Support for S60 ........ no
Symbian DEF files ...... no
STL support ............ yes
PCH support ............ yes
MMX/3DNOW/SSE/SSE2/SSE3. no/no/no/no/no
SSSE3/SSE4.1/SSE4.2..... no/no/no
AVX..................... no
Graphics System ........ default
IPv6 support ........... yes
IPv6 ifname support .... yes
getaddrinfo support .... yes
getifaddrs support ..... yes
Accessibility .......... yes
NIS support ............ no
CUPS support ........... no
Iconv support .......... yes
Glib support ........... yes
GStreamer support ...... no
PulseAudio support ..... no
Large File support ..... yes
GIF support ............ plugin
TIFF support ........... plugin (system)
JPEG support ........... plugin (system)
PNG support ............ yes (system)
MNG support ............ plugin (qt)
zlib support ........... system
Session management ..... yes
OpenGL support ......... yes (Desktop OpenGL)
OpenVG support ......... no
NAS sound support ...... no
XShape support ......... yes
XVideo support ......... no
XSync support .......... yes
Xinerama support ....... runtime
Xcursor support ........ runtime
Xfixes support ......... runtime
Xrandr support ......... runtime
Xrender support ........ yes
Xi support ............. runtime
MIT-SHM support ........ yes
FontConfig support ..... yes
XKB Support ............ yes
immodule support ....... yes
GTK theme support ...... no
SQLite support ......... plugin (qt)
OpenSSL support ........ no 
Alsa support ........... no
ICD support ............ no
libICU support ......... yes
Use system proxies ..... no

Une fois l'exécution de configure terminée j'ai fait les changements suivants liés aux évolutions de gcc qui n'est plus ce qu'il était du temps de Qt 4.8.7 :

Dans qt-everywhere-opensource-src-4.8.7/src/dbus/Makefile et qt-everywhere-opensource-src-4.8.7/src/plugins/accessible/widgets/Makefile j'ajoute l'option -fpermissive à la définition de CXXFLAGS

Dans qt-everywhere-opensource-src-4.8.7/src/plugins/accessible/widgets/itemviews.cpp je remplace la ligne 396 qui était

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

view()->selectionModel()->select(index, QItemSelectionModel::Columns & QItemSelectionModel::Deselect);

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

view()->selectionModel()->select(index, static_cast<QItemSelectionModel::SelectionFlags>(QItemSelectionModel::Columns & QItemSelectionModel::Deselect));

Dans qt-everywhere-opensource-src-4.8.7/tools/linguist/linguist/messagemodel.cpp ligne 186 je remplace 0 par ((MessageItem*)0) afin d'obtenir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (c->findMessage(m->text(), m->comment()) >= ((MessageItem*)0))

Dans qt-everywhere-opensource-src-4.8.7/src/corelib/global/qglobal.h ligne 2500 je remplace break par continue afin d'obtenir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for (variable = *_container_.i;; __extension__ ({--_container_.brk; continue;}))

Maintenant je peux compiler puis installer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
make -j3
sudo make install

et j'ai Qt 4.8.7 installé sous /usr/local/Trolltech/Qt-4.8.7 sans risque d’interaction avec une possible installation de Qt 5 ou 6.

Pour compiler BoUML j'ai juste à utiliser /usr/local/Trolltech/Qt-4.8.7/bin/qmake pour produire les Makefile qui utilisent QT 4.8.7
Je peux ainsi utiliser BoUML sur ma Pi5 64b comme si de rien n'était.

[unanonyme]

Bonjour,

N'est il pas possible de passer par un conteneur docker ou une VM pour produire le binaire ?
Voir, pour l'exécuter ?

Le second, la VM, risque de ne pas s'exécuter sur vos Pi car cela demande
beaucoup de ressources, mais le premier, le conteneur docker, ça se tente.

Quoi qu'il en soit, ça, c'est vraiment très intelligent,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for (int j = i;; __extension__ ({break;}))

Bonne journée.

[bruno_pages]

Bonjour,

N'est il pas possible de passer par un conteneur docker ou une VM pour produire le binaire ?
Voir, pour l'exécuter ?

Je n'ose pas non plus imaginer utiliser une machine virtuelle sur ma Pi, eu supposant que cela soit possible, malgré le fait que la Pi5 est vraiment performante.

Pour le docker j'avoue que je ne sais pas du tout.

Mais de toute façon pour moi rien ne vaut une utilisation native standard, sans tout un tralala me faisant perdre des ressources mémoire et CPU 'inutilement' car non pas pour ce que je veux faire au final, mais consommées par un intermédiaire que je devrais 'subir'.
J'ai commencé à programmer sur TI 59 avant de passer à un Goupil 3, malgré le fait que c'était déjà un ordi de folie avec une gigantesque mémoire d'une quarantaine de K (oui K, pas M ni G ) et un fabuleux 6809 à 1 ou 2 Mhz (oui M, pas G, et pas plusieurs CPUs ni cœurs ) j'ai toujours été radin dans l'utilisation des ressources. Les ressources ne sont pas destinées à êtres gâchées par les programmeurs, mais laissées à disposition des utilisateurs. Bien sûr ce mode de pensée est un peu d'un autre temps

[unanonyme]

Bonjour,

C'est bien aussi de penser comme vous le faites.

Disons que Docker permet de donner une longévité plus grande à l'artefact
en cela que puisque tout est figé,
il ne nécessite plus de ressources additionnelles
en cas de pépin avec l'environnement de production.

Hors vous nous en faites la démonstration avec GCC qui
doit corriger des inventions obscures de syntaxe surprenante
qui nécessite d'être très intelligent pour être manipulées.

Je n'ai pas connu ces antiquités, mais j'eus aimé,
c'est très formateur.

L'un dans l'autre,
tant que ça fonctionne dans l'immédiat c'est l'essentiel,
je ne faisais que des suggestions.

Ingénues mais pas dénuées de raisons, seulement,
je n'ai pas trouvé d'environnement de compilation pour QT4.

Une paire de ressources parmi tant d'autres,
https://github.com/fffaraz/docker-qt
https://www.docker.com/blog/compilin...ulti-platform/

Bonne journée.

[bruno_pages]

J'aurais dû le mentionner avant : pour compiler pour une autre version de l'OS que celui installé il y a bien-sûr pbuilder, et c'est celui-ci que j'utilisais pour produire BoUML à la chaîne pour les différentes versions d'Ubuntu en 32 bits et 64 bits à partir d'une unique Ubuntu 64 bits, et pareil pour Debian.
Mais pour cela il faut bien-sûr que la distribution cible soit encore distribuée afin que les binaires et librairies nécessaires puissent être téléchargés pendant l'opération.