Frank:
| strawberry 40% cat t.p | program t (output); | begin | writeln(output,'hello world'); | end. | strawberry 41% /usr/local/gpc/bin/gpc t.p | strawberry 42% a.out | Segmentation Fault | | :-(
Aha, so it isn't GPC that crashes, but the compiled executable. That's already more information than in your last mail.
Right. Sorry my previous email wasn't clear about that.
One possibility could be a confusion of runtime library versions or compiler parts. I see your admin installed GPC in a nonstandard directory. Did he do this correctly, i.e. either set the --prefix on configure, or else set GPC_EXEC_PREFIX?
I don't know, I'll pass this on to him.
If that's ok, can you run the program in a debugger to find out where it crashes?
Sure.
********************************************************************************
% cat t.p program t(output); begin writeln(output,'hello world'); end. % /usr/local/gpc-20050331/bin/gpc -v Reading specs from /export/data/local/gpc-20050331/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.3/specs Configured with: /export/home/bryantd/gpc-build/../gcc-3.3.3/configure --enable-languages=pascal --prefix=/usr/local/gpc Thread model: posix gpc version 20050331, based on gcc-3.3.3 % /usr/local/gpc-20050331/bin/gpc -g t.p % gdb t GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... (gdb) run Starting program: /home/strawberry/toms/work/emptytest/t
Program received signal SIGSEGV, Segmentation fault. 0x189dc in _p_ReturnAddr2Hex () (gdb) quit The program is running. Exit anyway? (y or n) y
I see now that my sysadmin did this:
I had compiled gpc on sparky so that it would be "solaris-8- compatible", and then installed it on strawberry. I guess I could try compiling the whole thing on strawberry and see if it makes any difference.
but
uname -aimnprsvX
gives
SunOS strawberry 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Blade-1000System = S unOS
Could that have caused this effect? Sparky is Solaris 2.8 and Strawberry is 2.9. Why GDB said 2.9 I don't know ...
********************************************************************************
| strawberry 44% /usr/local/gpc/bin/gpc -v | Reading specs from /export/data/local/gpc/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.3/specs | Configured with: /export/home/bryantd/gpc-build/../gcc-3.3.3/configure --enable-languages=pascal --prefix=/usr/local/gpc | Thread model: posix | gpc version 20050331, based on gcc-3.3.3 | | When I try to use /usr/local/bin/gpc-2.1 in my gpcc script | (/home/strawberry/toms/work/emptytest/gpcc2.1), I get: | | gpc1: Invalid option `-Wno-identifier-case-local' | | so I can't compile until this is fixed ...
Uhm, fixed? gpc-2.1 is 3 years old, and we don't actually plan to backport new features to it. If it's just this one (you don't require other newer features), you can take out this option for 2.1 (which simply didn't exist back then).
I'm confused. All I knew was that I got this 'Invalid option' message, which seemed unrelated and off the wall. But it could mean that `-Wno-identifier-case-local' is no longer a valid option? Looking in what seems to be the current manual at
http://www.gnu-pascal.de/gpc/GPC-Command-Line-Options.html#GPC-Command-Line-...
that flag is listed. Doesn't that mean it is a valid option? So I'm puzzled as to why it was objected to. I can't replicate the problem now so maybe sys admin was moving things around and I ended up working with an old version for a few minutes.
********************************************************************************
My gpcc script is at ftp://ftp.ncifcrf.gov/pub/delila/gpcc in gpcc2.1 I just modified the location of the compiler.
It's a bit longish, so I can't read it all now.
No problem, I included it only for completeness.
: # -Widentifier-case-local
Please accept my apologies for that. It was material that went into the script when the issue first came up. I have removed it and tried to clarify the issue in the documentation.
- Do it yourself.
I'm not an expert such as yourself. I have many papers to write and no time to become a GPC expert (though it would be fun to help you more than just reporting bugs).
- Ask politely and/or convince someone to do it for you.
Please accept my apologies.
- Pay someone to do it for you.
Unfortunately science has a shrinking budget in the USA ... My text modules are compiler independent and are not always consistent, so I had to just turn off the flag.
BTW, your quick jumping to conclusions that "[GPC] is too alpha" when in fact it may just be an installation problem on your (or your admin's) part, or claiming that an older version not supporting newer options is something that needs to be "fixed"
I am reporting a problem to you as best as I can. I'm not an expert, I do not know the guts of GPC. I did not know that an incorrect installation (if that's what happened) could cause such an effect as I have never seen that happen before. All I meant was that "this particular installation of a GPC alpha didn't work". GPC itself is clearly quite robust (thanks to you!), which is why I use it. The alpha GPC that we have produced a binary that crashed. I don't know why that may be. Alphas in general can crash - this is true for Mozilla.
I would never ask you to 'fix' an older version! That's wasting your time! Isn't this 20050331 a newer version?
Best Regards,
Tom
Dr. Thomas D. Schneider National Institutes of Health National Cancer Institute Center for Cancer Research Nanobiology Program Molecular Information Theory Group Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu (use only if first address fails) http://www.ccrnp.ncifcrf.gov/~toms/
Tom Schneider wrote:
% cat t.p program t(output); begin writeln(output,'hello world'); end. % /usr/local/gpc-20050331/bin/gpc -v Reading specs from /export/data/local/gpc-20050331/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.3/specs Configured with: /export/home/bryantd/gpc-build/../gcc-3.3.3/configure --enable-languages=pascal --prefix=/usr/local/gpc Thread model: posix gpc version 20050331, based on gcc-3.3.3 % /usr/local/gpc-20050331/bin/gpc -g t.p % gdb t GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... (gdb) run Starting program: /home/strawberry/toms/work/emptytest/t
Program received signal SIGSEGV, Segmentation fault. 0x189dc in _p_ReturnAddr2Hex () (gdb) quit The program is running. Exit anyway? (y or n) y
I see now that my sysadmin did this:
I had compiled gpc on sparky so that it would be "solaris-8- compatible", and then installed it on strawberry. I guess I could try compiling the whole thing on strawberry and see if it makes any difference.
but
uname -aimnprsvX
gives
SunOS strawberry 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Blade-1000System = S unOS
Could that have caused this effect? Sparky is Solaris 2.8 and Strawberry is 2.9. Why GDB said 2.9 I don't know ...
I'm not so familiar with Solaris version issues, but it would seem correct to me.
You could try entering "disass" in gdb to get more information.
But actually I'd rather suspect the "moving things around". GCC is rather sensitive to moving things around, especially if other versions are installed on the system as well.
So to save us all some guessing, it might be easiest to restart the installation from scratch:
- extract the original source archives,
- configure with the prefix it will finally be installed in,
- build,
- make install or make pascal.install-with-gcc (the latter won't overwrite a previous gcc installation if the prefix or the gcc version is different -- in your case, the prefix should be different AFAIUI)
What you can move around/copy/link/rename then are the main executables (those in .../bin), nothing else (in particular not any of the files installed under .../lib or .../libexec).
| strawberry 44% /usr/local/gpc/bin/gpc -v | Reading specs from /export/data/local/gpc/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.3/specs | Configured with: /export/home/bryantd/gpc-build/../gcc-3.3.3/configure --enable-languages=pascal --prefix=/usr/local/gpc | Thread model: posix | gpc version 20050331, based on gcc-3.3.3 | | When I try to use /usr/local/bin/gpc-2.1 in my gpcc script | (/home/strawberry/toms/work/emptytest/gpcc2.1), I get: | | gpc1: Invalid option `-Wno-identifier-case-local' | | so I can't compile until this is fixed ...
Uhm, fixed? gpc-2.1 is 3 years old, and we don't actually plan to backport new features to it. If it's just this one (you don't require other newer features), you can take out this option for 2.1 (which simply didn't exist back then).
I'm confused. All I knew was that I got this 'Invalid option' message, which seemed unrelated and off the wall. But it could mean that `-Wno-identifier-case-local' is no longer a valid option?
[...]
I would never ask you to 'fix' an older version! That's wasting your time! Isn't this 20050331 a newer version?
I think there's some confusion here. Yes, 20050331 is new, but 2.1 is older (2002-05-10). So the option works with the new version, but not with the old one, and so it's no surprise that you get an "invalid option" message with the old version (2.1, which I understand you tried to use above). As the old version will never be "fixed", you can either take out the option when you compile with the old version, or just not old the old version anymore ...
: # -Widentifier-case-local
Please accept my apologies for that. It was material that went into the script when the issue first came up. I have removed it and tried to clarify the issue in the documentation.
Now it says: "My programs use text modules that come from various places, so keeping the case consistent between all modules is not possible." -- Well, `-Widentifier-case-local' compares the case only within modules/units, so it might still work for you. Or do mean include files instead of modules?
BTW, your quick jumping to conclusions that "[GPC] is too alpha" when in fact it may just be an installation problem on your (or your admin's) part, or claiming that an older version not supporting newer options is something that needs to be "fixed"
I am reporting a problem to you as best as I can. I'm not an expert, I do not know the guts of GPC. I did not know that an incorrect installation (if that's what happened) could cause such an effect as I have never seen that happen before. All I meant was that "this particular installation of a GPC alpha didn't work". GPC itself is clearly quite robust (thanks to you!), which is why I use it. The alpha GPC that we have produced a binary that crashed. I don't know why that may be. Alphas in general can crash - this is true for Mozilla.
Some quotes from two articles also referenced in the GPC manual ("Reporting Bugs"):
http://www.catb.org/~esr/faqs/smart-questions.html
: Good and Bad Questions : : Finally, I'm going to illustrate how to ask questions in a smart way : by example; pairs of questions about the same problem, one asked in a : stupid way and one in a smart way. : : [...] : : Stupid: I can't get the code from project foo to compile. Why is it : broken? : He assumes that somebody else screwed up. Arrogant of him. : : Smart: The code from project foo doesn't compile under Nulix version : 6.2. I've read the FAQ, but it doesn't have anything in it : about Nulix-related problems. Here's a transcript of my : compilation attempt; is it something I did? : He's specified the environment, he's read the FAQ, he's showing : the error, and and he's not assuming his problems are someone : else's fault. This guy might be worth some attention.
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
: "It doesn't work." : : Give the programmer some credit for basic intelligence: if the program : really didn't work at all, they would probably have noticed. Since : they haven't noticed, it must be working for them. Therefore, either : you are doing something differently from them, or your environment is : different from theirs. They need information; providing this : information is the purpose of a bug report. More information is almost : always better than less.
So the point is not that alphas can crash, or that you don't like that particular option -- it's the way you phrase it. To quote the latter paper, if gpc-20050331 really couldn't compile a hello-world program, don't you think we'd have noticed by now? So claiming that "it is too alpha" on these grounds is rather silly.
I can only recommend, to you and anyone else who feels they should, to read those two articles [again or for the first time]. Various parts of them seem revelant to many bug reports on this list ...
Frank
Tom Schneider wrote:
Frank:
If that's ok, can you run the program in a debugger to find out where it crashes?
Sure.
% cat t.p program t(output); begin writeln(output,'hello world'); end. % /usr/local/gpc-20050331/bin/gpc -v Reading specs from /export/data/local/gpc-20050331/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.3/specs Configured with: /export/home/bryantd/gpc-build/../gcc-3.3.3/configure --enable-languages=pascal --prefix=/usr/local/gpc Thread model: posix gpc version 20050331, based on gcc-3.3.3 % /usr/local/gpc-20050331/bin/gpc -g t.p % gdb t GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... (gdb) run Starting program: /home/strawberry/toms/work/emptytest/t
Program received signal SIGSEGV, Segmentation fault. 0x189dc in _p_ReturnAddr2Hex () (gdb) quit The program is running. Exit anyway? (y or n) y
This looks like a known problem, see:
http://www.gnu-pascal.de/crystal/gpc/en/mail12116.html
There is also another known problem affecting Solaris:
http://www.gnu-pascal.de/crystal/gpc/en/mail12133.html
With patches from both mails applied gpc-20050331 worked fine for me on Solaris 2.6