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/