November 1999 - Gpc

Re: Problem with strings in record imported/exported from/to modules
by Frank Heckenbach 20 Nov '99

20 Nov '99

David James wrote: > I'm having problems with a string in a record that is exported > from one module and imported into another. I *hope* I am doing > something stupid! > > The maodule (dajmod3.pas) and main program (daj3.pas) below > should illustrate the problem. > > [...] This seems to be another innstance of a known bug with string types. Thanks for the report and the test program which I'm adding to the test suite. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 20 Nov '99

20 Nov '99

In message <214E52CA.19991120140550.FOO-4F71.frank(a)g-n-u.de> Frank Heckenbach writes: > David James wrote: > > > I'm having problems with a string in a record that is exported > > from one module and imported into another. I *hope* I am doing > > something stupid! > > [...] > > This seems to be another innstance of a known bug with string types. > Thanks for the report and the test program which I'm adding to the > test suite. Any ideas on whether this is likely to be fixed soon? or whether there are any reasonable work-arounds? The application I am trying to port uses shared memory to share data between multiple processes (running for different users). The shared memory is handled as a large (>200 kbyte) Pascal record with the definition of the record and the procedures to handle the data structure being defined and exported in a module and imported by nearly all the rest of the system. This bug looks rather like a showstopper for my application. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Re: -x lang and .PAS extension
by Frank Heckenbach 19 Nov '99

19 Nov '99

Dr A Olowofoyeku wrote: > One option for dealing with this is for gpc.exe to convert the filename > to lowercase before passing it on (only on systems such as Win32 > and Dos which do not care about the case of filenames). Another option would be to recognize '*.PAS' as Pascal files. This could be done on every system and would prevent a (small) problem when, say, unpacking a zip file created on Dos with capital file names on a Unix machine... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: -x lang and .PAS extension
by Alexandre Oliva 19 Nov '99

19 Nov '99

On Nov 18, 1999, "Dr A Olowofoyeku" <laa12(a)keele.ac.uk> wrote: >> % gpc FOO.PAS > One option for dealing with this is for gpc.exe to convert the filename > to lowercase before passing it on I don't think this is a good idea. Case matters even on MS-DOS based systems; think of .C (implies -x c++) and .c (implies -x c). Of course, GPC could recognize .PAS and .Pas as pascal extensions, but I don't see any need for it, as long as -x pascal works. > I can send you a diff for gpc.c if you want Thanks, but it was just a week-end issue. Thanks God now I'm back to real operating systems :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

-x lang and .PAS extension
by Alexandre Oliva 19 Nov '99

19 Nov '99

Hi! I've recently had the unfortunate opportunity of having to invoke gpc/cygwin from a compiling/testing engine that used only MS-DOS file names (i.e., all-caps 8.3). (if anybody cares, it was University of California at San Diego's PC^2, an ACM Programming Contest management program) The problem was that, when invoking gpc, the program used the .PAS extension, which gpc didn't recognize as a valid source file, and passed it to the linker. % gpc FOO.PAS /n/gnu/gcc-2.95.2-gpc-19991030-libg++-2.8.1.3-libgcj-2.95.1/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/real-ld:FOO.PAS: file format not recognized; treating as linker script /n/gnu/gcc-2.95.2-gpc-19991030-libg++-2.8.1.3-libgcj-2.95.1/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/real-ld:FOO.PAS:1: parse error collect2: ld returned 1 exit status No problem, I though, I just need to insert `-x pascal' before the source filename, as I had done in the gcc and g++ compiling scripts. Unfortunately, it failed too: % gpc -x pascal FOO.PAS gpc: Internal GPC problem: internal option `--amtmpfile' not given I ended up having to write a shell-script that would convert the extension to lower case, so it wasn't a show-stopper. Anyway, I believe it would be nice if gpc were more gcc-like, in the sense of accepting `-x' (and any other flags gcc accepts, for that matter). Cheers, -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

2 1

Re: What do you want to have fixed/implemented in gpc-2.1?
by Frank Heckenbach 18 Nov '99

18 Nov '99

