Installation de wxWidgets 3.0.2 sous Code::Blocks 16.01

Version imprimable

Merci wxXav,

A ta demande, j'ouvre une nouvelle discussion.

Je rappelle mon problème de compilation :

C:/Program Files (x86)/CodeBlocks/MinGW/lib/gcc/mingw32/4.9.2/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

Et ta réponse
Citation:
Voici le complément à ajouter à la ligne de commande :

Code:

CXXFLAGS=-fno-keep-inline-dllexport -std=gnu++11

Et pour gagner un peu de temps lors de la compilation, il est possible d'utiliser les différents coeurs du processeur en lançant plusieurs processus en même temps :
Code:

1 2 3 mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 clean mingw32-make -f makefile.gcc setup_h USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CXXFLAGS=-fno-keep-inline-dllexport -std=gnu++11 mingw32-make -j4 -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CXXFLAGS=-fno-keep-inline-dllexport -std=gnu++11
L'option "-j4" permet de lancer 4 processus de compilation en même temps : elle est à adapter en fonction du processeur.
Pour le paramètre "-fno-keep-inline-dllexport", je ne sais pas exactement à quoi il sert, mais je me souviens qu'il était indispensable pour la compilation en monolithique (sinon le linker plantait à cause d'un dépassement de mémoire).
Et pour le paramètre "-std=gnu++11", il permet de résoudre ton message d'erreur.
Bonne compilation.
@+
Xav'
Ton conseil a résolu mon problème de compilation. Merci !

Par contre, lorsque je veux créer un projet sous Code::Blocks, j'ai toujours le message : "A matching debug configuration cannot..."

Philippe

08/02/2016, 07h50
wxXav

Salut.

Citation:

Envoyé par Pgs

A ta demande, j'ouvre une nouvelle discussion.

Ce n'était pas vraiment une demande : juste un conseil.

Citation:

Envoyé par Pgs

Par contre, lorsque je veux créer un projet sous Code::Blocks, j'ai toujours le message : "A matching debug configuration cannot..."

C'est tout à fait normal : tu as compilé tes libs en mode "release" uniquement. Il est donc normal que Code::Blocks ne trouve pas de configuration "debug".
Maintenant, si tu lances les mêmes commandes en ramplaçant "BUILD=release" par "BUILD=debug", tu auras les deux configurations disponibles, et Code::Blocks ne t'embêtera plus avec ce message d'erreur (mais si tu ne souhaites pas utiliser de configuration debug pour ton application, tu peux tout simplement ignorer le message d'avertissement, ou décocher l'option correspondante dans l'assistant Nouveau Projet de Code::Blocks).

Bonne continuation.
Xav'

1 pièce(s) jointe(s)

Merci !

J'ai décoché la configuration DEBUG et, comme tu le disais, le problème du message est maintenant réglé.

J'ai donc créé un projet :
Code:

1 2 3 4 5 6 7 8 9 10 * wsWidgets 3.0.x * prefered GUI Builder : none * applicatio Type : Dialog Based * create "Release" configuration * Use wxWidgets DLL * wxWidgets is built as a monilithic library * enable unicode * Create and use precompiled header * Advanced options : case "Use_WXDEBUG_..." non sélectionnée * Release Target : Gui Mode Application
J'ai ensuite directement lancé un build et voici ce que j'obtiens.

/** @file bits/c++0x_warning.h
* This is an internal header file, included by other library headers.
* Do not attempt to use it directly. @headername{iosfwd}
*/

#ifndef _CXX0X_WARNING_H
#define _CXX0X_WARNING_H 1

#if __cplusplus < 201103L
#error This file requires compiler and library support for the \
ISO C++ 2011 standard. This support is currently experimental, and must be \
enabled with the -std=c++11 or -std=gnu++11 compiler options.
#endif

#endif

||=== Build: Release in Test_wx (compiler: GNU GCC Compiler) ===|
C:\Program Files (x86)\CodeBlocks\MinGW\lib\gcc\mingw32\4.9.2\include\c++\bits\c++0x_warning.h|32|error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.|
C:\wxWidgets-3.0.2\include\wx\strvararg.h|350|error: 'is_enum' in namespace 'std' does not name a template type|
C:\wxWidgets-3.0.2\include\wx\strvararg.h|354|error: 'is_enum' was not declared in this scope|
C:\wxWidgets-3.0.2\include\wx\strvararg.h|354|error: template argument 1 is invalid|
||=== Build failed: 4 error(s), 0 warning(s) (0 minute(s), 8 second(s)) ===|

Y-a-t-il une étape complémentaire obligatoire à faire avant le construire ce projet vide ?

En fait, je souhaite démarrer mon projet par un simple menu déroulant avec deux items : Date et Heure. Lorsque l'on sélectionne "Date", le programme affiche la date dans une boite message. Idem pour l'heure.

Merci

Philippe

08/02/2016, 08h38
Pgs

(suite)

J'ai tenté une compilation debug et voici ce que j'obtiens :

C:\wxWidgets-3.0.2\build\msw>mingw32-make -j4 -f makefile.gcc USE_XRC=1 SHARED=1
MONOLITHIC=1 BUILD=debug UNICODE=1
if not exist gcc_mswuddll mkdir gcc_mswuddll
if not exist ..\..\lib\gcc_dll\mswud mkdir ..\..\lib\gcc_dll\mswud
if not exist ..\..\lib\gcc_dll\mswud\wx\setup.h copy ..\..\include\wx\msw\setup.
h ..\..\lib\gcc_dll\mswud\wx\setup.h
gcc -c -o gcc_mswuddll\wxregex_regcomp.o -g -O0 -mthreads -DHAVE_W32API_H -DNDE
BUG -I..\..\include -I..\..\lib\gcc_dll\mswud -D__WXMSW__ -D_UNICODE -fno-keep
-inline-dllexport -MTgcc_mswuddll\wxregex_regcomp.o -MFgcc_mswuddll\wxregex_regc
omp.o.d -MD -MP ../../src/regex/regcomp.c
gcc -c -o gcc_mswuddll\wxregex_regexec.o -g -O0 -mthreads -DHAVE_W32API_H -DNDE
BUG -I..\..\include -I..\..\lib\gcc_dll\mswud -D__WXMSW__ -D_UNICODE -fno-keep
-inline-dllexport -MTgcc_mswuddll\wxregex_regexec.o -MFgcc_mswuddll\wxregex_rege
xec.o.d -MD -MP ../../src/regex/regexec.c
Le chemin d'accès spécifié est introuvable.
0 fichier(s) copié(s).
makefile.gcc:5651: recipe for target '..\..\lib\gcc_dll\mswud\wx\setup.h' failed

mingw32-make: *** [..\..\lib\gcc_dll\mswud\wx\setup.h] Error 1
mingw32-make: *** Waiting for unfinished jobs....
In file included from ..\..\include/wx/defs.h:27:0,
from ../../src/regex/regcustom.h:39,
from ../../src/regex/regguts.h:38,
from ../../src/regex/regexec.c:32:
..\..\include/wx/platform.h:183:22: fatal error: wx/setup.h: No such file or dir
ectory
#include "wx/setup.h"
^
In file included from ..\..\include/wx/defs.h:27:0,
from ../../src/regex/regcustom.h:39,
from ../../src/regex/regguts.h:38,
from ../../src/regex/regcomp.c:33:
..\..\include/wx/platform.h:183:22: fatal error: wx/setup.h: No such file or dir
ectory
#include "wx/setup.h"
^
ccomopmilpaitliaotni otne rtmeirnmaitneadt.e
d.
makefile.gcc:5705: recipe for target 'gcc_mswuddll\wxregex_regexec.o' failed
mingw32-make: *** [gcc_mswuddll\wxregex_regexec.o] Error 1
makefile.gcc:5702: recipe for target 'gcc_mswuddll\wxregex_regcomp.o' failed
mingw32-make: *** [gcc_mswuddll\wxregex_regcomp.o] Error 1

C:\wxWidgets-3.0.2\build\msw>
08/02/2016, 09h06
wxXav

Je n'y avais pas pensé, mais c'est tout à fait logique que ça ne compile pas.

On a ajouté l'option, "-std=gnu++11" pour la compilation des libs : il faut faire de même pour compiler ton projet.

Dans Code::Blocks, après avoir ouvert ton projet, tu vas dans "Project", "Build options".
Tu sélectionnes le project dans la liste de gauche (et non une des configuration).
Tu vas dans l'onglet "Compiler Settings" à droite, puis dans le sous-onglet "Other compiler options"
Et dans la liste que contient ce sous-onglet, tu ajoutes tout simpelement une ligne contenant "-std=gnu++11".

En ce qui concerne la tentative de compilation d'une configuration "Debug", je dirais que tu as lancé directement la commande "make... -j4" sans au préalable lancer celle qui contient "setup_h".
Comme plusieurs processus sont lancés en même temps, il faut absolument le faire avant, afin que le fichier "setup.h" soit créé au bon endroit et qu'il soit disponible pour tous les processus.

@+
Xav'
08/02/2016, 10h00
Pgs

Merci !

a) Le programme se compile, mais lors de l'exécution, j'obtiens "il manque wxmsw30u_gcc-custom.dll sur votre ordinateur".

