#1 Le 31/10/2006, à 09:39
- Bogoris
[Résolu] Problème avec la compilation de Code::Blocks
Bonjour .
Étant donné qu'il n'y a plus de paquets Debian sur leur site (et que de toutes manière l'ancien n'a pas supporté la transition vers Edgy), j'aimerais compiler Code::Blocks.
J'ai déjà fait quelques recherches sur ce forum qui m'on amené à cette page :
Installer CodeBlocks sur Ubuntu 5.10 Breezy
Malheureusement, à un moment j'arrive à ça :
bogoris@bogoris-desktop:~/codeblocks-1.0rc2$ ./bootstrap
Autoconf 2.50 or above is required. Aborting build...
J'ai pourtant installé autoconf 2.60-1 via Synaptic, et ait même fait un reboot (on sait jamais :-° ), mais toujours le même message.
Je n'ai jamais vraiment réussi à compiler un logiciel en console auparavent donc si quelqu'un pouvais m'aider ce serait sympa .
Merci d'avance,
Bogoris
[EDIT 2006/10/31 10:05]En suivant la méthode du site officiel (compiler les sources du SVN), j'obtiens :
bogoris@bogoris-desktop:~/devel/trunk$ ./bootstrap
./bootstrap: 59: libtoolize: not found
[/EDIT]
[EDIT 2006/10/31 22:39]
Problème résolu.
On peut trouver un paquet pour Ubuntu Dapper ici.
Il marche aussi pour Edgy.
[/EDIT]
Dernière modification par Bogoris (Le 31/10/2006, à 22:41)
Hors ligne
#2 Le 31/10/2006, à 10:50
- baltimore
Re : [Résolu] Problème avec la compilation de Code::Blocks
Malheureusement, à un moment j'arrive à ça :
bogoris@bogoris-desktop:~/codeblocks-1.0rc2$ ./bootstrap Autoconf 2.50 or above is required. Aborting build...
J'ai pourtant installé autoconf 2.60-1 via Synaptic, et ait même fait un reboot (on sait jamais :-° ), mais toujours le même message.
Quand tu fais un `locate autoconf`, le path du binaire est-il dans ton PATH ?
Sinon ajoute le à ton PATH.
[EDIT 2006/10/31 10:05]En suivant la méthode du site officiel (compiler les sources du SVN), j'obtiens :
bogoris@bogoris-desktop:~/devel/trunk$ ./bootstrap ./bootstrap: 59: libtoolize: not found
[/EDIT]
Ceci est le meme probleme, libtoolize etant une partie de la suite Autotools.
Baltimore ~~ Secrétaire de l'association Prologin
Prologin ~~ Concours National d'Informatique ~~ www.prologin.org
Hors ligne
#3 Le 31/10/2006, à 11:47
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
D'abord merci d'avoir répondu .
Donc, lorsque je fais :
bogoris@bogoris-desktop:~$ locate autoconf
J'obtiens :
/usr/share/gtk-doc/html/ximian-connector/ximian-connector-autoconfig.html
/usr/src/linux-headers-2.6.17-10/include/linux/autoconf.h
/usr/src/linux-headers-2.6.17-10-generic/include/linux/autoconf.h
Dois-je installer autotools-dev ?
Dernière modification par Bogoris (Le 31/10/2006, à 11:48)
Hors ligne
#4 Le 31/10/2006, à 12:01
- baltimore
Re : [Résolu] Problème avec la compilation de Code::Blocks
Si le locate ne te renvoie que ça, tu n'as pas les binaires Autotools (automake, autoconf, libtoolize, ...).
Fais un apt-get de ces binaires, pas forcément en dev.
Une fois fait, dis nous si ca marche
Baltimore ~~ Secrétaire de l'association Prologin
Prologin ~~ Concours National d'Informatique ~~ www.prologin.org
Hors ligne
#5 Le 31/10/2006, à 12:32
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
Je fais donc
apt-get install autoconf automake libtool
(pas de libtoolize )
autotools-dev est une dépendance de automake...
J'attends juste l'installation et j'essaye juste après.
J'ai donc, comme indiqué sur la page citée plus haut :
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
configure.in: installing `./install-sh'
configure.in: installing `./missing'
src/build_tools/autorevision/Makefile.am: installing `./depcomp'
Je supprime donc tout comme indiqué sur le site, je re-télécharge les sources à partir du svn avec :
svn checkout svn://svn.berlios.de/codeblocks/trunk
Puis je fais :
fromdos *.*
fromdos bootstrap
chmod +x bootstrap
Le terminal retourne :
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
configure.in: installing `./install-sh'
configure.in: installing `./missing'
src/build_tools/autorevision/Makefile.am: installing `./depcomp'
Je fais :
./configure
J'obtiens :
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gawk... (cached) mawk
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking how to recognise dependent libraries... pass_all
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking for unistd.h... (cached) yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for working volatile... yes
checking whether closedir returns void... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for working memcmp... yes
checking whether lstat dereferences a symlink specified with a trailing slash... yes
checking whether stat accepts an empty string... no
checking for vprintf... yes
checking for _doprnt... no
checking for atexit... yes
checking for getcwd... yes
checking for isascii... yes
checking for memchr... yes
checking for memmove... yes
checking for memset... yes
checking for strcasecmp... yes
checking for strchr... yes
checking for strcspn... yes
checking for strdup... yes
checking for strrchr... yes
checking for strstr... yes
checking for dlopen in -ldl... yes
checking for pthread_create in -lpthread... yes
checking for snprintf... yes
checking for vsnprintf... yes
checking whether to enable debugging... no
checking whether to build the source formatter plugin... yes
checking whether to build the autosave plugin... yes
checking whether to build the class wizard plugin... yes
checking whether to build the code completion plugin... yes
checking whether to build the compiler plugin... yes
checking whether to build the debugger plugin... yes
checking whether to build the default MIME handler plugin... yes
checking whether to build the scripted wizard plugin... yes
checking whether to build the to-do plugin... yes
checking whether to build the contrib plugins... no
checking if the compiler supports precompiled headers... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GTK2... configure: error: Package requirements (gtk+-2.0 >= 2.0.0) were not met:
No package 'gtk+-2.0' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables GTK2_CFLAGS
and GTK2_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
J'installe donc libgtk2.0-dev.
Y'a de l'amélioration quand je refaits ./configure :
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gawk... (cached) mawk
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking how to recognise dependent libraries... pass_all
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking for unistd.h... (cached) yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for working volatile... yes
checking whether closedir returns void... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for working memcmp... yes
checking whether lstat dereferences a symlink specified with a trailing slash... yes
checking whether stat accepts an empty string... no
checking for vprintf... yes
checking for _doprnt... no
checking for atexit... yes
checking for getcwd... yes
checking for isascii... yes
checking for memchr... yes
checking for memmove... yes
checking for memset... yes
checking for strcasecmp... yes
checking for strchr... yes
checking for strcspn... yes
checking for strdup... yes
checking for strrchr... yes
checking for strstr... yes
checking for dlopen in -ldl... yes
checking for pthread_create in -lpthread... yes
checking for snprintf... yes
checking for vsnprintf... yes
checking whether to enable debugging... no
checking whether to build the source formatter plugin... yes
checking whether to build the autosave plugin... yes
checking whether to build the class wizard plugin... yes
checking whether to build the code completion plugin... yes
checking whether to build the compiler plugin... yes
checking whether to build the debugger plugin... yes
checking whether to build the default MIME handler plugin... yes
checking whether to build the scripted wizard plugin... yes
checking whether to build the to-do plugin... yes
checking whether to build the contrib plugins... no
checking if the compiler supports precompiled headers... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GTK2... yes
checking for wx-config... no
configure: error:
wxWidgets must be installed on your system.
Please check that wx-config is in path, the directory
where wxWidgets libraries are installed (returned by
'wx-config --libs' or 'wx-config --static --libs' command)
is in LD_LIBRARY_PATH or equivalent variable and
wxWindows version is 2.6.0 or above.
Dernière modification par Bogoris (Le 31/10/2006, à 12:54)
Hors ligne
#6 Le 31/10/2006, à 12:57
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
j'installe donc wx2.6-headers... mais j'obtiens la même chose (j'avais déjà installé wx-common).
Euh... je vais manger -_-"
Hors ligne
#7 Le 31/10/2006, à 12:59
- baltimore
Re : [Résolu] Problème avec la compilation de Code::Blocks
Euh oui, désolé pour libtoolize, erreur d'inattention : le binaire est libtool.
Apparemment, il necessite beaucoup de paquets Code::Blocks !
Il faut maintenant install wxWidgets. Je ne suis pas sur que le paquet Debian existe, sinon va sur leur page http://www.wxwidgets.org.
Bon courage
Baltimore ~~ Secrétaire de l'association Prologin
Prologin ~~ Concours National d'Informatique ~~ www.prologin.org
Hors ligne
#8 Le 31/10/2006, à 13:28
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
En fait j'ai installé libwxbase2.6-dev (en ayant déjà libwxbase2.6 d'installé), et là, ô miracle :
# un tas de trucs puis :
*************************************************
* Code::Blocks source tree has been configured. *
*************************************************
You can now build Code::Blocks by issuing 'make'.
When the build is complete, become root and install
it by issuing 'make install'.
Mais en fait c'est pas fini, j'ai encore des erreurs:
make[2]: *** [sdk.h.gch] Erreur 1
make[2]: quittant le répertoire « /home/bogoris/devel/trunk/src/sdk »
make[1]: *** [install-recursive] Erreur 1
make[1]: quittant le répertoire « /home/bogoris/devel/trunk/src »
make: *** [install-recursive] Erreur 1
Bon, je vais aller voir sur le site de la wxWidgets...
Dernière modification par Bogoris (Le 31/10/2006, à 13:41)
Hors ligne
#9 Le 31/10/2006, à 14:09
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
Tiens, ça par exemple : je viens de trouver un paquet compilé sur Ubuntu Dapper ici o_O .
Ah... quand on sait chercher, c'est sûr, on trouve plus vite...
Hors ligne
#10 Le 31/10/2006, à 15:02
- Piwaï[INSA]
Re : [Résolu] Problème avec la compilation de Code::Blocks
Hum... c'est cool mais... Et quand on vient d'installer edgy ???
Aaaaahaha !!
Et il ne semble pas yavoir de packages egdy dans le lot...
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#11 Le 31/10/2006, à 22:39
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
Je suis sous Edgy.
En fait j'avais déjà un paquet pour Dapper (ou Debian je sais plus) mais il n'a pas supporté la transition vers Edgy (allez savoir pourquoi...).
Hors ligne
#12 Le 01/11/2006, à 09:12
- Piwaï[INSA]
Re : [Résolu] Problème avec la compilation de Code::Blocks
Tiens, ça par exemple : je viens de trouver un paquet compilé sur Ubuntu Dapper ici
o_O o_O ??
Heu, tu as réussi à l'installer sous Edgy avec le paquet Dapper ??
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#13 Le 01/11/2006, à 16:06
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
Bah oui, pourquoi pas ?
On utilise bien parfois des paquets Debian sous Ubuntu...
Hors ligne
#14 Le 01/11/2006, à 16:43
- Piwaï[INSA]
Re : [Résolu] Problème avec la compilation de Code::Blocks
Ok; j'osai po tester... ya po trop de bugs ? vé l'installer...
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#15 Le 02/11/2006, à 11:09
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
Moi pas de bug, non.
Par contre c'est vrai que ça fonctionne pas tout le temps : j'avais un paquet Debian de Frostwire qui fonctionnait avant et qui ne fonctionne plus maintenant .
Hors ligne
#16 Le 03/11/2006, à 01:29
- zedtux
Re : [Résolu] Problème avec la compilation de Code::Blocks
Bon moi j'arrive tout doucement à compiler ce ........ soft...
J'ai du installer tout ce qui est dis plus haut + wx-common.
Le bootstrap ne m'as donné aucun message.
Derriere le ./configure à marché au poile.
Et là je suis sur le make...
P.S: Je suis sur Edgy 64bits
Dernière modification par zedtux (Le 03/11/2006, à 01:29)
RECOLLER VOS FICHIERS XTM AVEC TUXTREMSPLIT !!
Adhérant April numéro 4985 [Rejoindre l'April moi aussi !].
Hors ligne
#17 Le 03/11/2006, à 01:45
- zedtux
Re : [Résolu] Problème avec la compilation de Code::Blocks
Ok, la compilation à marché nickel !
Mais ce fut long !!
RECOLLER VOS FICHIERS XTM AVEC TUXTREMSPLIT !!
Adhérant April numéro 4985 [Rejoindre l'April moi aussi !].
Hors ligne
#18 Le 03/11/2006, à 11:21
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
T'en as de la chance toi .
Hors ligne
#19 Le 03/11/2006, à 13:16
- Piwaï[INSA]
Re : [Résolu] Problème avec la compilation de Code::Blocks
Quand a moi, j'ai du mal a charger un projet Code::Blocks (créé sous win, et version RC2). Il me le charge bien au final, sauf que les fichiers (.cpp et .h) sont vides...
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#20 Le 03/11/2006, à 13:33
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
C'est étrange ça... tu es sûr que tu as bien reproduit l'arborescence par rapport au fichier cbp ?
Hors ligne
#21 Le 03/11/2006, à 18:18
- Piwaï[INSA]
Re : [Résolu] Problème avec la compilation de Code::Blocks
je pense que c'est a ce niveau la que ca foire. je n'ai rien reproduit du tout, j'ai juste fait charger le fichier cbp par code::blocks
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#22 Le 03/11/2006, à 19:20
- Bogoris
Re : [Résolu] Problème avec la compilation de Code::Blocks
Bah si tu n'as pas les fichiers .c et .h au bon endroit, ça paraît un peu logique aussi...
Normal que Code::Blocks ne puisse pas les trouver quoi .
Dernière modification par Bogoris (Le 03/11/2006, à 19:21)
Hors ligne
#23 Le 03/11/2006, à 19:28
- Piwaï[INSA]
Re : [Résolu] Problème avec la compilation de Code::Blocks
:s si si . Je dis simplement que j'ai ouvert le .cdb avec Code::blocks , il est au bon endroit et tout, ca marche niquel sous Win .
Pour tester (:p) ?
->
svn co https://svn.sourceforge.net/svnroot/toohardforyou toohardforyou
.. Je sais pas pourquoi il me montre pas les fichiers ..
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne
#24 Le 04/11/2006, à 00:23
- zedtux
Re : [Résolu] Problème avec la compilation de Code::Blocks
Et pour en faire un paquage deb ??? Comment faire ??
Car le recompiler sous edgy 64, ca me saoul
RECOLLER VOS FICHIERS XTM AVEC TUXTREMSPLIT !!
Adhérant April numéro 4985 [Rejoindre l'April moi aussi !].
Hors ligne
#25 Le 04/11/2006, à 09:12
- Piwaï[INSA]
Re : [Résolu] Problème avec la compilation de Code::Blocks
lool
http://www.piwai.info
Découvrez 2H4U (Too Hard For You) : http://www.sourceforge.net/projects/toohardforyou
et OpenGF : http://www.sourceforge.net/projects/opengf
Hors ligne