Hello,

Now that Mac OS X 10.5 has been (more or less) released, some notes on issues you may encounter when using FPC 2.2.0 (or earlier) on that new Mac OS X release. All issues are related to the fact the Apple now uses a different linker (the old 32 bit linker has been scrapped, and the old 64 bit linker has been extended to support all targets -- well, it already could link code for all targets in 10.4, but only 64 bit targets were supported by Apple).

Note that the information below is based on information gathered from testing on pre-release versions of Mac OS X 10.5, so the final version may still be different.

* The new linker refuses to link dynamic libraries containing non-PIC (position-independent code)
- Effect: you can't compile dynamic libraries anymore with FPC 2.2.0
- Occurs: whenever you compile a dynamic library. I don't know whether FPC-compiled dynamic libraries compiled on 10.4 still work on 10.5.
- Fix: already in FPC 2.3.1 and FPC 2.2.1 (FPC now always generates PIC by default on Darwin)

* There is a bug in the new i386 linker regarding dealing with certain kinds of relocations, which is triggered by the instructions which FPC generates for jump tables.
- Effect: crash of the compiled code
- Occurs: when compiling i386 code with large case statements on Mac OS X 10.5, mostly when using -O1 and higher. i386 programs compiled on Mac OS X 10.4.x containing such jump tables however work fine when run on Mac OS X 10.5 (as the 10.4.x linker does handle those relocations correctly).
- Fix: This will have to be fixed by Apple. I have however added a workaround in FPC 2.3.1 and FPC 2.2.1 which mostly avoids generating the crashing relocation (and the resulting code is faster to boot). The only case in which it can still happen is an enumeration or subrange type of which the lowest element has an ordinal value > 0, and you have a case statement which is translated to a jump table in which this lowest element is used. E.g.

type
   tmysub = 5..50;
var
   x: tmysub;
begin
   case x of
     5: writeln(5);
     6: writeln(6);
     ...
     50: writeln(50);
   end;
end.

* There is a bug in the new linker when dealing with certain kinds of (invalid?) Dwarf debug info
- Effect: crash of the linker, e.g. when linking a compiler which is compiled with Dwarf debug info
- Occurs: I have not yet been able to isolate which specific kind of Dwarf debug info causes the crash
- Fix: It seems the Dwarf info generated by the latest FPC 2.3.1 no longer crashes the linker. I'm not sure if all Dwarf fixes have already been merged back to 2.2.1 though.

* The new linker deals differently with stabs debug information compared to previous versions, causing a lot of "Unknown stabs" warnings and also some errors during linking
- Effect: you can't compile code with stabs debug information
- Occurs: with any program compiled with stabs debug information (programs compiled on 10.4 with stabs may still be debuggable on 10.5 though)
- Fix: already in FPC 2.3.1 (not yet merged to FPC 2.2.1)

I will merge the fixes for the last two issues to FPC 2.2.1 some time during the coming days and put up snapshot installers with that version for PPC and i386 on the ftp site.

Jonas

Jonas Maebe wrote

Now that Mac OS X 10.5 has been (more or less) released, some notes on issues you may encounter when using FPC 2.2.0 (or earlier) on that new Mac OS X release.

There's also some good news: gdb can now display parameters and local variables inside nested functions when you use Dwarf debug information.

Jonas

Jonas Maebe wrote

I will merge the fixes for the last two issues to FPC 2.2.1 some time during the coming days and put up snapshot installers with that version for PPC and i386 on the ftp site.

They are now uploaded and available at respectively (mind the line wraps)

PowerPC (25MB):
< ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v22/powerpc-macosx/ fpc-2.2.1-r8950.powerpc-macosx.dmg >

Intel (41MB):
< ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v22/i386-macosx/ fpc-2.2.1-r8950.intel-macosx.dmg >

As of tomorrow they will also be available from the mirrors (except for SourceForge) via the website.

Jonas