b) Pour la compilation de wx, voici ce que j'obtiens

C:\wxWidgets-3.0.2\build\msw>mingw32-make -f makefile.gcc setup_h USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1
if not exist ..\..\lib\gcc_dll\mswu mkdir ..\..\lib\gcc_dll\mswu
if not exist ..\..\lib\gcc_dll\mswu\wx mkdir ..\..\lib\gcc_dll\mswu\wx

C:\wxWidgets-3.0.2\build\msw>mingw32-make -f makefile.gcc setup_h USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1
if not exist ..\..\lib\gcc_dll\mswud\wx mkdir ..\..\lib\gcc_dll\mswud\wx
if not exist ..\..\lib\gcc_dll\mswud\wx\setup.h copy ..\..\include\wx\msw\setup.
h ..\..\lib\gcc_dll\mswud\wx\setup.h 1 fichier(s) copié(s).
if not exist ..\..\lib\gcc_dll\mswud\wx\msw mkdir ..\..\lib\gcc_dll\mswud\wx\mswgcc -E "..\..\include\wx\msw\genrcdefs.h" > "..\..\lib\gcc_dll\mswud\wx\msw\rcdefs.h"

C:\wxWidgets-3.0.2\build\msw>

J'ai ensuite relancé mingw32-make -j4 -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1

Cette fois-ci, plus d'erreur.

Mais si je créé un projet debug et release, j'ai à nouveau le message "A matching debug configuration cannot..."

Philippe
08/02/2016, 13h38
wxXav
Hello

Citation:

Envoyé par Pgs

Merci !

De rien 8-)

Citation:

Envoyé par Pgs

a) Le programme se compile, mais lors de l'exécution, j'obtiens "il manque wxmsw30u_gcc-custom.dll sur votre ordinateur".

C'est normal : le système ne sait pas où trouver cette dll que tu as fraîchement créé.
Tu as plusieurs possibilités :
- Ajouter le dossier dans lequel se trouve cette dll à la variable d'environnement PATH : il s'agit du sous-dossier /lib/gcc_dll/ de ton installation wxWidgets. Cette option peut devenir contraignante si tu as plusieurs versions et/ou plusieurs configurations de wxWidgets installées
- Copier la dll dans le répertoire de ton exécutable (mais il faudra la faire pour chaque nouveau projet, et il faudra également dupliquer la dll "debug" donc ça risque vide d'être le bazard)
- Créer un dossier dans lequel tu places toutes tes dll "spécifiques" et ajouter ce dossier à la variable d'environnement PATH
Citation:

Envoyé par Pgs

Cette fois-ci, plus d'erreur.

Mais si je créé un projet debug et release, j'ai à nouveau le message "A matching debug configuration cannot..."

Es-tu certain qu'il n'y a pas eut d'erreur ?
Normalement, tu ne devrais plus avoir ce message si tout s'était bien passé.
Pour le vérifier, tu dois avoir , dans le dossier "lib/gcc_dll" les éléments suivants :
- un dossier mswu et un dossier mswud
- les fichiers libs libwxbase30u.a et libwxbase30ud.a (il doit y en avoir d'autres).
- les dlls correspondantes : wxmsw30u.dll et wxmsw30ud.dll
Et bien entendu, la compilation de ton projet en mode debug doit pouvoir se faire sans problème.

@+
Xav'
08/02/2016, 22h04
Pgs

Bonsoir Xav',

J'ai finalement tout réinstallé en traitant MinGW de façon autonome afin de le placer en C:\MinGW => ÇA MARCHE !! Merci !!

J'ai ensuite créé un projet de base wxSmith. L'exécutable fonctionne correctement s'il est accompagné de wxmsw30u_gcc_custom.dll

Je suis surpris par la taille de cette dll (24 Mo).

De plus, lorsque j'ai lancé l'exécutable (qui est sur un disque partagé) à partir d'un autre poste du réseau, j'ai eu l'anomalie "le point d'entrée de procédure __gxx_peronality_v0 est introuvable". Je ne comprend pas pourquoi : l'EXE et/ou wxmsw30u_gcc_custom.dll sont-ils en lien avec la machine sur laquelle le build a été effectué ?

Y-a-t-il un moyen :
* de limiter la taille de la DLL en ne sélectionnant que les routines utilisées par le programme ?
* de compiler en statique afin de disposer d'un EXE autonome ?

Merci encore Xav'

Philippe
08/02/2016, 22h35
wxXav

Hello

Citation:

Envoyé par Pgs

J'ai finalement tout réinstallé en traitant MinGW de façon autonome afin de le placer en C:\MinGW => ÇA MARCHE !! Merci !!

Bonne nouvelle.

Citation:

Envoyé par Pgs

J'ai ensuite créé un projet de base wxSmith. L'exécutable fonctionne correctement s'il est accompagné de wxmsw30u_gcc_custom.dll

Comme je te l'ai expliqué, c'est logique.

Citation:

Envoyé par Pgs

Je suis surpris par la taille de cette dll (24 Mo).

Sa taille dépend des options de compilation et du compilateur lui même. Et en mode "monolothique", elle contient généralement tout le framework.

Citation:

Envoyé par Pgs

De plus, lorsque j'ai lancé l'exécutable (qui est sur un disque partagé) à partir d'un autre poste du réseau, j'ai eu l'anomalie "le point d'entrée de procédure __gxx_peronality_v0 est introuvable". Je ne comprend pas pourquoi : l'EXE et/ou wxmsw30u_gcc_custom.dll sont-ils en lien avec la machine sur laquelle le build a été effectué ?

Pas directement, mais suivant le système, il peut y avoir des différences de version avec certains fichiers dll.
Dans ton cas, il s'agit d'un problème de dll installée par MinGW.
Tu peux le vérifier facilement : trouve une dll nommée "libstdc++6" qui se trouve dans le dossier "bin" du MinGW que tu as ré-installé, et place-la aux côtés de l'exécutable.
Ton message d'erreur devrait normalement disparaître lorsque tu exécutes l'application depuis le second poste.

Citation:

Envoyé par Pgs

Y-a-t-il un moyen :
* de limiter la taille de la DLL en ne sélectionnant que les routines utilisées par le programme ?

Non. Tu peux par contre diminuer sa taille en modifiant certaines options de wxWidgets, mais ne t'attends pas à des miracles.

Citation:

Envoyé par Pgs

* de compiler en statique afin de disposer d'un EXE autonome ?

Oui : Recommence la compilation du Framework en remplaçant "SHARED=1" par "SHARED=0" (et en décochant "Use wxWidgets DLL" lors de la création du projet Code::Blocks).
Tu obtiendras un éxécutable qui fera dans les 6-8Mo en mode release.

Il existe aussi une autre alternative : ne pas utiliser l'option "Monolithique" lors de la compilation.
Tu obtiendras plusieurs dll de taille beaucoup plus modestes.

Citation:

Envoyé par Pgs

Merci encore Xav'

De rien.
C'est toujours un plaisir de pouvoir aider quelqu'un, surtout quand le résultat est satisfaisant.

Si tu as besoin de plus d'infos, n'hésite pas...

@+
Xav'
09/02/2016, 07h28
Pgs

Bonjour Xav',

Merci pour ton enthousiasme à me guider dans mon démarrage.

Je n'avais pas été attentif jusquà présent aux options de compilation de wxWidgets.

a) BUILD : peux-tu me dire la différence entre les options release et debug ?

b) SHARED : si je t'ai bien compris, c'est là que l'on précisse si les routines sont intégrées dans l'exécutable ou bien laissées à l'extérieur et reliées à ce dernier. C'est bien ça ?

