Thanks for your reply! I am afraid that, given my ignorance, most of it is over my head; but let me see if I've got the key points.

First, though: on rereading my original email it occurs to me that I at one point I wrote a trifle too elliptically, so I'll explain now, just in case it wasn't clear before. I wrote: "programs which used to compile and execute happily with the gpc for PPC compiler are less happy with the gpc for Intel compiler." I should have made clear that I was referring, of course, to two different computers: I've just bought a new intel-chipped Mac and discovered the problem when recompiling old programs written on and for an older PPC-chipped one.

OK, so my questions. Reading what you wrote, am I right in getting the impression that the problem has something to do with the attempt to build a universal binary (one that will run on intel- or PPC-based macs)? This in involves, if i understand correctly, compiling the code twice and bundling the two together; are you saying that the error messages are coming from the failure of one of the two attempts, but the other one is succeeding (thus allowing the program, as observed, to nonetheless execute happily)? (Thanks to Rosetta, I suppose either of the two could be the working one.)

Am I getting all that right? Well, if that's the issue, I should mention that my programming is entirely a hobby for myself so I don't really need to build universal binaries-- I'd be happy just compiling for intel on this computer (and recompiling for PPC on the old one if I ever went back there).

Secondly, as you can see from my second email, I took the advice of Adriaan van Os and rolled back my assembler/linker to version 590.36. (They had previously been v. 622.5.) But what you write has gotten me worried: although this solved my present gpc compiling problem, have I messed with the Xcode suite in a way I shouldn't have-- one which could come back and bite me in the future should I ever begin to use it properly? (Right now command-line gpc is all I do; but who knows what the future might hold!) Was I irresponsible?

Finally, with regard to your last comment-- I take it that not many people fall into that category? :)

Thanks so much and I apologize for blundering about your subtle explanations of things with my ham-fisted approximations!

Rick DuPuy

On 09/03/07, Gale Paeper gpaeper@empirenet.com wrote:

On Mar 7, 2007, at 8:43 PM, Frederick Karl Kepner DuPuy wrote:

...

Hi. Regarding gpc for Mac OS X on Intel, I found a thread in the archives (see below) from October 2006 concerning an error message a user (Nestor Aguilera) got in compiling even the simplest programs. Unless I'm misreading the thread, no final conclusion was reached. Is anything further known now?

Here's the thread: http://www.gnu-pascal.de/crystal/gpc/en/ mail13854.html And the gist of the error messages: indirect jmp without `*'

I'm having the same issue he had: programs which used to compile and execute happily with the gpc for PPC compiler are less happy with the gpc for Intel compiler--- they're still compiling, but issuing this error message repeatedly as they do so.

If you compile to assembly for the Intel target, the assembly code will assemble without errors using Apple's latest as. (The assembled binary disassembles back to the correct indirect jump instruction with the * included so the right instruction bit pattern is getting generated with Apple's latest as even with out the * on the indirect jump assembly code.)

...

I believe the output executes OK; but you can see why this is unsettling. So: is this a problem, or just an annoyance to be lived with? And is it happening to everybody trying to use gpc for Mac on Intel? (If so I'm curious as to why it hasn't been discussed since October.)

I ended up finding a solution to the problem by installing an older version of cctools, modifying Adriaan's GPC build scripts so the Intel compilers use the older cctools, and then using the modified scripts to build and install the PPC and Intel native and cross compilers.

To leave Apple's Xcode installed version of cctools unmodified, I ended up using an Open Darwin odcctools package since that package's install script was written to allow for easy installing to a user specified installation directory. (Apple's cctools package install script isn't written to allow for easy user specification of an installation directory.)

Since I needed a later version of GPC (gpc-20060325) than the version Adriaan has in his Mac OS X sources package for the bug fixes and additional MacPascal dialect support, I also updated Adriaan's Mac OS X gpc patch file and build scripts to build and install gpc-20060325 PPC and Intel native and cross compilers. In my updated version of Adriaan's Mac OS X sources package, I also included the odcctools package and modified Adriann's build-on-xx command scripts to include building and installing that package's tools.

My modified and updated version of Adriaan's Mac OS X GPC sources package is 24.2 MB when zipped. If you want a copy of it so you can build a gpc-20060325 based version of GPC for Mac OS X (PPC and/or Intel) which uses the older odcctools verion as for assembling to avoid the "indirect jmp without `*'" error messages, let me know.

In regards to who might be encountering the problem, it is only those Mac OS X users who are using the Xcode version 2.4.x installed as to assemble the GPC generated Mac Intel assembly code output that will experience the problem.

Gale Paeper gpaeper@empirenet.com

On Mar 9, 2007, at 10:59 AM, Frederick Karl Kepner DuPuy wrote:

