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