Gpc August 1998

gpc@gnu.de

7 participants
18 discussions

Re[4]: trouble compiling
by Paul Doerwald 14 Aug '98

14 Aug '98

> I think it's better to continue this discussion on the list. If you agree, > be invited to bounce my mail there. Did I not reply to all? oops. You might want to update the list software so it changes the Reply-To: field to gpc(a)hut.fi -- I've made this mistake more than once... > (So do I. If only I had the time I would happily WTFM.)-: Many moons ago, I volunteered to wtfm -- I realized shortly after that I was incapable of doing so (time, and knowledge of Pascal). And since things always work better in a community effort, I made the suggestion I did... Sadly, though, I still haven't gotten anyone else's thoughts. I found a gcc-2.8.1 distribution on my computer that I had downloaded (and left in a stupid place that I never thought to look), so I unpacked that, and stuck gpc-980511 in the p directory. It detected the patch file. I suspect this will work now. (No more trying short cuts for me -- maybe in a few years when I've used Linux enough, and I'm a bit more into the programming loop -- I'm a university music student who hasn't coded actively since early high school, so I'm somewhat (read: very) out of the loop) Sorry to trouble you with all my pedantic questions... | clavicle(a)niagara.com "The LORD is my strength and my | www.niagara.com/~clavicle song; he has become my salvation." | ICQ#13902938 Exodus 15:2b

1 0

trouble compiling
by Paul Doerwald 13 Aug '98

13 Aug '98

It seems that the only reason I ever post in this list is for help compiling GPC. I've got gcc 2.8.1 and gpc-980511. These are the errors I get: (root) pollux:/usr/src/gcc-2.8.1>make LANGUAGES=pascal cd p; make "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ar" "BISON=bison" "BISONFLAGS=" "CC=gcc" "CFLAGS=-g" "CLIB=" "GCC_FOR_TARGET=./xgcc -B./" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "LN=ln -s" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "RANLIB_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/i486-pc-linux-gnu/bin/ranlib ]" "SHELL=/bin/sh" "STAGE_PREFIX=" "exeext=" "objext=.o" "exec_prefix=/usr" "prefix=/usr" "tooldir=/usr/i486-pc-linux-gnu" "bindir=/usr/bin" "libsubdir=/usr/lib/gcc-lib/i486-pc-linux-gnu/2.8.1" "CROSS=" "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ar" "BISON=bison" "BISONFLAGS=" "CFLAGS=-g" "X_CFLAGS=" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "MAYBE_TARGET_DEFAULT=" "MAYBE_USE_COLLECT2=" "RANLIB_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/i486-pc-linux-gnu/bin/ranlib ]" "SHELL=/bin/sh" "bindir=/usr/bin" "exec_prefix=/usr" "gxx_include_dir=/usr/include/! ! ! g++" "includedir=/usr/local/include" "libsubdir=/usr/lib/gcc-lib/i486-pc-linux-gnu/2.8.1" "prefix=/usr" "target_alias=i486-pc-linux-gnu" "tooldir=/usr/i486-pc-linux-gnu" "gpc_version=980511" "rts_version=2.8" "version=2.8.1" ../gpc1 make[1]: Entering directory `/usr/src/gcc-2.8.1/p' rm -f ../gpc1 gcc -DIN_GCC -DGPC -g -o ../gpc1 \ `cat stamp-gbe` ../c-aux-info.o ../c-iterate.o ../c-pragma.o ../choose-temp.o ../pexecute.o gpc-common.o gpc-convert.o gpc-decl.o gpc-lang.o gpc-lex.o gpc-typeck.o module.o gpi-hash.o circle-buf.o objects.o parse.o rts.o types.o util.o setop.o version.o `if [ xobstack.o != x ]; then echo ../obstack.o; else true; fi` `case "gcc" in "cc") if [ x != x ]; then echo ../; else true; fi ;; esac` `if [ x != x ]; then echo ../; else true; fi` gpc-common.o: In function `build_pascal_binary_op': /usr/src/gcc-2.8.1/p/gpc-common.c:2572: undefined reference to `emit_string_move' /usr/src/gcc-2.8.1/p/gpc-common.c:2587: undefined reference to `emit_string_move' gpc-decl.o: In function `grokdeclarator': /usr/src/gcc-2.8.1/p/gpc-decl.c:5924: undefined reference to `size_volatile' gpc-decl.o: In function `handle_forward_pointers': /usr/src/gcc-2.8.1/p/gpc-decl.c:9049: undefined reference to `dbxout_set_type_status' /usr/src/gcc-2.8.1/p/gpc-decl.c:9055: undefined reference to `dbxout_set_type_status' module.o: In function `execute': /usr/src/gcc-2.8.1/p/module.c:466: undefined reference to `version_flag' module.o: In function `module_must_be_recompiled': /usr/src/gcc-2.8.1/p/module.c:685: undefined reference to `version_flag' module.o: In function `compile_module': /usr/src/gcc-2.8.1/p/module.c:802: undefined reference to `version_flag' module.o: In function `load_tree': /usr/src/gcc-2.8.1/p/module.c:1799: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/module.c:1853: undefined reference to `size_volatile' parse.o: In function `yyparse': /usr/src/gcc-2.8.1/p/parse.y:1563: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/parse.y:1629: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/parse.y:4766: undefined reference to `maybe_find_function_data' rts.o: In function `build_rts_call': /usr/src/gcc-2.8.1/p/rts.c:3503: undefined reference to `emit_string_move' types.o: In function `assign_string': /usr/src/gcc-2.8.1/p/types.c:639: undefined reference to `emit_string_move' /usr/src/gcc-2.8.1/p/types.c:690: undefined reference to `emit_string_pad' types.o: In function `prediscriminate_schema': /usr/src/gcc-2.8.1/p/types.c:1056: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1058: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1089: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1092: undefined reference to `size_volatile' types.o: In function `build_pascal_pointer_type': /usr/src/gcc-2.8.1/p/types.c:1738: undefined reference to `dbxout_set_type_status' util.o: In function `handle_formal_conf_array_param_list': /usr/src/gcc-2.8.1/p/util.c:738: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/util.c:763: undefined reference to `size_volatile' util.o: In function `initialize_world': /usr/src/gcc-2.8.1/p/util.c:1816: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/util.c:1819: undefined reference to `size_volatile' make[1]: *** [../gpc1] Error 1 make[1]: Leaving directory `/usr/src/gcc-2.8.1/p' make: *** [gpc1] Error 2 Any suggestions? Paul.

2 1

an idea for documentation
by Paul Doerwald 13 Aug '98

13 Aug '98

A couple months ago, there was a big struggle on the list over the out-of-date reference manual for GPC, and people proposed suggesting changes through the list. I have another idea, and I just thought I'd run it past all of you (especially you, Peter) Since there are a few people who *really* know GPC and all its function and procedure calls, but they don't have the time to document the whole thing as well as write it, but they always had corrections to what people submitted.... What I'm thinking is an extensive, online script (I would give it a shot, in Perl) that would allow everyone to update an online version of the documentation (that would be stored in HTML). Everyone could make their own changes; if they see a little problem, they can clarify it, and expand on each others' work. I wouldn't bother with passwords and special access -- I would just have regular backups made so that if someone hit it and tried to screw it up, we'd have a good copy backed up. The HTML file could (somehow?) be translated into texi, for distribution with GPC. Is this something that would be of value? I'd be interested to hear your suggestions. Paul.

1 0

Re: Memory access...
by heckenb＠helena.hut.fi 05 Aug '98

05 Aug '98

Orlando Llanes wrote: > The question I'm about to ask pertains to the DJGPP/DOS platform, tho > it may apply to other platforms if present. How can I access mroe than 8MB > while keeping compatible with the GPC Pointer type? I ask because I tried > allocating >8MB and I got a runtime error saying that GPC is out of heap > space. I know there are DPMI functions, but which one can allocate >8MB > while still maintaining the near pointer type? Thanks in advance! Looks like a DPMI configuration issue. I just ran the following program in DosEmu succesfully, after I increased the DPMI memory size (in DosEmu, that's as simple as setting "dpmi 32768" in /etc/dosemu.conf, but I don't know how this is done in native Dos): program x; const m=33000000; type t=array[1..m] of byte; var a:^t; i:integer; begin new(a); for i:=1 to m do a^[i]:=i and $ff; for i:=1 to m do if a^[i]<>i and $ff then runerror(42); writeln('OK') end. However, I can't seem to allocate more than 32 MB in DPMI, so this might be the limit of DPMI. (Anyone knows? From other source, I sometimes hear 16 MB, sometimes 64 MB as the limit. 32 MB is just in between, so according to the usual Dos kind of logic, this might be correct... >:-) BTW, (Peter:) BP accepts "RunError" without an argument, so GPC should allow that, too. However, BP gives a "Runtime Error 0" then, which I don't like very much, since the exit status 0 usually means success. So, GPC should probably use some other error code... -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Memory access...
by Orlando Llanes 05 Aug '98

05 Aug '98

The question I'm about to ask pertains to the DJGPP/DOS platform, tho it may apply to other platforms if present. How can I access mroe than 8MB while keeping compatible with the GPC Pointer type? I ask because I tried allocating >8MB and I got a runtime error saying that GPC is out of heap space. I know there are DPMI functions, but which one can allocate >8MB while still maintaining the near pointer type? Thanks in advance! See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

1 0

compiling gpc sources in plain dos / djgpp
by Maurice Lombardi 04 Aug '98

04 Aug '98

Hi all, Sometimes ago I have seen in a message of DJ Delorie in comp.os.msdos.djgpp, saying that now djgpp with the autoconf port can build with minor modification nearly every unix program governed by configure shell scripts. I have thus retried to build gpc under plain DOS from gcc-2.8.1 and the latest alpha sources gpc-980511.tar.gz. It works indeed with very few modifications, but everything contained in the directory p/config/msdos is now outdated, the configuration for gcc has been completely changed between 2.7.2.x and 2.8.x. I give in attachment a couple of files suggested for doing the modifications automatically (a driver prepare.bat and a shell script doprepar.sh), and a couple of instruction files (install.txt for binaries, the old one only slightly updated, and readme.djgpp for sources) to be put into the p/config/msdos directory (replacing the old ones). The modifications are - a few 8.3 issues stamp-objlist -> s-objlist .gdbinit -> gdb.ini g??.info-NN -> g??.iNN (only when LFN=n) - GCC is built into the build.djgpp subdirectory of the gnu/gc-2.81 source directory, while gpc must be built into the source directory itself. - enlarge the stack for gpc1 and gpc-cpp. Done by modifying a file config/i386/x-go32 which is already used by Delorie for enlarging the stack of cc1 cc1plus and cc1obj. With these modifications (plus one below to be done in the gpc sources themselves) all compiles, and the built compiler gives the same results as the binaries contained in the distribution for everything I have tried, some private programs, test programs from bgi2grx, the gpc test and testsuite. The modification suggested to gpc sources themselves is the following While looking around in the gcc "makefile.in" I have found the following: # Install the info files. # $(INSTALL_DATA) might be a relative pathname, so we can't cd into srcdir # to do the install. The sed rule was copied from stmp-int-hdrs. install-info: doc installdirs lang.install-info -rm -f $(infodir)/cpp.i* $(infodir)/gcc.i* for f in $(srcdir)/cpp.i* $(srcdir)/gcc.i*; do \ realfile=`echo $$f | sed -e 's|.*/$[^/]*$$$|\1|'`; \ $(INSTALL_DATA) $$f $(infodir)/$$realfile; \ done -chmod a-x $(infodir)/cpp.i* $(infodir)/gcc.i* ... and in the file "make-lang.in" from gpc, we indeed cd into the srcdir, and this fails when I install in a relative directory (to see what happens without overwriting my previous binary installation of gpc). So I suggest to replace in "gpc/p/make-lan.in" the old content pascal.install-info: $(srcdir)/p/doc/gpc.info -rm -f $(infodir)/gpc.info* ; cd $(srcdir)/p/doc; for f in gpc.info*; \ do $(INSTALL_DATA) $$f $(infodir)/$$f; done -chmod a-x $(infodir)/gpc.info* by the new content pascal.install-info: $(srcdir)/p/doc/gpc.info -rm -f $(infodir)/gpc.info* ; for f in $(srcdir)/p/doc/gpc.info*; do \ realfile=`echo $$f | sed -e 's|.*/$[^/]*$$$|\1|'`; \ $(INSTALL_DATA) $$f $(infodir)/$$realfile; \ done -chmod a-x $(infodir)/gpc.info* The doprepar.sh will take care of info* -> i* afterwards, only for the dos/LFN=no case. I have checked thas this works. Finally I have taken the .tar.gz sources untarred by the djtar utility. For .zip sources there remain a couple of problems to be solved: .gdbinit is ignored by pkzip and extracted as _.gdb by infozip. The extraction as _gdbinit done by djtar is supposed in the doprepar.sh script. in gpc-980401.zip I have tried, the info files have the long names gpc.info-NN, which cause problem both with pkunzip and infozip. This is also the case in the .tar.gz archive, but djtar takes care of this, by translating them to gpc.iNN, when LFN=no. The simplest workaround is probably not to include these files, since they are rebuilt easily from texi sources. the gpc diff filenames gpc-2.8.0.diff and gpc-2.8.1.diff are extracted by djtar as gpc-2.8-0 and gpc-2.8-1, which is fine for doprepar.sh, while infozip extract both as gpc-2_8_.dif (and barks for overwriting). This has no importance for alpha or beta stages, where you can supply only .tar.gz files, but needs to be solved when releasing an official version (everything is in zip format in the djgpp archives). Hope this helps. -- 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 @echo off echo ... starting from p/config/msdos directory: pwd echo ... going to gcc source dir: cd ..\..\.. pwd echo ... running doprepar shell script sh p\config\msdos\doprepar.sh

1 0

DiskSize and DiskFree
by heckenb＠helena.hut.fi 03 Aug '98

03 Aug '98

Hi! I just implemented some routines of BP's Dos unit in a portable way. Some of them are too Dos specific to be done portably, but most of the others are implemented. What is a bit problematic is the functions DiskSize and DiskFree which return the total or free space of a disk volume (mounted file system), respectively. The only routine I found to implement them with is statfs() which is unfortunately not standardized. E.g. Linux and DJGPP have compatible statfs()'s, but Solaris' one is a little different and deprecated in favour of statvfs() which isn't present on the former two systems. I don't know what it's like on other systems. Then I looked at the source code of df(1) which gets this information, and it's full of ifdefs and other nice things which confirms my guess that there's no portable way. So, I see only the following possibilities: - Not implement these routines in the Dos unit at all. - Implement them only for some known systems via ifdefs -- which would be Linux, DJGPP and Solaris for me, and perhaps other people will add support for other systems. - Test for some known functions (e.g. statfs() with the Linux/DJGPP arguments and statvfs() as found in Solaris) from GPC's RTS configure, and put a little system-independent wrapper into the RTS. (Advantage compared to the previous suggestion: configure is more general than ifdefs and can support systems I don't even know about if they have a compatible routine. Disadvantage: adding support for other systems requires changing the RTS, not only a unit.) - Pipe the output of df(1) and extract the information from that (not so seriously...) Any suggestions how to go ahead, or perhaps even better suggestions than the above? Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Documentation: AsmName...
by Orlando Llanes 01 Aug '98

01 Aug '98

@node asmname @unnumberedsec asmname @cindex asmname (Modified) @unnumberedsubsec Syntax @smallexample Var MyVar : asmname 'ExternalName' @var{some type}; Procedure MyProcedure; asmname 'externalproc'; Procedure MyProcedure( MyParam1 : @var{some type} ); asmname 'externalproc'; Function MyFunction: @var{some type}; asmname 'externalfunc'; @end smallexample @unnumberedsubsec Description @samp{asmname} allows one to access variables, functions, and/or procedures compiled externally. The difference between @samp{asmname} and @samp{C} is that ASMName sets the name of the procedure to one that will be recognized by the linker. @unnumberedsubsec Standards @unnumberedsubsec Example @unnumberedsubsec See also @ref{C} See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

2 3

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 August 1998