Hi,

I just tried to update one of my Windows VM with the latest released FPC. To my surprise there is no Win64 release for FPC 2.6.2 on SourceForge? I only found a 32-bit cross-compiler.

Why is this?

Regards,
- Graeme -

2013.04.30. 20:39 keltezéssel, Graeme Geldenhuys írta:

http://sourceforge.net/projects/freepascal/files/Win32/2.6.2/fpc-2.6.2.x86_64-win64.exe/download

Gabor

Gabor Boros wrote

http://sourceforge.net/projects/freepascal/files/Win32/2.6.2/fpc-2.6.2.x86_64-win64.exe/download

That's what I thought too, but that is a 32-bit cross-compiler for 64-bit targets. I wanted a real 64-bit compiler.

In the end I just downloaded the FPC source, and built my own 64-bit compiler.

Regards,
- Graeme -

Because it has no advantage over the 32 bit cross compiler. FPC never hits the 2 or 3 GB limit, a 64 bit compiler executable is slower, 32 bit executables run perfectly on 64 bit windows. So we can just provide two installers: a basic one targetting 32 bit win and an additional one for people needing 64 bit development, all regardless of their host system.

This sounds like a good candidate for a new FAQ item (I couldn't find an existing one by searching for Win64, but I may have missed something on the currently used 3 inch display, of course)...

Tomas

Graeme Geldenhuys wrote

In the end I just downloaded the FPC source, and built my own 64-bit compiler.

Why do you need a 64 bit compiler? (just curious)

Joao Morais wrote

Why do you need a 64 bit compiler? (just curious)

Huh? Because I was running 64-bit Windows 7, and needed to test and resolve a 64-bit bug. My system was already setup with 64-bit Lazarus and 64-bit FPC 2.6.0. I didn't want to read 10's of pages on how to setup a cross compiler etc. Not to mention I have never had great success (buggy end results) with cross-compilers in the past (though that experience was all under Linux).

But like I said, my problem was resolved quite easily by simply compiling it myself.

I personal opinion is that even though a 64-bit FPC under Windows might not be as fast as a 32-bit FPC. They [the FPC team] introduce an unnecessary stumbling block for those wanting to create 64-bit apps. Linux, FreeBSD, MacOSX all have official 64-bit versions of the FPC compiler.

Regards,
- Graeme -

You don't have to read anything, it works exactly the same as a regular compiler. Lazarus nor the compiler cares at all about what architecture the compiler binary is.

Not to mention I have never had great success (buggy end results) with cross-compilers in the past (though that experience was all under Linux).

Maybe you tried to build and install them yourself? Cross-building the compiler and its packages itself can indeed be somewhat more complicated than building a native compiler.

The Mac OS X 64-bit compilers are also cross-compilers (although the x86-64 binaries are actually a bit faster on Mac OS X, but it reduces the packaging and testing burden).

Jonas

I did initially try to use it with Lazarus IDE. I setup Lazarus IDE by pointing it to the cross-compiler, then tried to compile my project. It failed - can't remember the error. In hindsight, it was probably because I failed to specify a Target and OS platform in the "Project Options|Compiler Settings" - not sure.

Anyway, not to waste time debugging that or reading docs, I simply built a true 64-bit compiler. My project then compiled without problems.

The Mac OS X 64-bit compilers are also cross-compilers (although the x86-64 binaries are actually a bit faster on Mac OS X, but it reduces

Any thoughts on why it is slower on Linux and Windows then? It is just a lack of compiler optimisation?

Regards,
- Graeme -

Since the cross-compiler is the only official Win64 compiler we distribute, I'd assume more people would have problems with it if it wouldn't work out of the box with Lazarus.

I don't know whether it's slower on Linux. In any case, a major difference between Mac OS X and the other platforms is the on Mac OS X, several performance-critical RTL routines are mapped to the system C library, whose routines are tuned specifically for the cpu of the current machine on Mac OS X (and which are in general probably also more optimised than the routines which we have in our RTL). Codegeneration-wise there is virtually no difference between Linux and Mac OS X on x86-64. Win64 uses a different ABI, but I don't know whether it is (much) less efficient.

Jonas

Hi,

John Lee made the suggestion that an "unofficial" 64-bit Windows compiler archive be made available - for those people like me.

You can now download it from the Free Pascal FTP site:

ftp://ftp.freepascal.org/fpc/dist/2.6.2/x86_64-win/

--------[ readme.txt ]--------------
64 bit win fpc 2.6.2

generated by Graeme Geldenhuys, uploaded by John Lee fpc.cfg is set up for Graeme's config

NB this version is not generated as part of the distribution by the fpc developers since it is not believed to offer any/many advantages cf the win32 version frunning on a win 64 bit target.

May 2013
------------------------------------

Hope somebody finds it useful.

Regards,
- Graeme -

A personalised unofficial zipfile does not belong under /dist on the fpc site. The files there are all proper installers that are officially supported by us. At most it can be added under /contrib, but even then it should be a generic installer rather than just a zipfile of the installation on someone's hard drive.

Jonas

I wanted to mention that Lazarus comes with a 64bit FPC 2.6.2 from binaries...

Guys, Graeme is well meaning here. I agree that most of us first go to x64 downloads for binaries. Thinking 32 to 64 or reverse is onerous on typical end users.

I need 64bit FPC binaries too. Presently I install the Lazarus to get 64bit FPC, then checkout svn FPC/trunk and Lazarus/trunk. I do this every time because of the fact that there is no 64bit FPC.

Others do this too. You are looking at this too much from the internals. This is a case where the Customer is right I can assure you.

But the solution must conform to FPC standards with regards to builds/packaging.

Thanks for any help in offering a 64bit download of FPC.

Andrew Brunner,

Aurawin LLC
512.574.6298
http://aurawin.com/

Aurawin is great new way to store and share your pictures, videos, and more, featuring our innovative Pure Cloud social computing platform.

In our previous episode, Andrew Brunner said:

Guys, Graeme is well meaning here. I agree that most of us first go to x64 downloads for binaries. Thinking 32 to 64 or reverse is onerous on typical end users. I need 64bit FPC binaries too. Presently I install the Lazarus to get 64bit FPC,

For bootstrapping purposes, you can simply get the 64-bit ppcx64 compiler at ftp://freepascal.stack.nl/pub/fpc/dist/2.6.2/bootstrap/ :

ftp://freepascal.stack.nl/pub/fpc/dist/2.6.2/bootstrap/x86_64-win64-ppcx64.zip

A checkout of the fpcbuild repository will give you the necessary binutils.

Andrew Brunner wrote

I agree that most of us first go to x64 downloads for binaries. Thinking 32 to 64 or reverse is onerous on typical end users.

The whole point is that the "typical end user" doesn't know nor should have to care about whether the compiler is a 32 or 64 bit binary. It should not make any difference whatsoever. If it does, then that's either a bug in FPC, or in Lazarus, its fpmake files or Makefiles (or fpcmake).

Jonas

Jonas Maebe wrote

The whole point is that the "typical end user" doesn't know nor should have to care about whether the compiler is a 32 or 64 bit binary. It should not make any difference whatsoever.

How does the saying go: "I want to live in Theory, because everything works in theory." ;-)

And since when is a developer a "typical end user"?

If I run 64-bit Mac or 64-bit Windows or 64-bit Linux, I want 64-bit applications. Some OS's allow for easier execution of 32-bit apps, but definitely not all. All my systems run 64-bit OS's, and all my installed libraries etc are 64-bit too (think Firebird, etc). 32-bit executables cannot load 64-bit libraries, so I need 64-bit executables.

To put it simply, that is the reason I (and many others) need a 64-bit FPC. I've had lots of bad experiences with FPC cross-compilers - from installing headaches, to broken executables (don't ask me why, I don't know why). So I simply don't trust FPC cross-compliers. This is why I have various build systems in VM's for all our supported platforms.

And if FPC developers have to download Lazarus setups (a product not actually part of Free Pascal), just to get the FPC they want, that should say something to the Free Pascal team too. Release what the public wants.

And just to make it clear... it was NOT my idea to release my build of FPC 2.6.4 for 64-bit Windows. I was asked in private to archive what I have and make it available for download (on my own server). That is what I did.

Regards,
- Graeme -

I agree with what you are saying as long as the os matches the binary type. An x64 native package must install a x64bit binary and utils.

I would be understating if I said that a 32bit binary would be normal on a 64bit distro.

Andrew Brunner
Aurawin LLC
512.574.6298

A safe new way to store and share your files, pictures, videos and more.

http://aurawin.com

It does not matter in any way whatsoever on Windows (which is what the thread is about), where 32 and 64 bit binaries can always run transparently side by side on 64 bit versions of the OS without any need for the user to install special packages. On Mac OS X the situation is even more transparent because there even several systems that boot a 32 bit kernel can run 64 bit applications. In other words, there is no relation whatsoever between the "bitness" of the kernel and the "bitness" of the applications on Mac OS X.

Jonas

No, it goes: "nobody ever submitted a bug report about this nor posted anything on the FPC mailing list and I don't use Windows myself, so this is the first I hear about it". Problems need to be reported and fixed.

And since when is a developer a "typical end user"?

That's a non sequitur. As mentioned, it has to work out of the box.

If I run 64-bit Mac or 64-bit Windows or 64-bit Linux, I want 64-bit applications. Some OS's allow for easier execution of 32-bit apps, but definitely not all.

That's why I explicitly mentioned in my previous mail that the thread was about Windows. We do offer 64 bit compiler binaries for Linux.

All my systems run 64-bit OS's, and all my installed libraries etc are 64-bit too (think Firebird, etc). 32-bit executables cannot load 64-bit libraries, so I need 64-bit executables.

That is about the produced programs, not about the compiler binary itself.

Every single person using the Mac OS X version to build 64 bit applications uses a cross-compiler and I've never seen any bug reports or complaints about it. As mentioned before, I don't remember seeing any bug reports either related to the Win64 compiler being a cross-compiler (other than people asking to get a 64 bit binary with as only reason that it would then be a 64 bit binary).

I'm not saying that you are wrong when you say that you have had problems with (self-built?) cross-compilers (where are the bug reports?), just that this is all unrelated to an official installer provided by us that is fully tested and supported (other than the Lazarus integration problem that apparently exists), and that there are plenty of data points to indicate that cross-compiling with FPC in general is not intrinsically broken nor hard (cross-building FPC yourself can be harder, but as you mentioned we are talking about typical end-users and not about developers).

And just to make it clear... it was NOT my idea to release my build of FPC 2.6.4 for 64-bit Windows. I was asked in private to archive what I have and make it available for download (on my own server). That is what I did.

I don't mind that you did, only the fact that a personal installation was placed in the distribution location on the official FPC ftp site (and I know you are not responsible for that in any way).

Jonas

Unlike Linux which can indeed be a headache regarding cross compilers the 64-bit cross compiler works without problems on Windows (because you don't need library paths, the binutils are not needed, etc.)

Regards,
Sven

In our previous episode, Graeme Geldenhuys said:

It was the least you could do after travelling forward in time to obtain 2.6.4 :-)

I have not had bad experience with cross-compilers, as far as the compilers not working as of yet. However, let me state for the record, that a vast majority of the compiling that I will be doing will be exclusively for 64-bit systems, and I simply do not want to be forced to compile a 32-bit program on Windows, then cross-compile it into a 64-bit program. That is just ludicrous. I want to direct compile a native 64-bit applications, period. Even when I use Lazarus, it's just used to build forms. I have another IDE that I much prefer for the actual coding and compiling work.

As a developer, and as a father of 2 young children, I don't have time to have to compile my own compilers and get everything fixed. I want to download FPC_x86_64 for Windows and just get to work with it so that I have more time with my children.

Hello.
I want add access to AT-SPI interface.
http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface

Does it exist a pascal header for that ?
Does anybody know how to do it, via fpc, not lcl ? Thanks.

Cross-compilers also directly generate code for the target platform (64 bit Windows in this case). The term simply refers to the fact that the architecture of the compiler binary itself, or the platform it runs on, is different from the architecture/platform of the code that it generates. In this particular case, the compiler binary is a Win32 program that directly generates Win64 code. There is no intermediate step.

Jonas

Jonas Maebe wrote

No, it goes: "nobody ever submitted a bug report about this nor posted anything on the FPC mailing list and I don't use Windows myself, so this is the first I hear about it". Problems need to be reported and fixed.

[...]

Every single person using the Mac OS X version to build 64 bit applications uses a cross-compiler and I've never seen any bug reports or complaints about it. As mentioned before, I don't remember seeing any bug reports either related to the Win64 compiler being a cross-compiler (other than people asking to get a 64 bit binary with as only reason that it would then be a 64 bit binary). I'm not saying that you are wrong when you say that you have had problems with (self-built?) cross-compilers (where are the bug reports?), just that this is all unrelated to an official installer provided by us that is fully tested and supported (other than the Lazarus integration problem that apparently exists), and that there are plenty of data points to indicate that cross-compiling with FPC in general is not intrinsically broken nor hard (cross-building FPC yourself can be harder, but as you mentioned we are talking about typical end-users and not about developers).

Cross compiler building is broken for FPC 2.7.1 on Ubuntu and Fedora. I had submitted a couple of bug reports and made several posts in this mailing list, but all went unnoticed or were not handled. I have almost lost hope.

Bug reports:
http://bugs.freepascal.org/view.php?id=24262
http://bugs.freepascal.org/view.php?id=24372

I used to build on an Ubuntu 32 bit machine cross compilers for several targets using FPC 2.6.0 and previous releases. However as of FPC 2.6.3, some targets succeeded only using workarounds. With 2.7.1 I can not build any cross compiler. I am not sure why nobody else is complaining (could it be me the culprit??), but again, cross compiler building is not everybody's hobby.

As for the integration with Lazarus, what problems do you have in mind? I simply build binutils for each target (a one time task), compile the FPC version (using latest release or starting compiler), then build the cross compiler for the different targets. As for Lazarus, I have setup default build modes so that with exactly 2 mouse clicks I can change the project's target.

I can even fire up Lazarus using any FPC version (2.6.0, 2.6.2, 2.6.3, 2.7.1, etc...) by selecting the version in a script.

Stephano

patspiper wrote

Cross compiler building is broken for FPC 2.7.1 on Ubuntu and Fedora. I had submitted a couple of bug reports and made several posts in this mailing list, but all went unnoticed or were not handled. I have almost lost hope. Bug reports: http://bugs.freepascal.org/view.php?id=24262

You presumably have to add something like CROSSOPT="-XR/path/to/your/32bit/root -Fl/directory/containing/your/32bitlibgcc". As Florian mentioned, the compiling the entire tree now depends on certain C libraries, and hence you have to tell the build process where to find these (and the associated startup code files) if they are not in the standard directories.

http://bugs.freepascal.org/view.php?id=24372

And does the linker not interpret that parameter correctly? Even if it doesn't, that does not appear to be a problem specific to cross building.

Jonas

PS: when asking questions about a different topic, at change the subject (and preferably start a new thread altogether)

I learned from the free pascal wiki and installed the LazDaemon package.

I 'new' a project as a Daemon (Service) application. However, when I compile it, it has many (dozens of) warnings e.g. undefined reference to 'WSRegisterCustomPage',
'WSregisterCustomNotebook', 'WSRegisterCustomIamgeList' ....

Finally, it has a fatal error: Error while linking.

Can anyone help?

I also tried the example cleandir and it complied ok but then I don't know the next step to install this daemon in Ubuntu. (Sorry, I don't know linux much). It produced a 1.3M cleandir file (no extension)

