Compilation sous Linux Mint en échec

Bonjour tout le monde,

Jusqu’à présent j’utilise ART en le lançant par un terminal dans le dossier où j’ai enregistré ma version ART-1.24.5-linux64, comme expliqué dans le Tuto de Carafife “News ART #6, installez ART autrement” https://www.youtube.com/watch?v=o_F_19muiVw

Lancement_ART_Terminal

Après avoir noté quelques instabilités de ART de la manière dont je l’utilise, je me suis dit que j’allais devoir compiler, ce que je redoutais car je n’y connais rien !

J’ai alors suivi le Tuto de Carafife “News ART #3, compilez et participez” https://www.youtube.com/watch?v=6ZLxpFH_jNI

J’ai bien installé les librairies, et exactement ceci, comme dans le tuto :
sudo apt install build-essential cmake curl git libcanberra-gtk3-dev libexiv2-dev libexpat-dev libfftw3-dev libglibmm-2.4-dev libgtk-3-dev libgtkmm-3.0-dev libiptcdata0-dev libjpeg-dev liblcms2-dev libpng-dev librsvg2-dev libsigc+±2.0-dev libtiff5-dev zlib1g-dev

Puis je suis allé chercher et ouvrir le script build-art ici Bitbucket dont j’ai copié/collé le texte dans un fichier texte que j’ai donc appellé “build-art” et que j’ai enregistré dans mon dossier “Programmes”

Ensuite j’ai rendu ce fichier exécutable et l’ai lancé en ouvrant un terminal et en y tappant “./build-art”.
Et voici le message final :

Et là, mes bien maigres connaissances en Linux ne me permettent pas de savoir quoi faire => pourriez-vous m’aider s’il vous plait ?

Première chose à faire : regarder ce qui est écrit dans les 2 fichiers .log, il devrait y avait des infos sur là où ça bloque. Car là on n’a pas assez d’infos.

Autre information : il vaut mieux aller sur GitHub qui est l’entrepôt officiel d’ART depuis un certain.

Bonsoir

Selon mon expérience personnelle la première compilation d’ART est un peu plus complexe que le simple lancement du script d’installation. En revanche une fois la première compilation faite la mise à jour peut s’opéré par deux ligne de commande

cd ~/programs/code-art/tools
./build-art

La méthode décrite sur ce fil me parait plus adaptée

D’autant plus que Je viens de compiler la dernière version d’ART sous linux mint (22.2 Zara) avec le script Bitbucket et tout s’est bien passée (pas de problème de dépendances)

Version: c1617ec44
Branch: master
Commit: c1617ec44
Commit date: 2025-09-10
Compiler: cc 13.3.0
Processor: x86_64
System: Linux
Bit depth: 64
Gtkmm: 3.24.9
Lensfun: 0.3.4.0
Exiv2: 0.27.6
LCMS2: 2.14
LibRaw: N/A
OpenColorIO: N/A
CTL interpreter: N/A
Build type: release
Build flags: -std=c++11 -ffp-contract=off -march=native -Werror=unused-label -fno-math-errno -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags: -march=native
OpenMP support: ON
Mi-malloc: V2.1
Build OS: Linux
Build date: 2025-09-11T17:49:10Z

En plus cela à permis de résoudre un petit écueil à l’utilisation des RAW provenant d’un boitier Nikon (j’ai un Z6) sur lequel l’on à activé le D-Lighting: " Un cas particulier pour les boitiers Nikon, le Raw est sous exposé par rapport au JPG si on a mis le D Lightning sur le boitier. L’exposition est correcte sur le logiciel propriétaire de Nikon (NX-Studio) mais comme tous les autres logiciels ne savent pas « lire » le D Lightning , le Raw est sous exposé"

PS le fil de discussion contient des bonus comme la création d’un îcône pour l’application

Pour une première installation par compilation, il faudrait aussi préciser que OpenColorIO (OCIO) ainsi que l’interpréteur CTL et ses dépendances (imath et openexr). Ce n’est pas nécessaire pour ART de base, mais nécessaire pour pouvoir utiliser les CTL et le support de certain types de fichiers supplémentaires.

Bonjour,

J’ai recommencé selon la méthode transmise par @alain_gre, et malheureusement cela bloque au même endroit :
=> au niveau des fichiers .log
=> mais il y a aussi une notification sur le package mimallocConfig.cmake !
Le système me demande d’installer la library mimalloc ; mi-malloc: mi-malloc
=> est-ce normal ? (microsoft ?)

Voici le texte du terminal après lancement de ./build-art :


linds@linds-photo95-pc:~/programs/tools$ ./build-art

Program name: art
Build type: release
Build without updating: false
Checkout:
Install primary:

Clonage dans ‘/home/linds/programs/code-art’…
remote: Enumerating objects: 85025, done.
remote: Counting objects: 100% (183/183), done.
remote: Compressing objects: 100% (82/82), done.
remote: Total 85025 (delta 122), reused 119 (delta 101), pack-reused 84842 (from 2)
Réception d’objets: 100% (85025/85025), 152.30 Mio | 11.50 Mio/s, fait.
Résolution des deltas: 100% (67343/67343), fait.
– The C compiler identification is GNU 11.4.0
– The CXX compiler identification is GNU 11.4.0
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Check for working C compiler: /usr/bin/cc - skipped
– Detecting C compile features
– Detecting C compile features - done
– Detecting CXX compiler ABI info
– Detecting CXX compiler ABI info - done
– Check for working CXX compiler: /usr/bin/c++ - skipped
– Detecting CXX compile features
– Detecting CXX compile features - done
– WARNING: gcc 11.4.0 is known to miscompile ART when using --ffp-contract=fast, forcing the option to be off
– CMAKE_BUILD_TYPE: release
– Found PkgConfig: /usr/bin/pkg-config (found version “0.29.2”)
– Checking for module ‘gtk±3.0>=3.16’
– Found gtk±3.0, version 3.24.33
– Checking for module ‘gtkmm-3.0>=3.16’
– Found gtkmm-3.0, version 3.24.5
– Checking for module ‘glib-2.0>=2.44’
– Found glib-2.0, version 2.72.4
– Checking for module ‘glibmm-2.4>=2.44’
– Found glibmm-2.4, version 2.66.2
– Checking for module ‘cairomm-1.0’
– Found cairomm-1.0, version 1.12.2
– Checking for module ‘gio-2.0>=2.44’
– Found gio-2.0, version 2.72.4
– Checking for module ‘giomm-2.4>=2.44’
– Found giomm-2.4, version 2.66.2
– Checking for module ‘gthread-2.0>=2.44’
– Found gthread-2.0, version 2.72.4
– Checking for module ‘gobject-2.0>=2.44’
– Found gobject-2.0, version 2.72.4
– Checking for module ‘sigc+±2.0>=2.3.1’
– Found sigc+±2.0, version 2.10.4
– Checking for module ‘lensfun>=0.2’
– Found lensfun, version 0.3.2.0
– Checking for module ‘librsvg-2.0>=2.40’
– Found librsvg-2.0, version 2.52.5
– Checking for module ‘exiv2>=0.24’
– Found exiv2, version 0.27.5
– searching for library exiv2 in /usr/lib/x86_64-linux-gnu
– result: /usr/lib/x86_64-linux-gnu/libexiv2.so
– Checking for module ‘lcms2>=2.6’
– Found lcms2, version 2.12
– Checking for module ‘expat>=2.1’
– Found expat, version 2.4.7
– Checking for module ‘fftw3f’
– Found fftw3f, version 3.3.8
– Checking for module ‘libtiff-4>=4.0.4’
– Found libtiff-4, version 4.3.0
– Found JPEG: /usr/lib/x86_64-linux-gnu/libjpeg.so (found version “80”)
– Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version “1.2.11”)
– Found PNG: /usr/lib/x86_64-linux-gnu/libpng.so (found version “1.6.37”)
– Checking for module ‘libcanberra-gtk3’
– Found libcanberra-gtk3, version 0.30
– Found OpenMP_C: -fopenmp (found version “4.5”)
– Found OpenMP_CXX: -fopenmp (found version “4.5”)
– Found OpenMP: TRUE (found version “4.5”)
– Performing Test _fftw3f_multithread
– Performing Test _fftw3f_multithread - Failed
– searching for library lensfun in /usr/lib/x86_64-linux-gnu
– result: /usr/lib/x86_64-linux-gnu/liblensfun.so
– Performing Test LENSFUN_HAS_LOAD_DIRECTORY
– Performing Test LENSFUN_HAS_LOAD_DIRECTORY - Success
– Performing Test _lcms2_fast_float
– Performing Test _lcms2_fast_float - Failed
CMake Warning at CMakeLists.txt:618 (find_package):
By not providing “Findmimalloc.cmake” in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by “mimalloc”,
but CMake did not find one.

