Gpc

gpc@gnu.de

5400 discussions

Re: gcc-3.4.0
by Russell Whitaker 26 Apr '04

26 Apr '04

Hi compiled & installed bison 1.875c, make check reported 7 errors. Traced problem to error in gcc-3.4: the default install of /usr/local puts libstdc++ in /usr/local/lib but the gcc code expects it to be in /usr/lib. Rebuilt gcc & installed using --prefix=/usr. Rebuilt bison & installed. Now make check reports all ok. So back to the patched version of gcc-3.4: rm -r * in the build directory to start clean. make -j3 bootstrap - it failed in p then "make bootstrap > emsgs 2>&1" last few lines are: gcc -o p/parse.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -I. -Ip -I../../gcc-3.4.0/gcc -I../../gcc-3.4.0/gcc/p -I../../gcc-3.4.0/gcc/../include -DGPC -I../../gcc-3.4.0/gcc/p ../../gcc-3.4.0/gcc/p/parse.c parse.c:378: warning: useless keyword or type name in empty declaration parse.c:378: warning: empty declaration parse.c: In function `yydoAction': parse.c:8133: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c:8133: error: (Each undeclared identifier is reported only once parse.c:8133: error: for each function it appears in.) parse.c: In function `yyglrReduce': parse.c:8249: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yysplitStack': parse.c:8287: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveStates': parse.c:8386: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveAction': parse.c:8417: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyprocessOneStack': parse.c:8610: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.y: At top level: parse.y:2967: warning: 'locations' defined but not used make[2]: *** [p/parse.o] Error 1 make[2]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/build/gcc' make: *** [bootstrap] Error 2 h'm looks like same problem last email. Russ

4 8

Gcc-3.4
by David Kredba 25 Apr '04

25 Apr '04

Hello all, gpc seems to be very friendly with gcc-3.3.x, gpc testsuite is completely OK with it. How deep is change between gcc-3.3 and gcc-3.4 ? I don't study structure of gcc-3.4 thoroughly for the present, but i see that the build logic were changed. Configure scripts are now called by main Makefile after a little base configuration. Etc. Did you someone any research on it ? Thanks, David -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024/BB7FB39D Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

6 19

gcc-3.4.0
by Russell Whitaker 23 Apr '04

23 Apr '04

Hi Grabbed Waldek's patches. Both gcc & gpc patched ok. Started bootstrap; found bison 1.35 was too old; Grabbed bison 1.875, & installed (there's a 1.875c - should I have used that instead? ). Then make bootstrap got this far: [..] make[3]: Nothing to be done for `generated-files'. make[3]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/p/rts' gcc -o p/parse.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -I. -Ip -I../../gcc-3.4.0/gcc -I../../gcc-3.4.0/gcc/p -I../../gcc-3.4.0/gcc/../include -DGPC -I../../gcc-3.4.0/gcc/p ../../gcc-3.4.0/gcc/p/parse.c parse.c:378: warning: useless keyword or type name in empty declaration parse.c:378: warning: empty declaration parse.c: In function `yydoAction': parse.c:8133: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c:8133: error: (Each undeclared identifier is reported only once parse.c:8133: error: for each function it appears in.) parse.c: In function `yyglrReduce': parse.c:8249: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yysplitStack': parse.c:8287: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveStates': parse.c:8386: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveAction': parse.c:8417: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyprocessOneStack': parse.c:8610: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.y: At top level: parse.y:2967: warning: 'locations' defined but not used make[2]: *** [p/parse.o] Error 1 make[2]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/build/gcc' make: *** [bootstrap] Error 2 Russ

2 1

Re: Gcc-3.4
by Waldek Hebisch 23 Apr '04

23 Apr '04

Russell Whitaker wrote: > > > On Thu, 22 Apr 2004, Waldek Hebisch wrote: > [..] > > > > There are experimental patches on my gpc Web page... > > URL, please > http://www.math.uni.wroc.pl/~hebisch/gpc/ -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Re: Inaccurate information in `GNU' section
by Neil Santos 23 Apr '04

23 Apr '04