On Tue, 19 Oct 1999 Peter wrote: Hello, folks! : We are approaching a version of GPC that will (a) compile with : gcc-2.95.x and (b) only need minimal patches to the GCC backend. : : With the next version of the GNU Compiler Collection (GCC), we want : to publish the long-expected gpc-2.1 as a fully integrated frontend. : We expect this next GCC release (2.9x or 3.0) to happen within the next : two months or so. : : It is not realistic to fix all bugs and to implement all wanted features : listed in the GPC TODO list (http://fjf.gnu.de/gpc-todo_toc.html) within : this time schedule. However, most of the bugs listed there are not : really relevant to real-world praxis. So we are planning to re-sort the : TODO list and to focus on the most important bugs and feature requests. : : Please tell us which bugs and/or missing features on the TODO list, : section "Urgent", you consider the most urgent. : : And of course, your help to fix those bugs is welcome. Based of the feedback we have received, I have updated the To-Do list which will hopefully enable us now to produce a GPC 2.1 fully integrated into GCC soon. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 6

Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 17 Nov '99

17 Nov '99

I'm having problems with a string in a record that is exported from one module and imported into another. I *hope* I am doing something stupid! The maodule (dajmod3.pas) and main program (daj3.pas) below should illustrate the problem. This is on a system which identifies itself as Eridani / Red Hat Linux 6.0 (Hedwig) Kernel 2.2.5-15 on an i586 The output of gpc -v is Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 19991030, based on 2.95.2 19991024 (release) daj3.pas: ======== program daj3(output); import globaltypes in 'dajmod3.pas'; globalvars in 'dajmod3.pas'; begin shared_data.prefix:='ABCD'; if (shared_data.prefix='ABCD') then writeln('OK') else writeln('failed ',shared_data.prefix,'|'); end. dajmod3.pas: =========== module dajmod3 interface; export globaltypes =(astring); globalvars =(shared_data); TYPE astring=string(255); VAR shared_data : record prefix:astring; end; end. {of module header} module dajmod3 implementation; end. {of module implentation}

1 0

32-bit dll in GNU Pascal
by Joanna Owczarzak 17 Nov '99

17 Nov '99

Hi! I generated 32-bit dll in GNU Pascal. I used examples from GNU Pascal. My new functions (added to that example) work with *.exe program (that program was in examples too) which uses that dll. But when I'm trying to run function from my dll in my program written in Power Builder 6.0 I get message:"Error opening dll library testdll.dll for external function" Thanks in advance. Joanna

2 1

Re: native building of gpc 19991030 / gcc 2.95.2 for djgpp
by Frank Heckenbach 16 Nov '99

16 Nov '99

Maurice Lombardi wrote: > I succeeded in this native building with only one change to gpc sources due to a > DOS peculiarity. > The problem comes from the following lines contained (at two different > locations) in p/Make-lang-2.95.in > > CC="`echo $(GCC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e > 's,^$[^/][^ ]*$,../../\1,'`" \ > PC="`echo $(GPC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e > 's,^$[^/][^ ]*$,../../\1,'`" \ > > It means that to go the to rts subdirectory it prepends ../.. to G?C_FOR_TARGET > if this is a relative, not an absolute directory name. Absolute is recognized by > the first character being a slash. However in DOS an absolute pathname starts > with a drive letter c:/ In particular GCC_FOR_TARGET is in my case an absolute > pathname built through `pwd` in the top makefile, which gives the drive letter. > Solutions could be > - saying that an absolute pathname has either / as first character or : as > second. Can be garbled by a unix relative path starting with d: is this possible > in this context? This gives the attached notroot.dif > - saying that a relative pathname starts by ./ or ../ This is what occurs for > GPC_FOR_TARGET. Can be garbled if the relative path starts with an ordinary > character, is this possible in this context? This gives the attached > relative.dif. > You can incorporate one of these solutions (or a better you may imagine) into > the gpc sources, or let the djgpp maintainers to make the patch only for djgpp > (and probably other DOS systems). The last solution would mean however the need > to modify the patch for each new gpc alpha or beta distribution, so that the > first is highly preferred. As you say, it can garble unix paths starting with `d:', and also (Unix and Dos) paths consisting of only 1 letter, in particular `.'. I don't know the build process of gcc-2.95 well, so I don't know if these are possible in this context, but it's possible to modify the substitution so as to recognize 1-letter paths. The following should do the trick, but is *untested*: 's,-B$[^/]\([^:].*$\?\)$$,-B../../\1,g' (The double `$' is necessary when using it in a Makefile.) Furthermore, in order to restrict the change only to Dos systems, I suggest the following: - Make the substitution (the string above) a make variable. - Set it to the Unix substitution by using an assignment in the Makefile. - Make sure the variable is transported to sub-makes (see GPC_FLAGS_TO_PASS, GPC_INSTALL_FLAGS_TO_PASS). - When building under Dos, you can override the value on the command line (takes precedence over assignments in the Makefile). You can put this in a batch file or whatever you use to invoke make. - Alternatively, you can hack config-lang.in to add this value automatically on Dos systems, but I can't give you any advice about this, since I don't know this stuff well. > For those interested to internals of djgpp. The beta bash version enables (when > setting PATH_EXPAND=N) pwd to output /dev/c/ instead of c: to have a more > unix-like behavior, which seems to solve the above problem. Bash understands > command lines starting with /dev/c/bin/something.exe but DOS (command.com) does > not understand ! Now, as explained to me by Eli Zaretskii to solve an other > hairy problem, the djgpp port of Make sends command lines to bash only if he > thinks that the shell is involved, and to COMMAND.COM otherwise (to save > overhead). He recognizes that the shell is needed if the make line includes > something which belongs to the shell, which could be a simple ; at the end of > the makefile line. I have tried to build with PATH_EXPAND=N, it stops building > the rts at the first command line > $(GCC_FOR_TARGET) so so > When adding a ; at the end of that makefile line, make goes somewhat further, > but stops at the next occurrence, which shows that this is indeed the problem. > Now is the overhead in make large enough to warrant all these inconveniences? I'm not sure, though I would guess not, as far as GPC's build process is concerned. But if I understood you right, there's nothing we can do about it anyway, because that happens to be make's behaviour under DJGPP, doesn't it? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

New bug in GPC 19991030 ?
by Maurice Lombardi 16 Nov '99

16 Nov '99

Hi all, While running demos and tests on the newly built GPC 1991030 / gcc-2.95.2 for djgpp I have found two occurences of the same bug. They are in test/goto4.pas and demos/parserdemo.pas Error message is (for parserdemo) f:/djgpp/tmp\ccbqrrbj.s: Assembler messages: f:/djgpp/tmp\ccbqrrbj.s:2010: Error: operands given don't match any known 386 instruction The offending instruction is movl $L177,$__p_MPNGHS eliminating the second $ to give movl $L177,__p_MPNGHS manual assembly and linking gives the correct result. Is this reproducible on other systems ? Has it something to do with new assembly errors generated by gcc-2.95 ? Hope this helps Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1