Could not find a package configuration file provided by “mimalloc” with any
of the following names:

mimallocConfig.cmake
mimalloc-config.cmake

Add the installation prefix of “mimalloc” to CMAKE_PREFIX_PATH or set
“mimalloc_DIR” to a directory containing one of the above files. If
“mimalloc” provides a separate development package or SDK, be sure it has
been installed.

CMake Error at CMakeLists.txt:629 (message):
ART requires the mimalloc library. Please install it (see
mi-malloc: mi-malloc)

– Configuring incomplete, errors occurred!
See also “/home/linds/programs/code-art/build/CMakeFiles/CMakeOutput.log”.
See also “/home/linds/programs/code-art/build/CMakeFiles/CMakeError.log”.
linds@linds-photo95-pc:~/programs/tools$


ART fonctionne bien en le lançant depuis un terminal dans son dossier de stockage (en tapant ./ART) : j’ai travaillé avec de longues heures hier, c’est juste que je souhaitais compiler et visiblement la compilation ne veut pas de moi !

Mimalloc est originaire de Microsoft, mais ce gestionnaire d’allocation mémoire (multiplateforme) semble très efficace et préféré par Alberto. Dans la liste des dépendances à installer, en principe il y a “libmimalloc-dev”. L’as-tu bien installé avant de lancer la compilation ?

Et note bien que si tu n’as pas installé CTL et ses dépendances, tu n’auras pas accès aux scripts CTL avec cette version compilée.

Bonjour @sguyader,

Merci pour la réponse rapide et pour l’aide.
Oui j’ai bien installé “libmimalloc-dev” car cela faisait partie du copier/coller “en une seule fois” indiqué.
J’ai refait à plusieurs reprise ce “sudo apt install” et voici le résultat : tout est bien à jour sur mon ordinateur :


linds@linds-photo95-pc:~$ sudo apt install build-essential cmake curl git libcanberra-gtk3-dev libexiv2-dev libexpat-dev libfftw3-dev libglibmm-2.4-dev libgtk-3-dev libgtkmm-3.0-dev libiptcdata0-dev libjpeg-dev liblcms2-dev libpng-dev librsvg2-dev libsigc+±2.0-dev libtiff5-dev zlib1g-dev liblensfun-dev libmimalloc-dev
[sudo] Mot de passe de linds :
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances… Fait
Lecture des informations d’état… Fait
Note : sélection de « libexpat1-dev » au lieu de « libexpat-dev »
build-essential est déjà la version la plus récente (12.9ubuntu3).
libexiv2-dev est déjà la version la plus récente (0.27.5-3ubuntu1).
libfftw3-dev est déjà la version la plus récente (3.3.8-2ubuntu8).
libglibmm-2.4-dev est déjà la version la plus récente (2.66.2-2).
libgtkmm-3.0-dev est déjà la version la plus récente (3.24.5-1build1).
libjpeg-dev est déjà la version la plus récente (8c-2ubuntu10).
liblcms2-dev est déjà la version la plus récente (2.12~rc1-2build2).
libpng-dev est déjà la version la plus récente (1.6.37-3build5).
libsigc+±2.0-dev est déjà la version la plus récente (2.10.4-2ubuntu3).
libiptcdata0-dev est déjà la version la plus récente (1.0.5-2.3ubuntu1).
liblensfun-dev est déjà la version la plus récente (0.3.2-6).
libmimalloc-dev est déjà la version la plus récente (2.0.5+ds-2).
cmake est déjà la version la plus récente (3.22.1-1ubuntu1.22.04.2).
curl est déjà la version la plus récente (7.81.0-1ubuntu1.20).
git est déjà la version la plus récente (1:2.34.1-1ubuntu1.15).
libcanberra-gtk3-dev est déjà la version la plus récente (0.30-10ubuntu1.22.04.1).
libexpat1-dev est déjà la version la plus récente (2.4.7-1ubuntu0.6).
libgtk-3-dev est déjà la version la plus récente (3.24.33-1ubuntu2.2).
librsvg2-dev est déjà la version la plus récente (2.52.5+dfsg-3ubuntu0.2).
libtiff5-dev est déjà la version la plus récente (4.3.0-6ubuntu0.11).
zlib1g-dev est déjà la version la plus récente (1:1.2.11.dfsg-2ubuntu9.2).
0 mis à jour, 0 nouvellement installés, 0 à enlever et 334 non mis à jour.
linds@linds-photo95-pc:~$


