Thanks to Jonas for the command line option suggestions. With them I am getting only 3 "push" (and no "pop") errors when I use the 2007 version of gpc (the 2002 version would not accept those options).
Given that the "with gcc" binary tarballs are intended to be stand-alone I am somewhat surprised that installing 32 bit versions of "all dev packages (including libc-dev)" may be needed. And since I do not come from the C/Linux world (my background is primarily Fortan, Pascal, Ada) I'm not sure quite what is meant by "dev packages" - are we talking only libraries (libc-dev), tools (gcc, gpc, etc.) or something else? And which ones do I need, if any? (The issue may not be important, see below.)
First: Am I correct in assuming that the "i686" versions are: a) 32-bit not 64-bit, and more importantly, b) NOT for the iTanium chip?
And am I correct in that a true 64-bit wide (x86_64) gpc Linux compiler is not yet available? If so I expect I need to install the i686 version of the "binutils" package. (yum only lists the x86_64 version and the trace below implies that the 64 bit assembler is being used - this seems to confirm my initial suspicion about a word length mismatch.) Or, put another way, have I encountered a hidden assumption/pitfall that the "binary" stand-alone gpc packages expect binutils to always be 32-bits wide?
BTW, The application has safety, security, configuration control and legal reasons that preclude the target machines from ever having anything installed that someone can use (e.g. compilers) to compromise the system. All development is done here, all that our field sites ever get are the binary executables in the form of an install package.
And FYI, the entire program is:
program hello; begin writeln('Hello, world!'); end;
Compiling this (as root) using the -v option produced:
[root@lxstn08 dev]# gpc -v -Wa -m32 hello.pas
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ../gcc-3.4.6/configure --enable-languages=pascal Thread model: posix gpc version 20070904, based on gcc-3.4.6
/usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.6/gpc1 -quiet -v hello.pas
-quiet -dumpbase hello.pas -m32 -mtune=pentiumpro -auxbase hello -famtmpfile=/tmp/ccA5rIAp.gpa -Wa -version -o /tmp/ccALeZVE.s
GNU Pascal version 20070904, based on gcc-3.4.6 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.6
as -V -Qy -o /tmp/ccKyOQdV.o /tmp/ccALeZVE.s
GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020
/tmp/ccALeZVE.s: Assembler messages: /tmp/ccALeZVE.s:9: Error: suffix or operands invalid for `push' /tmp/ccALeZVE.s:37: Error: suffix or operands invalid for `push' /tmp/ccALeZVE.s:51: Error: suffix or operands invalid for `push' [root@lxstn08 dev]#
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 24, 2010 12:01 PM To: GNU Pascal mailing list Subject: Re: GPC Assembler errors - help needed
On 24 Aug 2010, at 17:47, Morton, John wrote:
However when I compile the simplest possible "hello world" on RHEL 5.4 (a fedora variant) I always get the following assembler errors:
Error: suffix or operands invalid for "push" Error: suffix or operands invalid for "pop"
Does anyone know what is causing these errors - and/or a fix for them?
This means that GPC is generating 32 bit code, but that it is being assembled as [64] bit code. Try passing the "-m32" parameter to gp/gpc, and if that does not work, try -Wa,-m32. Note that you may have to install 32 bit versions of all dev packages (including libc-dev) that you need, unless those are installed by default.
<<SNIP>>
Jonas
Morton, John a écrit :
First: Am I correct in assuming that the "i686" versions are: a) 32-bit not 64-bit,
yes
And am I correct in that a true 64-bit wide (x86_64) gpc Linux compiler is not yet available?
No it is, but you absolutely need to compile from sources for linux. You probably need more parameters for configure.
I have compiled gpc some years ago on a Fedora core machine, with gcc-3.4.4 sources patched by redhat. configure is done by ../gcc-3.4.4-20050721/configure --disable-shared --enable-threads=posix \ --disable-checking --with-system-zlib --enable-__cxa_atexit \ --disable-libunwind-exceptions --enable-languages=c,pascal \ --disable-multilib --host=x86_64-redhat-linux
It was taken from the configure you can read by typing gcc -v on your dev machine, eliminating parameters obviously not needed because they are needed for other compilers like java (but I am not sure that others like --enable-__cxa_atexit are needed, not understanding what they mean)
Important is the last line
--host=x86-redhat-linux tells him to produce a 64 bits compiler
--disable-multilib , because multilib support is not (yet?) contained in gpc. multilib means to be able to produce both 64 bits and 32 bits executables and libraries (libgpc.a to begin width)
Yesterday, I compiled similarly a 64 bits gpc on a new debian machine, with fsf sources gcc-3.4.6 without any patches, changing only
--host=x86_64-linux-gnu
In both cases I looked to the installed file system for /usr/lib/gcc to determine the correct host name.
Running the gpc tests in place gave in both systems a handfull of errors with more than 5000 tests, and I have used the first system for years without problems.
Comments of other peoples come in when you try to build a multilib system without multilib support for gpc (but multilib support for gcc with --enable-multilib in configure). I was able to do that on the first machine, but it needed some dirty tricks: experimentation in installing into temporary directories to understand the directory structure, compiling a 32 bits version of libgpc.a with things like make PFLAGS=-m32 RTSFLAGS=-m32 boostrap and finishing by putting manually libgpc.a at proper place I needed also to install various 32 bits libraries for curses, gmp, graphics and the like, all made with yum.
If you need only 64 bits, it is simple, and proceeds like in the INSTALL doc.
Maurice
On 24 Aug 2010, at 23:35, Morton, John wrote:
Given that the "with gcc" binary tarballs are intended to be stand- alone I am somewhat surprised that installing 32 bit versions of "all dev packages (including libc-dev)" may be needed.
A compiler only transforms source code into machine code. If your program depends on functionality that is inside libraries, then you obviously have to install those libraries as well. GPC programs by default use functionality from libc afaik, and hence to compile such programs you have to have the right libraries installed.
And since I do not come from the C/Linux world (my background is primarily Fortan, Pascal, Ada) I'm not sure quite what is meant by "dev packages" - are we talking only libraries (libc-dev), tools (gcc, gpc, etc.) or something else?
Only libraries.
And which ones do I need, if any?
libc, plus whichever libraries you use functionality from in your program.
First: Am I correct in assuming that the "i686" versions are: a) 32- bit not 64-bit,
Yes.
and more importantly, b) NOT for the iTanium chip?
The Itanium's monicker is ia64. i686 means "sixth generation of the 80x86 processors", i.e., basically any 80x86-compatible micro- architecture that came after the original Pentium (Pentium Pro, AMD K6, Cyrix 6x86, Pentium II etc).
And am I correct in that a true 64-bit wide (x86_64) gpc Linux compiler is not yet available?
See Maurice' answer for this.
If so I expect I need to install the i686 version of the "binutils" package. (yum only lists the x86_64 version and the trace below implies that the 64 bit assembler is being used - this seems to confirm my initial suspicion about a word length mismatch.)
The x86-64 version of the assembler can also assemble 32 bit code. You just have to specify the correct parameter, which is "--32" (so you'd have to use -Wa,--32 rather than -Wa,-m32, sorry about that).
BTW, The application has safety, security, configuration control and legal reasons that preclude the target machines from ever having anything installed that someone can use (e.g. compilers) to compromise the system. All development is done here, all that our field sites ever get are the binary executables in the form of an install package.
That is no problem.
[root@lxstn08 dev]# gpc -v -Wa -m32 hello.pas
-Wa by itself does nothing. That parameter means "pass everything after the comma literally as option to the assembler". If you don't add anything, nothing will be passed. Use this instead: -Wa,--32 (including the comma, and no spaces in between)
Jonas
-
Jonas Maebe -
Maurice Lombardi -
Morton, John