Olivier PECHEUX wrote:
Dimitri, tu dis :ça marche. Chez Maurice, ça marche. (unité crt).
Chez moi, ça ne marche que la première fois. Ce que j'ai fait:
- j'ai chargé le curse23.zip (indiqué par Maurice).
- j'ai supprimé le specs et le djgpp.djl
- j'ai modifié le djgpp.env (indiqué par Olivier = moi)
_ j'ai tapé le programme:
program efface; uses crt; begin clrscr; readln end.
Quand je compile la première fois, tout se passe bien, et le programme fonctionne. Si je compile une deuxième fois, je retrouve le messsage undefined reference to crt_clrscr. Dans mon répertoire de travail, j'ai les fichiers gpc.o gpc.gpi crt.o crt.gpi et crtc.o . le fichier crtc.o contient bien la procédure crt_clrscr (vue par nm -O crtc.o >crtc.lst). Si je supprime lun des trois fichiers crt.gpi gpc.gpi ou crt.o , la compilation fonctionne à nouveau.
I must admit that I don't really speak French, but as far as I can understand, you can compile a program that uses CRT once succesfully, but not twice. Yes, this is a known problem with GPC's `automake' under DJGPP, and it affects all units, not just CRT. We'll try to fix it soon, but until then, you'll probably have to delete crt*.o before each compilation, or use the `--autobuild' switch. Both will force CRT to be recompiled, and then the problem does not appear.
Dans le fichier crtdummy.c (dans units), il est dit:
- add a statement to #include that file, together with suitable #ifdefs
in crtc.c
This statement only refers to those who want to port CRT to a new system (say, mingw). If you just want to use CRT under DJGPP, you don't need to worry about it.
The link to the last djgpp version of gpc in the directory gnu-pascal/djgpp on agnes is not correct: instead of gpc20bb -> ../binary/gpc-19990530-i386-pc-djgppv202.zip it should be gpc20bb -> ../beta/binary/gpc-19990530-i386-pc-djgppv202.zip
Quel est le nom exact complet? Dans ftp://agnes.dida.physik.uni-essen.de/gnu-pascal je ne vois pas de djgpp. le gpc20bb.zip que j'ai pris est tiré de : ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/binary/gpc-19990430-i386-pc-djgppv202.zip . Ai-je pris le mauvais fichier?
The `19990530' was a typo. 19990430 is the correct name of the last binary release for DJGPP.
To overwrite such a builtin specs, provide a new one in a rhide.env file (either the global one in %DJDIR%/share/rhide/ or a local one in the current directory). In you specific task you should place a line like the following:
RHIDE_COMPILE_LINK_GPC_AUTOMAKE=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) -o $(OUTFILE) -automake $(RHIDE_GPC_FLAGS) $(SOURCE_NAME) $(LIBRARIES) $(LDFLAGS) $(RHIDE_LDFLAGS) $(RHIDE_LIBS)
(NOTE here, this should be all ONE long line!!!)
J'ai effectivement bien la spec indiquée. Je ne commprends pas bien ce que je dois faire avec la fameuse ligne. Je l'ai mise seule dans un fichier rhide.env mis dans les deux répertoires indiqués sans aucun changements.
I'm not sure if I understand you correctly here, but if your problem is that there is no rhide.env file, then just create it in one of the directories mentioned, and put just this one line into it.
I just tried it under Linux with the following line (note: the `$(LIBRARIES)' and `$(RHIDE_LIBS)' are also omitted because GPC cares about the libraries itself), and it seemed to work:
RHIDE_COMPILE_LINK_PASCAL_AUTOMAKE=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) $(RHIDE_LDFLAGS) -o $(OUTFILE) --automake $(RHIDE_GPC_FLAGS) $(SOURCE_NAME) $(RHIDE_LDFLAGS)
Frank
-- Frank Heckenbach, frank@fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html