On 15:35 21/04/04, Peter N Lewis wrote: > >``Separate entity'' is rather vague; do you mean that it can run > >standalone, or do you mean that it does not contain code from any > >GPL-covered software? Both have to be true before you can consider > >releasing it under any license other than GPL. > > I'm confused by this. If it "does not contain code from any > GPL-covered software", then surely you can release it under any > license you feel like, whether it can run stand-alone or not. If I A program can be free of code from a GPL-covered program, but it links with a library licensed under the GPL, then it has to be under the GPL as well. It is this catch, if you will, that led to the LGPL. For more information on the above, please read http://www.gnu.org/licenses/why-not-lgpl.html > write code that does not contain code from any GPL-covered software, > how then could the GPL be required of my code even if it is not > standalone? If it is not standalone, and it links with one or more libraries under the GPL, then your code falls under the situation I described above. It would then have to be released under the GPL, as per its conditions. > I can't see how that could be otherwise...? I hope my reply helps you understand the hairy situation. -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

3 2

Inaccurate information in `GNU' section of GPC info
by Neil Santos 23 Apr '04

23 Apr '04

While mulling over a confusing part of something I'm writing, I decided to browse the info pages of GPC. In the GNU section, I read this: When you modify a free program released under the GNU General Public License, e.g. the GNU Pascal compiler itself, your modified will become Free Software, too. I'm no lawyer, but I've read enough of RMS's articles regarding the GPL, as well as a few technical (but not necessarily legalese) discussions of the same, to understand that, when modifications to Free Software DO NOT need to become free themselves. As I understand it, modifications to Free Software do not need to be released; but when it is, it HAS to be released under the GPL, if the program modified was released under the GPL. [CC'd to RMS, in case I goofed, and therefore should be banished from society and be forced to use nothing but proprietary software.] -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

5 11

Closing a file
by Andy Ball 22 Apr '04

22 Apr '04

Hello, Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use... CLOSE(FILEHANDLE,LOCK); ...which gpc complains about. I have tried... CLOSE(FILEHANDLE); ...which compiles okay, but doesn't seem to commit the data (I wind up with a zero-length file. I've tried including the filename in the program parameters, which is suggested by the book, but gpc didn't seem to like that either. I'm also not sure whether I need to pass the file handle as a parameter to the procedure that's doing the writing, or how I would do that (I did try, but without success). This is my first Pascal program... http://grex.cyberspace.org/~ball/test5.pas - Andy.

8 21

Extended Pascal question
by Frank Heckenbach 21 Apr '04

21 Apr '04

Sometime ago I asked the following questions, but got no replies. What about the EP experts out there? ;-) A question to the EP experts. Are these things allowed? a) module m; export m = (a => a); const a = 1; end; end. b) module m; export m = (a => b, a => c); const a = 1; end; end. c) module m; export m = (a => b, a); const a = 1; end; end. Likewise for import (assuming m exports a): a) program p; import m (a => a); begin end. b) program p; import m (a => b, a => c); begin end. c) program p; import m (a => b, a); begin end. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

3 10

Re: MD5 unit
by Thorsten Glaser 20 Apr '04

20 Apr '04

Dixitur me scribere... >Okay, this is now a second try: ... this time for real, with attachement. //Thorsten -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

1 0

Executable file size in MinGW environment
by André Eduardo Gabriel da Silva 20 Apr '04

20 Apr '04

Hello people! First of all, I'd like to thank you all that work on the development of the GPC compiler. It's a really good work. But I have a question, that I don't know exactly if it's run-time system's matter or a linker's matter. I'm using the following GPC (I've downloaded the binaries from the site): ----- gpc -v ----- Reading specs from c:\usr\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\specs Configured with: /src/mingw/gcc-3.2.3-20030504-1/configure --srcdir=/src/mingw/gcc-3.2.3-20030504-1 --enable-languages=pascal --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --disable-win32-registry --disable-shared --enable-sjlj-exceptions Thread model: win32 gpc version 20030830, based on gcc-3.2.3 (mingw special 20030504-1) ----- Consider the size of the following source and executable files: ----- cat hello.pas ----- PROGRAM hello; BEGIN writeln ('Hello world!'); END. ----- Consider the size of the following source and executable files, after compilation: ----- gpc -o hello hello.pas ----- hello.pas 60 bytes hello.exe 707.791 bytes ----- Why is the executable file so big? What is this overhead generated for every program created with the above GPC? The program LD has the option of stripping off all the symbols. Doing that I've got the following: ----- gpc -Wl,-s -o hello hello.pas ----- hello.pas 60 bytes hello.exe 247.808 bytes ----- But I still think this is a big executable. There is a way to reduce this overhead? Thank you in advance. Andre

3 2

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