c) MONOLITHIC : si je t'ai bien compris, c'est le package "tout compris". Quel est l'intérêt ? Pourquoi ne pas compiler de préférence avec MONOLITHIC=0 ?

d) USE_XRC : ?

e) UNICODE : dans quel cas choisirait-on 0 ?

Je voudrais essayer de faire un programme autonome, sans DLL.

Est-ce que je peux lancer une compilation du Framework SHARED=0 en complément de la compilation SHARED=1 ou bien dois-je faire un clean puis une nouvelle compilation (vu que la commande clean précise elle aussi toutes les options, je serais tenté de penser que chaque option de compilation est autonome et peut coexister avec les autres).

Si je peux avoir en parallèle une compiltation en SHARED= 1 et une complitation en SHARED = 0, me suffira-t-il alors simplement, lors de la construction du projet, de cocher/décocher "Use wxWidgets DLL" pour
générer un EXE autonome ou un ensemble EXE+DLL ?

Merci encore

Philippe
09/02/2016, 11h27
wxXav
Salut.

Citation:

Envoyé par Pgs

a) BUILD : peux-tu me dire la différence entre les options release et debug ?

Une build "release" et plus optimisée (pas seulement en taille) pour la production "finale". Il n'y a normalement plus d'informations de déboggage.
Malgré tout, avec wxWidgets, il reste quelques messages d'avertissements qui s'affichent (pour des trucs non bloquants). Pour ma part, je les désactive pour une build release en ajoutant "DEBUG_FLAG=0" à la ligne de commande. Il faut ensuite penser à l'ajouter lors de la compilation de l'exécutable sinon ça ne marche pas.
À l'inverse, une build "debug" contient énormément d'informations permettant le déboggage. Lorsque le déboggueur rencontre une erreur qui en temps normal aurait fait crasher l'application, il sait exactement où il se situe par rapport au code source. Ça permet de trouver plus facilement d'où vient le problème.
Pour ma part, j'ai tendance à ajouter plein de messages en mode debug et généralement, même s'il s'agit d'une application "GUI", elle est construite en mode console afin d'afficher tous ces messages.

Citation:

Envoyé par Pgs

b) SHARED : si je t'ai bien compris, c'est là que l'on précisse si les routines sont intégrées dans l'exécutable ou bien laissées à l'extérieur et reliées à ce dernier. C'est bien ça ?

C'est bien ça. "Shared" veut en anglais dire "Partagé". Pour faire simple, la partie correspondant à wxWidgets est partagée entre plusieurs applications.
Imagine que tu deviennes un codeur fou qui pond une nouvelle application wxWidgets par semaine.
Si elles font toutes référence à la même version de wxWidgets, tu peux toutes les mettre dans le même dossier, avec un seul exemplaire de la dll wxWidgets.
Imagine ensuite que tu corriges un petit bug dans les sources wxWidgets.
Il te suffit de recompiler la dll, et de la remplacer dans le dossier des applications, et le tour est joué : pas besoin de recompiler toutes les applications.
Je schématise, mais c'est exactement ce principe là.

Citation:

Envoyé par Pgs

c) MONOLITHIC : si je t'ai bien compris, c'est le package "tout compris". Quel est l'intérêt ? Pourquoi ne pas compiler de préférence avec MONOLITHIC=0 ?