Thanks in advance.

Dennis

These reports are not about cross-compiling to windows but linux. Cross-compiling to linux was and is always a pain while it works perfectly for windows for years. As Jonas said, cross-compilation from win32 to win64 works perfectly for years. We provide this setup for over 5 years. Afaik there was never a native win64 release of fpc.

While trying to debug my ARM cross-compile problems (in another email thread) I decided to replicate the cross-compiler setup to i386 (to compare it for clues) but I've run into another problem with x86_64 -> i386 cross compiling which seems related to this thread.

My cross built fpc 2.7.1 works just fine for x86_64 -> i386 when fpc.cfg has:

#IFDEF LINUX
#IFDEF CPUI386
-Xd
-k--sysroot=/usr/local/opt/chroot/i386-linux-squeeze -FD/usr/local/opt/binutils/bin
#ENDIF
#ENDIF

that is, when built against a Debian Squeeze crossroot.

However when linked against a Wheezy crossroot:

#IFDEF LINUX
#IFDEF CPUI386
-Xd
-k--sysroot=/usr/local/opt/chroot/i386-linux-wheezy -FD/usr/local/opt/binutils/bin
#ENDIF
#ENDIF

It fails reporting lines like this:

(.text+0x795): undefined reference to `__divdi3'

This indicates libgcc is not being pulled in (the Wheezy case).

Wheezy is multarch and -Xd means no standard locations are searched by fpc anyway, so in light of these two bug reports:

http://bugs.freepascal.org/view.php?id=24372
http://bugs.freepascal.org/view.php?id=24262

I amended fpc.cfg as:

#IFDEF LINUX
#IFDEF CPUI386
-Xd
-k--sysroot=/usr/local/opt/chroot/i386-linux-wheezy -Fl/usr/local/opt/chroot/i386-linux-wheezy/lib/i386-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/lib/i486-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i486-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/local/lib -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4 -FD/usr/local/opt/binutils/bin
#ENDIF
#ENDIF

It still did not pull in libgcc but I know libgcc.a in the correct place (in the crossroot) so I recompiled with -Cn and linked with ppas.sh after manually adding -lgcc to the GROUP statement in link.res, it linked correctly.

So my question is; what am I missing in the wheezy case that means libgcc is not applied during the link where as (with everything else being identical) the squeeze case does work "out of the box" (i.e. no explicit -lgcc needs to be applied in the link.res file).

Thanks, Bruce.

In our previous episode, Bruce Tulloch said:

This indicates libgcc is not being pulled in (the Wheezy case).

That's what I would expect yes.

My guess is that the default glibc references the gcc and it gets pulled in, and it doesn't in the cross situation (so you have to manually add a reference to it)

I think that can be considered a bug in those cross libs.

To check this compile a simple cthreads using program straight and cross with -s. This allows you to inspect the link.res in both cases.

If -lgcc isn't necessary in one case, but it is in the other, I assume it is a library dependency problem

Yes, that's what thought, but why the difference between the cross compiled squeeze/i386 case (which works) and the cross compiled wheezy/i386 one (which does not)?

That is, both are cross builds, both are building the same code in the same way, the only difference is the crossroot against which they're built.

The link.res file differences between them seems moot:

*** /tmp/link-squeeze-i386-cross.res 2013-05-24 19:23:25.000000000 +1000 --- /tmp/link-wheezy-i386-cross.res 2013-05-24 19:19:29.000000000 +1000 ***************
*** 1,3 ****
--- 1,7 ----
+ SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/")
+ SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/usr/local/lib/")
+ SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/")
+ SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/lib/i386-linux-gnu/") SEARCH_DIR("/home/bruce/.home/hg/lazarus/lcl/units/i386-linux/gtk2/") SEARCH_DIR("/home/bruce/.home/hg/lazarus/lcl/units/i386-linux/") SEARCH_DIR("/home/bruce/.home/hg/lazarus/components/lazutils/lib/i386-linux/") ***************
*** 103,108 ****
--- 107,114 ----
SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/i386-linux/gdbm/") SEARCH_DIR("/usr/local/lib/fpc/2.7.1/")
INPUT(
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crti.o
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtbegin.o test-interfaces.o
test-interfaces.or
/usr/local/lib/fpc/2.7.1/units/i386-linux/rtl/system.o ***************
*** 374,379 ****
--- 380,389 ----
GROUP(
-lc
)
+ INPUT(
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtend.o
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crtn.o
+ )
ENTRY(_start)
SECTIONS
{

That is, the wheezy case has four additional search paths and it has four additional INPUT statement lines (adding crti.o, crtbegin.o, crtend.o and crtn.o). These differences do not appear material. If the INPUT lines are removed from the wheezy case and ppas.sh run, it still does not link.

The native build is very similar too (see below), I can't see any dependency differences that would explain why gcc is not pulled in for the wheezy/i386 cross compile case but it IS pulled in for the squeeze/i386 cross compile AND the wheezy/x86_64 native compile.

Something is affecting the linker's behaviour which is NOT in the link.res script I think.

Bruce

*** /tmp/link-wheezy-x86_64-native-summary.res 2013-05-24 19:36:41.000000000 +1000
--- /tmp/link-wheezy-i386-cross-summary.res 2013-05-24 19:36:58.000000000 +1000
***************
*** 1,15 ****
! SEARCH_DIR("/lib64/")
! SEARCH_DIR("/home/bruce/.home/hg/lazarus/lcl/units/x86_64-linux/gtk2/") ! SEARCH_DIR("/home/bruce/.home/hg/lazarus/lcl/units/x86_64-linux/") ! SEARCH_DIR("/home/bruce/.home/hg/lazarus/components/lazutils/lib/x86_64-linux/") ! SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/x86_64-linux/utmp/") ! SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/x86_64-linux/svgalib/") ! SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/x86_64-linux/lexyacc/") SEARCH_DIR("/usr/local/lib/fpc/2.7.1/")
INPUT(
! /usr/local/lib/fpc/2.7.1/units/x86_64-linux/rtl/cprt0.o test-interfaces.o
test-interfaces.or
)
INPUT(
-ldl
--- 1,18 ----
! SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/") ! SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/usr/local/lib/") ! SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/") ! SEARCH_DIR("/usr/local/opt/chroot/i386-linux-wheezy/lib/i386-linux-gnu/") ! SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/i386-linux/unixutil/") ! SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/i386-linux/libc/") ! SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/i386-linux/utmp/") ! SEARCH_DIR("/usr/local/lib/fpc/2.7.1/units/i386-linux/svgalib/") SEARCH_DIR("/usr/local/lib/fpc/2.7.1/")
INPUT(
! /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crti.o ! /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtbegin.o test-interfaces.o
test-interfaces.or
+ /usr/local/lib/fpc/2.7.1/units/i386-linux/rtl/si_c21.o )
INPUT(
-ldl
***************
*** 29,39 ****
GROUP(
-lc
)
ENTRY(_start)
SECTIONS
{
! PROVIDE (__executable_start = 0x0400000); . = 0x0400000 + SIZEOF_HEADERS; ! . = 0 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
--- 32,45 ----
GROUP(
-lc
)
+ INPUT(
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtend.o
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crtn.o
+ )
ENTRY(_start)
SECTIONS
{
! PROVIDE (__executable_start = 0x010000); . = 0x010000 + SIZEOF_HEADERS; .interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
***************
*** 90,97 ****
}

    . = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1));
    .dynamic        : { *(.dynamic) }

! .got : { *(.got .toc) }
! .got.plt : { *(.got.plt .toc.plt) }
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
--- 96,103 ----
}

    . = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1));
    .dynamic        : { *(.dynamic) }

! .got : { *(.got) }
! .got.plt : { *(.got.plt) }
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
***************
*** 114,143 ****

    PROVIDE (end = .);
    .stab          0 : { *(.stab) }
    .stabstr       0 : { *(.stabstr) }

- /* DWARF debug sections.
- Symbols in the DWARF debugging sections are relative to the beginning
- of the section so we begin them at 0. */
- /* DWARF 1 */
- .debug 0 : { *(.debug) }
- .line 0 : { *(.line) }
- /* GNU DWARF 1 extensions */
- .debug_srcinfo 0 : { *(.debug_srcinfo) }
- .debug_sfnames 0 : { *(.debug_sfnames) }
- /* DWARF 1.1 and DWARF 2 */
- .debug_aranges 0 : { *(.debug_aranges) }
- .debug_pubnames 0 : { *(.debug_pubnames) }
- /* DWARF 2 */
- .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
- .debug_abbrev 0 : { *(.debug_abbrev) }
- .debug_line 0 : { *(.debug_line) }
- .debug_frame 0 : { *(.debug_frame) }
- .debug_str 0 : { *(.debug_str) }
- .debug_loc 0 : { *(.debug_loc) }
- .debug_macinfo 0 : { *(.debug_macinfo) }
- /* SGI/MIPS DWARF 2 extensions */
- .debug_weaknames 0 : { *(.debug_weaknames) }
- .debug_funcnames 0 : { *(.debug_funcnames) }
- .debug_typenames 0 : { *(.debug_typenames) }
- .debug_varnames 0 : { *(.debug_varnames) }
- /DISCARD/ : { *(.note.GNU-stack) }
}
--- 120,123 ----

I've solved the problem (in my case at least).

http://lists.freepascal.org/lists/fpc-pascal/2013-May/038254.html

Thanks for your suggestions Marco (and also thanks to Jonas!).

Bruce.