On voit bien que “libmimalloc-dev” est supposément opérationnel.
Donc je sèche encore plus…
J’ai regardé vite fait un des fichiers .log, mais je n’y comprends rien :slight_smile:
Je ne peux pas le placer ici, du fait de son extension non-autorisée, mais je peux éventuellement le mettre dans un fichier texte.

Nota : Quand je lance ART depuis un terminal, j’ai de suite un message d’erreur, mais qui n’empêche pas le fonctionnement du logiciel.
Voici ce message :

linds@linds-photo95-pc:~/Programmes/ART-1.24.5-linux64$ ./ART
Gtk-Message: 19:02:19.350: Failed to load module “xapp-gtk3-module”

Puis, après, pendant l’utilisation de ART, le terminal se noircit de messages en tous genres mais sans pertuber plus que cela le fonctionnement du programme.

Sinon, que sont les CTL ?

Bonsoir

ART fonctionne bien en le lançant depuis un terminal dans son dossier de stockage (en tapant ./ART) : j’ai travaillé avec de longues heures hier, c’est juste que je souhaitais compiler et visiblement la compilation ne veut pas de moi !

La compilation a l’avantage d’accélèrer significativement le lancement d’ART ainsi que l’ouverture des fichiers à traiter.

Mais comme tu t’en es rendu compte - c’est pas toujours aussi simple que l’explique Benois dans le fils de discussion qui avait été ouvert Compilation sous ubuntu 22.04 et debian 11 bullseye (en cours de modif)

Autant pour moi de n’avoir pas fait de réponse complète hier (par manque de temps) - car dans ce même fil aparait également la difficulté rencontrée avec mi-alloc (lorsque cette dépendance n’est pas encore installée) - Sur ma linux mint c’est cette librairie (et pas la version dev)

Et pour l’installer il faut également récupérer les sources et les compiler comme explique

1 « J'aime »

Bonjour

Bonne nouvelle pour les utilisateurs de linux mint car pour en avoir le coeur net j’avais à faire un nouvelle installation sur mon PC de “secours”. J’ai donc une installation vierge à partir de laquelle - après avoir finaliser l’installation de Linux Mint 22.2 Zara comme expiqué sur ce fil Entre–aide migration de Windows à Linux - #18 par alain_gre j’ai repris sans les modifier chacune des lignes de commande du premier post sur Compilation sous ubuntu 22.04 et debian 11 bullseye (en cours de modif) et rien d’autre.

La compilation à été jusqu’au bout sans besoin d’installer d’autres librairies

Bonjour tout le monde,

Merci @alain_gre : en voyant ton dernier message de bonne nouvelle, je me suis dit que mes difficultés pouvaient alors éventuellement venir de mises à jour de mon système (0) que je n’avais pas faites. En effet, ne sachant pas vraiment en quoi consistaient les mise-à-jour indiquées, j’avais toujours décidé de ne pas les faire (1) ; mais j’ai donc tout mis à jour, puis relancé la compilation par ./build-art (tout ayant été fait avant cette ligne selon le protocole rappelé plus haut)… mais ce n’était pas cela !

Comme cela bloquait toujours au même endroit : “mimalloc”, j’ai donc repris ton avant-dernier message qui reprenait les sources associées à récupérer et à compiler, ainsi que les différents liens vers d’autres messages pour ce faire, dont celui de @srgmro. J’ai donc suivi scrupuleusement le protocole donné ici Mise à jour ART en panne? (24/12/2022) - #25 par srgmro :

Puis j’ai ouvert de nouveau un terminal sous ~/programs/tools pour lancer ./build-art…

…et là, MIRACLE, la compilation a démarré différemment des autres fois et s’est mise à égrener les % les uns derrière les autres jusqu’à atteindre les 100% avec succès !

En lançant ART avec ~/programs/art/ART, le logiciel s’ouvre bel et bien, avec en version : 908c67575, au lieu de 1.24.5, correspondant à ART-1.24.5-linux64.tar.xz que je lance via un terminal par ./ART => est-ce bien bon ?