PS: these snapshots also work on previous versions of Mac OS X, but unless you know that a particular bug which affects you has been fixed in FPC 2.2.1 in the mean time, it's advisable to stay with the previous release for now.

Strange. I installed FPC 2.3.1 from svn and I still get the unknown stabs errors.
And I get a lot warnings like:
ld: warning in zbase.o, file is not of required architecture And finally a lot of missing symbols so linking fails. :(

Any hint?

I will merge the fixes for the last two issues to FPC 2.2.1 some time during the coming days and put up snapshot installers with that version for PPC and i386 on the ftp site.

Mattias

The unknown stabs are only in the LCL units, not in the FPC units. So apparently FPC knows a trick.
Does someone know the trick?

And I get a lot warnings like: ld: warning in zbase.o, file is not of required architecture And finally a lot of missing symbols so linking fails. :(

Any hint?

Mattias

That's because it also has to be partly fixed in the linker (which I didn't realise when I posted that message). The unknown stabs warnings (they're not errors afaik) are caused by stabs for local constants in functions/procedures (the linker interprets them as function stabs, because they have a very similar format and gcc does not generate stabs for constants).

If you want, you can download a patched linker from http://trappist.elis.ugent.be/~jmaebe/cctools/ (extract it to some directory, add a symbolic link to /usr/bin/as in the same directory, and point FPC to it using the -FD command line switch). That linker corresponds to the one shipped with Xcode 3.0 (+ the patches in that directory).

But since end users most likely won't have that patched linker (and because stabs has been deprecated by Apple), you may want to switch to dwarf instead on Mac OS X 10.5+

And I get a lot warnings like: ld: warning in zbase.o, file is not of required architecture

That normally means what it says: you are trying to link a PowerPC object file into an Intel binary or vice versa. I don't know why this would happen unless you somehow overwrote certain object files without overwriting the associated ppu files, have some strange object search path, etc. You can use the file command to check the architecture of an object file using the "file" command.

And also take into account the comments of the first note at http://bugs.freepascal.org/bug_view_advanced_page.php?bug_id=11270#bugnotes (but that only affects the finally linked binaries and not the compilation of the unit object files).

And finally a lot of missing symbols so linking fails. :(

That's because of the right object files were not found.

Jonas

Mattias Gaertner wrote

The unknown stabs are only in the LCL units, not in the FPC units. So apparently FPC knows a trick. Does someone know the trick?

The "trick" is not using local constants.

Jonas

Thanks. That fixed the warnings.
Now only the wrong file formats.
zbase, gzio, crc, zdeflate, ... inffast. Hmm. These are only the .o files in paszlib.

I was wrong. There are some fpc files too. 'file' gives: inffast.o: Mach-O object i386.
Like all other.

Mattias

Mattias Gaertner wrote

Now only the wrong file formats. zbase, gzio, crc, zdeflate, ... inffast. Hmm. These are only the .o files in paszlib.

I can't reproduce it. One thing you can try is compiling with -Cn and checking the generated link.res file to make sure that the object files which are linked in are the ones you expect to be linked in.

Jonas

Zitat von Jonas Maebe :

I removed all fpc .o/.ppu files under /usr/local/lib and in lazarus. Then it worked. Apparently somewhere the fpc make install / lazarus make clean does not replace/delete all files.

Mattias

make install does not explicitly delete anything, at most it overwrites existing files. I'm not aware of the installed paszlib units changing place though (the packages reorganisation did not change that location).

Jonas

make clean does not delete installed files from make install.

Mattias

Michael Schindler

Different versions may have been the problem, such as /usr/local/lib/ fpc/2.2.0, /usr/local/lib/fpc/2.3.1, ...

Michael

Zitat von Schindler Karl-Michael :

Maybe you misunderstood: I did not use the lazarus 'make install'. I installed fpc with 'make install'. This installed fpc 2.3.1 in a separate directory (/usr/local/lib/fpc/2.3.1) (separate from the prior installed fpc 2.2.2rc1).
And I did a lazarus 'make clean all'. This lead to the strange linker errors.

Mattias

This is strange, since the FPC config files all use $fpcversion to set the unit paths. There was also no 2.2.2rc1 release for Mac OS X (although it may have been distributed along with some Lazarus snapshot(s)).

Jonas

Zitat von Jonas Maebe :

BTW, for some reasons 'make install' did not recreate the /etc/fpc.cfg. I did it manually by calling samplecfg with $fpcversion. But it did not make any difference. The errors stayed the same. I did not check the diff between both fpc.cfg.

There was also no 2.2.2rc1 release for Mac OS X (although it may have been distributed along with some Lazarus snapshot(s)).

Yes, I had to use the lazarus snapshot of fpc as start compiler, because the 2.2.0 failed to compile fpc 2.2.3 and 2.3.1 (Access Violation). What is the current startup compiler for Mac OS X 10.5?

But I don't think the 2.2.0 nor 2.2.2 had to do with the bug, because I didn't use 2.2.0 nor 2.2.2 to compile lazarus and the solution was to remove all the ppu files of 2.3.1 and lazarus. So 2.2.0 nor 2.2.2 never touched the ppu/o files.

The only explanation is that some ppu/o files mixed up. Maybe some search paths contain some invalid paths?

Mattias

That is by design. /etc/fpc.cfg is only created by the installers of releases on our website.

I did it manually by calling samplecfg with $fpcversion. But it did not make any difference. The errors stayed the same.

Well, if it found units before you did that, you probably had a .fpc.cfg somewhere in your home directory already.

That issue is documented on the FPC Mac OS X download pages and 2.2.1 starting packages for Mac OS X 10.5.x are are provided there.

Jonas

Zitat von Jonas Maebe :

Maybe. I didn't check.
I called samplecfg first as normal user and so samplecfg ignored my parameters and wrote the config to my home directory. A strange automatism. I deleted it and ran it again with sudo.
But if there was an ~/.fpc.cfg, then it could only be created by 2.2.0 or the 2.2.2rc1 snapshot. Maybe through the above automatism? But they all used $fpcversion, don't they? If yes, then all fpc versions should create a useful fpc.cfg?

Where?

I did this: drove browser to www.freepascal.org, click on download on the right panel, then Binaries / intel/i386 / Mac OS X, choose as mirror Sourceforge, and there is only the 2.2.0 version.

Mattias

It really is only intended to be run by installers, which is why its usage is nowhere documented. Snapshots are also only intended to be installed on top of official releases. On most if not all platforms at least some things are missing if you start with just a snapshots (such as binutils or a config file).

But if there was an ~/.fpc.cfg, then it could only be created by 2.2.0 or the 2.2.2rc1 snapshot.

No, samplecfg generates a ~/.fpc.cfg if it cannot create fpc.cfg in the designated location.

Maybe through the above automatism? But they all used $fpcversion, don't they? If yes, then all fpc versions should create a useful fpc.cfg?

If the basepath in the generated (.)fpc.cfg is correct, yes.

The problem is that there is no download page with explanations on sourceforge (I don't know whether it's even possible to do that). You can see it on all of the regular download pages. That release was however indeed never uploaded to sourceforge.

Jonas

Zitat von Jonas Maebe :

In this case you can call me 'installer'. ;)

I meant, that I only installed 2.2.0 and 2.2.2rc1 via a dmg. So these are the only candidates for running samplecfg.

All installations were in /usr/local/lib/fpc.

On the australian page there is only a small hint at the end of the page about dwarf debugging.

Mattias

Then that means that this mirror is not being updated for some reason. Try the Netherlands or ftp.freepascal.org mirror page.

Jonas

Thanks, but I just wanted to point out, that at the moment it is not easy to get a recent FPC and lazarus working on Mac OS X.

Mattias