Pour ma part, je ne l'utilise jamais.
Mais c'est vrai que c'est plus simple à gérer : une seule dll qui contient tout.
Quand tu as déjà une ribambelle de dll annexes à gérer (regarde le contenu du dossier de Code::Blocks), le fait de pouvoir simplifier est bien venu.

Citation:

Envoyé par Pgs

d) USE_XRC : ?

Celui là, tu n'est pas obligé de le spécifier car je crois qu'il est activé par défaut.
Ça permet d'utiliser le système de ressources spécifique à wxWidgets.
C'est une façon bien particulière de créer une interface graphique : la description de la fenêtre et de ses contrôles est contenue dans un fichier texte indépendant de l'exécutable.
Ça peut être pratique lorsque tu veux faire des essais pour placer tes contrôles : tu n'est pas obligé de recompiler l'exécutable car il suffit de modifier le contenu du fichier xrc et de relancer l'application.
Pour ma part, je ne l'utilise jamais, mais je le laisse activé quand je compile mes libs.

Citation:

Envoyé par Pgs

e) UNICODE : dans quel cas choisirait-on 0 ?

On ne peut plus le faire depuis wxWidgets 3

Citation:

Envoyé par Pgs

Je voudrais essayer de faire un programme autonome, sans DLL.

Il n'y a aucun problème à cela.

Citation:

Envoyé par Pgs

Est-ce que je peux lancer une compilation du Framework SHARED=0 en complément de la compilation SHARED=1 ou bien dois-je faire un clean puis une nouvelle compilation (vu que la commande clean précise elle aussi toutes les options, je serais tenté de penser que chaque option de compilation est autonome et peut coexister avec les autres).

Les deux versions peuvent cohabiter (même les 4 en tenant compte de Debug/Release).
Par contre, tu risque d'avoir un conflit de libs si tu cherches à faire cohabiter une version monolitique et une version multi-lib.
Tu trouveras un peu plus d'infos en suivant ce lien.

Citation:

Envoyé par Pgs

Si je peux avoir en parallèle une compiltation en SHARED= 1 et une complitation en SHARED = 0, me suffira-t-il alors simplement, lors de la construction du projet, de cocher/décocher "Use wxWidgets DLL" pour
générer un EXE autonome ou un ensemble EXE+DLL ?

Tu peux même imaginer commencer à coder par exemple en statique (avec tes deux configurations release/debug dans Code::Blocks).
Puis tu veux tester en mode dynamique (shared). Dans ce cas, tu duplique tes configurations et tu modifies les chemins d'accès aux libs ainsi que quelques options de compilation, et le tour est joué.

Si tu persistes à approfondir wxWidgets, tu t’apercevras qu'il est possible de faire cohabiter plein de configurations différentes.
Et si tu ne veux tester sans t’embêter à tout compiler, tu peux utiliser les libs que je mets à disposition sur le site dont je t'ai passé le lien ci-dessus.

Par exemple, sur mon pc perso, j'ai pour chaque installation de wxWidgets (wx-3.0.2 et wx-3.1.0) 16 configurations différentes permettant de couvir tous les cas de figures pou rles paramètres suivants :
- SHARED=0 et SHARED=1
- BUILD=release et BUILD=debug
- 32 bits et 64 bits
- MinGW et Visual C++
Voilà.
C'est un peu long comme explications, mais je voulais être le plus précis possible.

@+
Xav'
09/02/2016, 11h52
Pgs

Xav',

Merci pour tes explications précises. J'irai regarder X@v's wxStuff pour approfondir.

* si j'ai bien compris, tu es en MONOLITHIC=0. C'est ça ? Pour savoir quelles DLL copier avec l'EXE, il faut le lancer et voir quelles DLL ne sont pas trouvées. C'est également ça ?
* en SHARED =0, quel est l'impact de l'option MONOLITHIC ?

Citation:

Tu peux même imaginer commencer à coder par exemple en statique (avec tes deux configurations release/debug dans Code::Blocks).
Puis tu veux tester en mode dynamique (shared). Dans ce cas, tu duplique tes configurations et tu modifies les chemins d'accès aux libs ainsi que quelques options de compilation, et le tour est joué.