Dans tous les cas, merci à vous @alain_gre, @sguyader et @srgmro pour votre contribution à ce forum qui aide grandement les novices comme moi.

(0) Linux Mint 21.2 Cinnamon | version 5.8.4 | Noyau 5.15.0-153-generic | Intel Core i5-2520M CPU @ 2.5GHzx2 | RAM 7.7 Go | 320 Go | Nvidia GF119M [NVS 4200M]

(1) j’avais évalué les possibilités d’utiliser un vieux PC Windows 7 Pro que j’avais déjà pour le réserver exclusivement à traiter mes photos, et rien d’autre, de sorte que je limite également les connexions à internet. Il me fallait également un logiciel avec lequel je partirai de zéro, étant donné que ma licence supposée permanente Lightroom s’est retrouvée invalidée par la politique d’Adobe. Et j’ai trouvé ART (grâce RT + ce forum + Carafife), or ART ne tourne pas sous windows 7, il m’a donc fallu passer en dual boot sur Linux. Je me suis alors retrouvé avec le mur d’une courbe d’apprentissage Linux + ART :sweat_smile: pour laquelle je devais identifier de quoi m’en tenir au strict minimum nécessaire à mon besoin initial : essayer d’améliorer mes prises de vue de base…

Tout d’abord, bravo pour ce succès !

Oui c’est bon. Ce 908c67575 correspond au numéro du dernier commit ajouté au code à partir du quel du as compilé ART. Quand tu vas sur Commits · artpixls/ART · GitHub tu vois la liste des commits et leur numéro

1 « J'aime »

Pour plus d’infos :

En utilisant la recherche sur le forum, tu pourras trouver d’autres infos ici et là.

Mais comme je l’ai dit plus haut, pour activer CTL il faut installer (compiler probablement) l’interpréteur CTL et ses dépendances.

1 « J'aime »

Bonsoir - Mauvaise pioche. Que l’on soit sous linux ou windows - il faut toujours maintenir à jour son système et ses applications.

Linux Mint 21.2 Cinnamon | version 5.8.4 | Noyau 5.15.0-153-generic | Intel Core i5-2520M CPU @ 2.5GHzx2 | RAM 7.7 Go | 320 Go | Nvidia GF119M [NVS 4200M]

S’il s’agit d’un disque mécanique - le remplacer par un SSD de 256 Go ou plus et ce sera une configuration matérielle tout a fait acceptable (sous réserve d’un bon écran)

1 « J'aime »

Merci @alain_gre pour tes conseils et ta prévenance.

Pour les mises-à-jour, j’ai la “tête dure” et pars du principe qu’un système fait pour rendre un service à un moment donné… peut être isolé (au sens physique même du terme :wink: ) de sorte à toujours apporter la satisfaction initiale, si le besoin lui-même n’évolue pas. C’est ma contribution à ne pas surconsommer : utiliser un vieux PC qui fait tout-à-fait l’affaire (tout comme remplacer un condo sur un sèche-linge, par exemple, même s’il faut tout démonter pour cela, plutôt que de racheter la machine entière).

Pour ma configuration matérielle, j’ai la chance d’avoir un écran Eizo CS2420.
J’y vois faire avec mon développement, un peu ce qui est préconisé ici ou là pour la prise de vue : investir dans l’objectif plus que dans le boîtier ! C’est un peu le principe suivant : “l’écran est à l’objectif, ce que le boîtier est à l’ordinateur” :smiley:
Cela dit, toujours sur le matériel, en commençant à développer mes photos, je me rends encore plus compte de quelques belles qualités de mon boîtier, comme une balance des blancs et une montée en iso tout-à-fait satisfaisantes. C’est un Pentax K3 de 2015. Je l’avais acheté sur des conseils et autres bancs tests réalisés, avec un commentaire qui m’avait marqué à l’époque, du genre : “c’est un appareil fait pour faire de la photo sans fioriture et il le fait bien”. Par fioriture, étaient listées des fonctions du genre connectivité, écran déporté etc. qui ne m’intéressaient pas à l’epoque car je voulais juste apprendre à photographier avec un premier reflex numérique.

Merci encore de m’avoir guidé pour résoudre le sujet initial.