First, though: on rereading my original email it occurs to me that I at one point I wrote a trifle too elliptically, so I'll explain now, just in case it wasn't clear before. I wrote: "programs which used to compile and execute happily with the gpc for PPC compiler are less happy with the gpc for Intel compiler." I should have made clear that I was referring, of course, to two different computers: I've just bought a new intel-chipped Mac and discovered the problem when recompiling old programs written on and for an older PPC-chipped one.

Actually, using two different computers (i.e., PPC versus Intel Mac) isn't necessary to figuring out your problem. The critical and essential part was compiling code for a Mac Intel target. That last time Adriaan had the time to release Mac OS X GPC packages, he put a lot of work into providing compiler support for creating universal binaries regardless of whether one was using a PPC or Intel Mac. If you look into the packages Adriaan has available for downloading both the PPC and Intel hosted packages have included in them a GPC cross compiler targeting to non-native architecture. Thus, you could have been using a PPC Mac and the GPC Intel target cross compiler or using a Intel Mac and the GPC Intel native compiler and the error message problem would have been exactly the same with the same potential solutions.

OK, so my questions. Reading what you wrote, am I right in getting the impression that the problem has something to do with the attempt to build a universal binary (one that will run on intel- or PPC-based macs)? This in involves, if i understand correctly, compiling the code twice and bundling the two together; are you saying that the error messages are coming from the failure of one of the two attempts, but the other one is succeeding (thus allowing the program, as observed, to nonetheless execute happily)? (Thanks to Rosetta, I suppose either of the two could be the working one.)

Although you'll encounter the problem when creating a universal binary because you need a Intel machine code object file as part of the process of creating the universal binary, it isn't necessary to be creating a universal binary for the problem to occur. All that is required is GPC compiling for an Intel Mac target either using the PPC Mac hosted GPC cross compiler or the Intel Mac hosted GPC native compiler.

After the problem was discussed in the October 2006 thread, I never looked into what would happen for the universal binary build case so I'm not sure what actually happens when trying to build a universal binary. After Waldek suggested trying an older version of the as assembler for compiling to workaround the problem of the changed assembly code syntax for indirect jump instructions, that's where I focused all my efforts.

Am I getting all that right? Well, if that's the issue, I should mention that my programming is entirely a hobby for myself so I don't really need to build universal binaries-- I'd be happy just compiling for intel on this computer (and recompiling for PPC on the old one if I ever went back there).

On an Intel Mac, you're going to have a problem when compiler for an Intel code target unless you use either Adriaan's or my workaround solutions. As noted above, regardless of wether your using a Intel or PPC Mac to compile code for an Intel machine code target, you'll encounter the problem. Compiling code for a PPC machine code target whether on an Intel Mac or a PPC mac works just fine even with Apple's latest version as assembler.

On Mar 11, 2007, at 3:11 AM, Adriaan van Os wrote:

Frederick Karl Kepner DuPuy wrote:

...

Secondly, as you can see from my second email, I took the advice of Adriaan van Os and rolled back my assembler/linker to version 590.36. (They had previously been v. 622.5.) But what you write has gotten me worried: although this solved my present gpc compiling problem, have I messed with the Xcode suite in a way I shouldn't have-- one which could come back and bite me in the future should I ever begin to use it properly? (Right now command-line gpc is all I do; but who knows what the future might hold!) Was I irresponsible?

There is little reason to worry. You can always reinstall Xcode later, which will reinstall cctools-622.5 (or whatever version Apple includes). Besides, the solution I proposed is a temporary one. As soon as I have a little time, I will look at providing a new compiler build. But of course, you can also use the compiler built by Gale Paeper, as outlined in his previous post.

Given that you're only compiling with GPC, I agree with Adriaan's "little reason to worry". I think you won't have a problem with the older version cctools unless you starting using Apple's gcc to compile code which relies upon some new feature supported in the latest Apple gcc compiler such as 64 bit Intel code targeting.

The main reason I went with a separate cctool installation for GPC only usage (actually my GPC build only uses just the as assembler from the separated cctools installation) was because it avoided any and all potential problems with tool version mismatch problems when using Apple's gcc compiler to compile other code projects. Since I need to upgrade to a newer version of GPC for other reasons anyway, adding in the separate installation of cctools and directing the GPC build to use that installation's as assembler for Intel targets was a relatively small and easy part of the Mac OS X GPC upgrade process.

Adriaan, in case it helps and if you decide to remain with a gcc 3.4.5 base for the new compiler build, the jump instructions causing all the assembler errors all seems to be the "jmp %edx" instructions used in each ".picsymbol_stub" code block. Due to lack of familiarity with the backend code generation code and not enough time available to figure out what the proper code fix was, I abandoned trying to fix the root cause of the assembler indirect jump error messages and went with using Waldek's suggestion to use an older as assembler version. (I'll also note your Mac OS X GPC sources package was a big help in getting a running start on getting gpc-20060325 built for Mac OS X.)

Gale Paeper gpaeper@empirenet.com