J'ai pour l'instant compilé SHARED=1.
J'avais cru comprendre qu'il me suffirait de compiler en plus en SHARED=0 puis, lors de la fabrication du projet, de cocher/décocher "Use wxWidgets DLL".
Mais tu évoques le fait de modifier le chemin d'accès aux lib...

Philippe
09/02/2016, 13h05
wxXav

Citation:

Envoyé par Pgs

* si j'ai bien compris, tu es en MONOLITHIC=0. C'est ça ?

Oui, c'est ça. Je trouve ça "plus sain" (mais ce n'est que mon avis).
De plus, la version Monolitique demande plus de ressources système lors de la compilation.
Par exemple, je suis actuellement en train de tester la compilation pour les libs officielles 3.1.0 et en même temps pour celles que je fourni, et il est impossible de compiler la version "Shared/Monolithic/Debug" avec MinGW-5.1.0 et MinGW-4.8.1 : on a un crash dû à un dépassement de mémoire.

Citation:

Envoyé par Pgs

Pour savoir quelles DLL copier avec l'EXE, il faut le lancer et voir quelles DLL ne sont pas trouvées. C'est également ça ?

C'est une façon de faire.
Après, tu peux utiliser un utilitaire comme "Dependency Walker" qui te permet d'obtenir toute la liste des dll nécessaires à ton application pour tourner.

Citation:

Envoyé par Pgs

* en SHARED =0, quel est l'impact de l'option MONOLITHIC ?

C'est une bonne question : je ferais le test pour voir.

Citation:

Envoyé par Pgs

J'ai pour l'instant compilé SHARED=1.
J'avais cru comprendre qu'il me suffirait de compiler en plus en SHARED=0 puis, lors de la fabrication du projet, de cocher/décocher "Use wxWidgets DLL".
Mais tu évoques le fait de modifier le chemin d'accès aux lib...

Je n'ai plus pensé au fait que sous Code::Blocks, il y a un assistant pour ajouter une nouvelle configuration (build target).
Je partais du principe que le projet est déjà en place, et qu'il faut basculer en mode statique ou ajouter cette possibilité. manuellement.

@+
Xav'
09/02/2016, 13h21
Pgs

Merci encore pour tout !

Je viens de créer un programme avec un menu déroulant qui, à chaque sélection, modifie le contenu d'un champ d'édition de texte ! Quel programme !!

Juste une question : si je transmet à quelqu'un un programme (par exemple compilé en statique), peut-il le décompiler et lire le code, ou bien ai-je le moyen de protéger un programme ?

Philippe
09/02/2016, 13h33
wxXav

Citation:

Envoyé par Pgs

Je viens de créer un programme avec un menu déroulant qui, à chaque sélection, modifie le contenu d'un champ d'édition de texte ! Quel programme !!

Comme tu dis : Microsoft dervait faire gaffe, la concurrence arrive ;-)
Il n'empêche que c'est en faisant des bricoles de ce genre que tu pourras apprendre (et galérer avant de trouver certaines solutions :mouarf: ).

Citation:

Envoyé par Pgs

Juste une question : si je transmet à quelqu'un un programme (par exemple compilé en statique), peut-il le décompiler et lire le code, ou bien ai-je le moyen de protéger un programme ?

Non : il pourra tout au plus le désassembler mais en aucun cas il n'obtiendra ton code source.
Après, pour ce qui est de la protection réelle d'un programme, il n'y en a pas beaucoup (voir pas du tout) que ne soit piratable.
Tout dépend de quel niveau de protection du recherches.

@+
Xav'
09/02/2016, 13h58
Pgs

Ce que je veux surtout, c'est que ce ne soit pas l'auberge espagnole.

Je voudrais pouvoir réserver certaines fonctions aux utilisateurs ayant les codes correspondants (et donc présents dans les if() du code).

S'il est trop facile de récupérer ces valeurs en "ouvrant" l'exécutable, cela ne sert plus à rien.

Qu'en penses-tu ? Puis-je considérer cette éventualité comme peu probable ?

Par ailleurs, j'ai été surpris par le point suivant : j'ai un fort taux de compression en zippant l'exécutable : 50%. C'est logique ?

Philippe