PS : après avoir écrit ce message, je retourne dans ART nouvellement compilé et je me rends compte que le programme ne trouve plus mon APN pour les corrections d’objectif alors que c’est bien le cas pour la version 1.24.5 => je vais donc devoir utiliser cette version non-compilée en attendant, snif. Savez-vous pourquoi ou comment résoudre cela ?

Ça doit être un souci de base de données lensfun. Cette base devrait être dans /usr/share/lensfun/version_1, ou peut-être dans /var/lib/lensfun-updates/version_1.

Essaye de voir si tu trouves bien la base lensfun dans un de ces répertoires, et ce qui ne fera pas de mal c’est de faire une mise à jour en tapant dans le terminal la commande : sudo lensfun-update-data

Puis relance ART.

1 « J'aime »

Merci @sguyader,

Il y a bien un tel dossier dans /usr/share/lensfun/version_1
On y trouve un fichier mil-pentax.xml, que j’ai ouvert dans un éditeur de texte et qui semble effectivement bien vide.

En revanche, le terminal m’indique “commande introuvable” quand je tape exactement “sudo lensfun-update-data”, que ce soit à partir d’un terminal ‘racine’ (lancé par Ctrl+Alt+t), ou bien en lançant un terminal à partir du dossier “lensfun” ; mais peut-être que je m’y prend mal ?

lensfun-update-data est un script python qui doit être localisé dans usr/bin. Si tu ne trouves pas le script à cet endroit, regarde il faut peut-être installer un autre paquet avec sudo apt install liblensfun-data (j’ai vu ça sur un vieux post de forum linuxmint, mais comme je ne suis pas sous le même type de distribution Linux, je ne suis pas sûr).

1 « J'aime »

Bonsoir

Je confirme que sur ma mint j’ai bien ces paquets d’installés

Coté base de données - ma version compilée permet bien à ART de retouver (automatiquement) mon boitier et l’objectif à partir des exifs (*) (sauf lorsque j’utilise une bague d’adaptation mais je peux choisir l’objectif dans une liste) .

(*) il faut donc qu’ART puisse lire les exifs et pour cela disposer d’un outil qui s’appelle exiftools

Tout ça pour dire que je n’ai pas fait autre chose que compiler ART sur une mint nouvellement installée mais que j’ai bien des bibliothèques de lecture des exifs qui proviennent du build

PS - Tout à fait d’accord sur le parallèle objectif/ boitier et écran/ordinateur mais j’ai eu remplacé une courroie à 20 € sur un sèche linge apès un gros démontage et ainsi pu le maintenir en état de fonctionnement pendant plus de 10 ans ..sauf que lorsque que j’ai du finalement en changer - ma facture d’éléctricité à bien diminuée :slight_smile:

1 « J'aime »

Bonjour,

Merci encore et une nouvelle fois à vous deux @alain_gre et @sguyader pour votre patience à vous pencher sur mon cas ; c’est vraiment très agréable de se sentir soutenu.

J’ai l’impression que mes déboires sont plus liés à ma config Linux qu’à ART, et j’aimerais bientôt pouvoir plutôt publier des sujets plus liés au coeur même de ce forum : la photo, plutôt que de remonter des problèmes autres rencontrés :slight_smile:

Ma Linux Mint 21.2 Cinnamon 5.8.4 est à jour à ceci près :

et outre le fait que le système propose également cela :

Sinon, j’ai bien vérifié les paquets et ils sont bien existants chez moi, à une légère différence de version près par rapport à ce que @alain_gre montre :

Donc je sèche…
…d’autant plus que lancer ART 1.24.5 par un terminal me permet bien de trouver mon APN, comparativement donc à lancer ART compilé.

De part les deux versions d’ART installées, j’ai noté deux grosses différences :

=> On voit bien qu’il y a une nette différence de version !

De ce fait, je ne comprends toujours pas pourquoi en compilant en 2025, avec a priori la bonne version d’ART installée (cf échange plus haut sur le commit 908c7575), et en ayant suivi scrupuleusement (en tant que novice) tout le protocole, une telle différence se présente.

Comme la mise-à-jour de lensfun évoquée à juste titre par @sguyader est sans succès pour l’instant chez moi, une idée basique est de remplacer les fichiers que ART compilé va chercher par ceux présents et opérationnels pour ART 1.24.5… sauf que le système ne me le permet pas (remplacement basique par supprimer, copier/coller dans Nemo le gestionnaire de fichiers)… décidément…

Et la commande suivante est en échec également… décidément bis (pleurs) !