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