Dear GPC Users,
I just compiled GPC from sources on both 32-bit and 64-bit Linux machines. On both machines, I'm running Scientific Linux 6.4, a derivative of Red Had Linux 6.4. The local C compiler is 4.4.7 in both cases.
On the 32-bit machine, I can compile from Pascal to make objects, and link them with libgpc.a to make a shared library. But on the 64-bit machine I find that I must pass -fPIC to GPC to force it to compile position-independent code for the subsequent link. Even then, libgpc.a is position-dependent, so I can't link it into a shared library. So I edit the GPC build's Makefile:
CFLAGS = -g -O2 -fPIC
Now I build GPC again and re-install. The new libgpc.a is position-independent, and I can make my shared library.
Does anyone know why the default on 64-bit is position-dependent, while on 32-bit it is position-independent?
Is there an easier way to add a compiler option to the build process, other than editing the Makefile produced by the GCC_3.4.6 configure script? (For example, can I pass a compiler option into the configure script or into the makefile.)
Anyway: I have adapted my compiler GPC instructions below, and I'll be adding more Linux binary install files in the coming weeks.
http://alignment.hep.brandeis.edu/Software/Pascal/Index.html
Yours, Kevan
On 05/02/14 20:11, Kevan Hashemi wrote:
Is there an easier way to add a compiler option to the build process, other than editing the Makefile produced by the GCC_3.4.6 configure script? (For example, can I pass a compiler option into the configure script or into the makefile.)
try
make CFLAGS = -g -O2 -fPIC pascal.install-with-gcc
Is your version of bison later than 2.3? For me, later versions of bison produce errors on the unmodified gpc-20070904 sources. I've attached a patch taken from here ---> http://www.microchip.com/forums/m416697-print.aspx to fix this.
--Trevor// (contributor, gpc rpms on openSuSE build service)
Kevan Hashemi wrote:
I just compiled GPC from sources on both 32-bit and 64-bit Linux machines. On both machines, I'm running Scientific Linux 6.4, a derivative of Red Had Linux 6.4. The local C compiler is 4.4.7 in both cases.
On the 32-bit machine, I can compile from Pascal to make objects, and link them with libgpc.a to make a shared library. But on the 64-bit machine I find that I must pass -fPIC to GPC to force it to compile position-independent code for the subsequent link. Even then, libgpc.a is position-dependent, so I can't link it into a shared library. So I edit the GPC build's Makefile:
CFLAGS = -g -O2 -fPIC
Now I build GPC again and re-install. The new libgpc.a is position-independent, and I can make my shared library.
Does anyone know why the default on 64-bit is position-dependent, while on 32-bit it is position-independent?
By default gpc builds position-dependent libgpc. On 32-bit i386 shared libraries may contain position-dependent code, on other platforms, in particular for amd64 you need position-independent code in shared libraries.
If you want shared libgpc, after buildiing gpc do:
cd gcc/p/rts make clean make WITH_SHARED=yes
I do not remember if there is any support for automatically installing libgpc, if needed install resulting libgpc by hand.
Waldek Hebish:
By default gpc builds position-dependent libgpc. On 32-bit i386 shared libraries may contain position-dependent code
I see. That explains it. Thank you.
cd gcc/p/rts make clean make WITH_SHARED=yes
I will try that. My existing 64-bit binary distribution appears to be position-independent.
Trevor B:
make CFLAGS = -g -O2 -fPIC pascal.install-with-gcc
Very good. Thank you.
Is your version of bison later than 2.3?
Yes, 2.4.1, and I had no difficulties. But following your link to the patch, I see that the error I would have obtained would be:
gcc: c-parse.c: No such file or directory gcc: no input files
And this is exactly the error that thwarted me six months ago, when I tried to compile on 64-bit Linux. So it appears that Bison has been fixed, and I now understand what has been going wrong, because a colleague was able to compile on another, older 64-bit machine. So thank you for that also.
Your, Kevan
-
Kevan Hashemi -
trevor -
Waldek Hebisch