Thanks to the list (especially Jonas and Maurice) I've made progress.
I am now able to log in as an unprivileged user ("etms") and run gpc (from "/home/etms/dev" which holds the "hello world" source code). The gpc -v output shows that the compile now gets to the linker stage - which complains that it cannot find crtl.o (and probably crti.o and crtn.o). Since none of these files are prefixed with a path it seems that the linker assumes they are in the current directory or are in the following default path (as one line - you can safely ignore the two "etms" folders):
/usr/local/bin/:/usr/bin:/usr/X11R6/bin:/home/etms/bin: /opt/0V/bin:/opt/0V/bin/0pC:/etms/com:.
I thought I saw the missing files somewhere but (assuming I've used "find" correctly) they aren't on my system at all. I did the search after deleting gpc-2.1 (from gnu-pascal.de) and then untarring (as root) "gcc-core-3.4.6.tar.tar" (from Brandeis) into it's default location (/usr/local/gcc-3.4.6). Shouldn't the 3.4.6 extraction have placed the 3 files in or under that directory?
In theory all I need to do is update $PATH to include the appropriate directory - but which one is supposed to contain the three files? Or is there some other way (e.g. a command line option) to make the files visible to the linker?
---
BTW, yum reports glibc 2.5-42 (i686 and x86_64 versions) and glibc-common 2.5-42 (x86_64 version only) but not libc (or libc-dev). My understanding is that this naming difference does not affect gpc (or anything else) on my Linux box.
Finally, my thanks to Maurice for explaining the 64 bit situation. Luckily for me a 64 bit image is not (yet) an absolute requirement. Once I've got the 32 bit version working I'll be looking into building a 64 bit version from source code.
John
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 25, 2010 07:11 AM To: GNU Pascal mailing list Subject: Re: GPC Assembler errors - help needed
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.
<<SNIP>>
GPC programs by default use functionality from libc afaik, and hence to compile such programs you have to have the right libraries installed.
<<SNIP>>
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
<<SNIP>>
[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
On 25 Aug 2010, at 21:26, Morton, John wrote:
I am now able to log in as an unprivileged user ("etms") and run gpc (from "/home/etms/dev" which holds the "hello world" source code). The gpc -v output shows that the compile now gets to the linker stage - which complains that it cannot find crtl.o (and probably crti.o and crtn.o).
These are part of the glibc-devel.i386 package. You have to install it on your compilation machines. It does not have to be installed on the staging/deployment machines (but glibc.i686 will have to be installed there).
Since none of these files are prefixed with a path it seems that the linker assumes they are in the current directory or are in the following default path (as one line - you can safely ignore the two "etms" folders):
Those files will be installed in /usr/lib.
I thought I saw the missing files somewhere but (assuming I've used "find" correctly) they aren't on my system at all. I did the search after deleting gpc-2.1 (from gnu-pascal.de) and then untarring (as root) "gcc-core-3.4.6.tar.tar" (from Brandeis) into it's default location (/usr/local/gcc-3.4.6). Shouldn't the 3.4.6 extraction have placed the 3 files in or under that directory?
No, because they are part of glibc rather than of gcc/gpc.
In theory all I need to do is update $PATH to include the appropriate directory
Object files are not searched in the PATH. The path is only used when looking for executables.
BTW, yum reports glibc 2.5-42 (i686 and x86_64 versions) and glibc-common 2.5-42 (x86_64 version only) but not libc (or libc-dev).
I made a mistake before: I meant glibc-devel rather than libc-dev.
My understanding is that this naming difference does not affect gpc (or anything else) on my Linux box.
The -devel package of a library is required when compiling software that links against this library. It's not just a naming difference, it's an additional package that contains extra files. On the deployment machine, only the regular package is necessary.
Jonas
What OS is this on?
AIX uses a LIBPATH variable for paths to search for libraries. I think in linux its the LD_PATH or LD_LIB_PATH
Look for something like that to set with the path you need. It may be in the default bashrc in /etc
What do you get when you enter env at the command line? This should show all your environment variables for bash and korn shells
----- Original Message ---- From: Jonas Maebe jonas.maebe@elis.ugent.be To: GNU Pascal mailing list gpc@gnu.de Sent: Wed, August 25, 2010 2:40:26 PM Subject: Re: GPC Assembler/linker errors - help needed
On 25 Aug 2010, at 21:26, Morton, John wrote:
I am now able to log in as an unprivileged user ("etms") and run gpc (from "/home/etms/dev" which holds the "hello world" source code). The gpc -v output shows that the compile now gets to the linker stage - which complains that it cannot find crtl.o (and probably crti.o and crtn.o).
These are part of the glibc-devel.i386 package. You have to install it on your compilation machines. It does not have to be installed on the staging/deployment machines (but glibc.i686 will have to be installed there).
Since none of these files are prefixed with a path it seems that the linker assumes they are in the current directory or are in the following default path (as one line - you can safely ignore the two "etms" folders):
Those files will be installed in /usr/lib.
I thought I saw the missing files somewhere but (assuming I've used "find" correctly) they aren't on my system at all. I did the search after deleting gpc-2.1 (from gnu-pascal.de) and then untarring (as root) "gcc-core-3.4.6.tar.tar" (from Brandeis) into it's default location (/usr/local/gcc-3.4.6). Shouldn't the 3.4.6 extraction have placed the 3 files in or under that directory?
No, because they are part of glibc rather than of gcc/gpc.
In theory all I need to do is update $PATH to include the appropriate directory
Object files are not searched in the PATH. The path is only used when looking for executables.
BTW, yum reports glibc 2.5-42 (i686 and x86_64 versions) and glibc-common 2.5-42 (x86_64 version only) but not libc (or libc-dev).
I made a mistake before: I meant glibc-devel rather than libc-dev.
My understanding is that this naming difference does not affect gpc (or anything else) on my Linux box.
The -devel package of a library is required when compiling software that links against this library. It's not just a naming difference, it's an additional package that contains extra files. On the deployment machine, only the regular package is necessary.
Jonas
On 25 Aug 2010, at 21:59, Refr Bruhl wrote:
What OS is this on?
Red Hat Enterprise Linux.
AIX uses a LIBPATH variable for paths to search for libraries. I think in linux its the LD_PATH or LD_LIB_PATH
It's not necessary in this case, the files he needs are simply not yet installed. I guess you are thinking of LD_LIBRARY_PATH, but that one is only used by the dynamic linker to search for libraries when starting a program, not by the static linker when compiling a program (for the latter, you simply use the -L command line option to add directories to the search path).
Jonas
Morton, John a écrit :
I am now able to log in as an unprivileged user ("etms") and run gpc (from "/home/etms/dev" which holds the "hello world" source code). The gpc -v output shows that the compile now gets to the linker stage - which complains that it cannot find crtl.o (and probably crti.o and crtn.o). Since none of these files are prefixed with a path it seems that the linker assumes they are in the current directory or are in the following default path (as one line - you can safely ignore the two "etms" folders):
/usr/local/bin/:/usr/bin:/usr/X11R6/bin:/home/etms/bin: /opt/0V/bin:/opt/0V/bin/0pC:/etms/com:.
This is the path for executables. crtl.o is not an executable, but an "object" i.e. a binary file produced by the compilation of a source like crtl.c, and which be used by the linker with other objects to produce an executable. The linker searches these files in standard locations, whence the absence of pathes. You can see these standard locations by typing gpc --print-search-dirs hello.pas (there are many ...)
I thought I saw the missing files somewhere but (assuming I've used "find" correctly) they aren't on my system at all. I did the search after deleting gpc-2.1 (from gnu-pascal.de) and then untarring (as root) "gcc-core-3.4.6.tar.tar" (from Brandeis) into it's default location (/usr/local/gcc-3.4.6). Shouldn't the 3.4.6 extraction have placed the 3 files in or under that directory?
gcc-core.... is a source file, it contains absolutely no binary.
If you have a gcc compiler installed in your system (a binary, not a source, otherwise you could not make anything), you should have a directory structure like
/usr/lib/gcc/<system>/<version>
where <system> is e.g. x86_64-redhat-linux for a 64 bits compiler i686-pc-linux 32
and <version> is e.g. 3.4.6 or 4.4.4
In this directory you have several files crtbegin.o crtend.o ... and libraries like libgcc.a
A successfull compilation and install of gpc produces the same structure below /usr/local/lib
Apparently you should spend some time in looking to the directory structure of your computer and trying to understand what is a source, an object, a static library, a dynamic library, an executable, a compiler, an assembler, a linker and the like.
Maurice
-
Jonas Maebe -
Maurice Lombardi -
Morton, John -
Refr Bruhl