Je rencontre un problème de compilation sous Manjaro ?
La première fois ce n’est pas passé avec l’erreur, la compilation c’est arrêtée.
Dans le fichier inclus depuis /usr/include/string.h:519,
depuis /usr/include/glib-2.0/glib/gslice.h:26,
depuis /usr/include/glib-2.0/glib.h:79,
depuis /tmp/pamac-build/art-rawconverter-git/src/art-rawconverter-git_src/rtengine/dcraw.cc:12:
Dans la fonction « void* memcpy(void*, const void*, size_t) »,
mis en ligne depuis « int fread(void*, int, int, IMFILE*) » à /tmp/pamac-build/art-rawconverter-git/src/art-rawconverter-git_src/rtengine/myfile.h:123:16,
mis en ligne depuis « void DCraw::parse_makernote(int, int) » à /tmp/pamac-build/art-rawconverter-git/src/art-rawconverter-git_src/rtengine/dcraw.cc:5643:13:
/usr/include/bits/string_fortified.h:34:33: attention: « void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int) » la taille spécifiée entre 18446744071562067968 et 18446744073709551615 excède la taille maximale 9223372036854775807 de l'objet [-Wstringop-overflow=]
34 | return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 10%] Building CXX object rtengine/CMakeFiles/rtengine.dir/gauss.cc.o
J’ai donc redémarré le PC, j’ai eu la même erreur mais ART est passé en version 1.6 quand même ?
Je fais suite à mon message.
J’ai lancé mon PC, il m’a été proposé la version git-1.61, elle ne c’est pas installée ?
J’avais également un autre logiciel qui posait problème “libhandy-git” que j’ai supprimé.
Je reviens sur ce problème qui n’empêche pas ART de fonctionner.
Lorsque je fais la compilation sous Ubuntu je reçois ce qui semble être une erreur ?
N’ayant pas eu de réponse, je repose la question sur ce sujet avant d’en créer un autre.
[ 8%] Building CXX object rtengine/CMakeFiles/rtengine.dir/hphd_demosaic_RT.cc.o
[ 8%] Building CXX object rtengine/CMakeFiles/rtengine.dir/iccstore.cc.o
In file included from /usr/include/string.h:495,
from /usr/include/glib-2.0/glib/gtestutils.h:30,
from /usr/include/glib-2.0/glib.h:85,
from /home/caille/programs/code-art/rtengine/dcraw.cc:12:
In function ‘void* memcpy(void*, const void*, size_t)’,
inlined from ‘int fread(void*, ssize_t, ssize_t, IMFILE*)’ at /home/caille/programs/code-art/rtengine/myfile.h:123:16,
inlined from ‘void DCraw::parse_makernote(int, int)’ at /home/caille/programs/code-art/rtengine/dcraw.cc:5643:13:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34:33: warning: ‘void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int)’ specified size between 9223372036854775808 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
34 | return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 8%] Building CXX object rtengine/CMakeFiles/rtengine.dir/iimage.cc.o
[ 9%] Building CXX object rtengine/CMakeFiles/rtengine.dir/image16.cc.o
Dans ce que tu as mis je ne vois pas de messsage d’erreur, juste des “warnings”. Ca ne devrait pas empêcher ART de finir de compiler et de fonctionner correctement.
Pour réagir à tes messages précédents sur la compilation sous Manjaro (je suis aussi sous Manjaro) personnellement je compile directement à partir du code source en utilisant le script fourni (un peu adapté) .
salut @sguyader. Je profite de tes connaissances pour te demander si la compilation avec Build-art (en le modifiant …???) peut jouer sur l’utilisation de la Ram dans les traitements… Sans tout à fait comprendre le processus, il me semble qu’Alberto fait appel à la Library Malloc pour la gestion de la ram…
Chez moi Art est trèèèès consommateur de Ram !!! Sur un traitement assez poussé, il n’est pas rare que Art utilise 15 go de ram… (sur un total de 32 go).
Est ce que cela te semble normal ?
Salut, à une époque j’ai testé mimalloc, quand Alberto a ajouté le support, à la place de tcmalloc. Mais honnêtement, sans tests scientifiques, je n’ai pas trouvé de différence significative entre les deux à l’époque.
Par contre 15 Go de RAM utilisé pour untraitement, ça me paraît énorme ! Peut-être devrais-tu le signaler à Alberto sur bitbucket, en lui donnant accès à un raw + arp.
Ou bien si tu veux je peux regarder sur mon système si tu m’envoies raw + arp.
Edit: la modification du script build-art pour moi consiste surtout en la modification des chemins entre sources et répertoire de destination du programme, rien d’exotique.
Je viens de tester un RAW issu d’un Nikon D800, 36MP, avec plein de traitements (pratiquement tous les filtres activés sur les 5 premiers onglets) ART ne prend que 1.7 Go.
Si j’ouvre 6 raws en même temps (même appareil, même traitement), ça monte à 5.2 Go.
Par contre ce que j’ai déjà constaté, c’est que quand on charge des raws comme cela et que la RAM est occupée, si on ferme les raws ART ne libère pas la RAM.
Ok… J’ai quand même un problème de surconsommation… À moins que la gestion de la ram sur Manjaro (et ailleurs peut être) est fonction de la disponibilité totale ? Plus il y en a, plus le système en consomme ?? (pure conjecture… !!)
Je vais tenter bientôt une install à la main d’une Arch (pure !), je comparerais les résultats…
Je ne pense pas que la gestion de mémoire dépende de ce qui est disponible, mais je peux me tromper.
Si j’ouvre 6 copies de ton raw avec le même traitement, ça occupe 3,7Go. Si ensuite je m’amuse à changer les paramètres de ton triatement ça monte au maximum à 4.2 Go.
Ton ART est compilé avec quel allocateur de mémoire ? TCMALLOC ?
Si la réponse est non, essaye de recompiler ART en mettant l’option -DENABLE_TCMALLOC="ON" à la commande cmake. Il faut avoir installé le paquet gperftools d’abord.
Non, il n’y pas de message d’erreur, mais un overflow, ça a donc débordé.
Petite question, pour préserver le SSD ne serait-il pas préférable de créer le dossier code-art en RAM en utilisant une partition du type tmpfs: https://doc.ubuntu-fr.org/tmpfs
Cela aurait pour avantage d’éviter d’user les puces du SSD lors du clonage du git ?
Sous Manjaro AUR, ça ce passe comme ça si je choisi le bon tmp !
Aucune idée… Mais il me semble qu’aujourd’hui les SSD sont plus robustes et qu’il est plus probable que tu changes de SSD avant qu’il ne défaille, sachant qu’à l’heure actuelle les capacités de stockage des SSD sont encore relativement faibles et qu’on a tendance à changer pour plus gros quand les prix baissent…
Et puis personnellement, je ne fais pas de mise à jour régulière.
Bref, sur ça je ne peux pas te t’aiguiller…
