Gpc

gpc@gnu.de

5400 discussions

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.… [View More]

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 … [View More]

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)… [View More]

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 … [View More]

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++… [View More]

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 : … [View More]

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 (… [View More]

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,'`" \ > > … [View More]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 [View Less]

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 … [View More]

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc