Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2015-03

Does a single cross compiler for a CPU used for all operating systems?

6 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

vfclists .

Does a single cross compiler for a CPU used for all operating systems?

eg ppcross386 is the cross compiler for i386. Is it the same compiler that would be used whether the target was a 32bit Linux, OS/X or Win32, with different linkers and libraries used for the final executable?

Frank Church ======================= http://devblog.brahmancreations.com

Reply by email

Sven Barth
to vfclists .
vfclists . wrote 5 lines
Does a single cross compiler for a CPU used for all operating systems? eg ppcross386 is the cross compiler for i386. Is it the same compiler that would be used whether the target was a 32bit Linux, OS/X or Win32, with different linkers and libraries used for the final executable?

That is correct. (an exception to this is ARM hard float which requires a different compiler binary than ARM soft float - if I remember correctly)

Regards,
Sven

Reply by email

Jon Foster
to Sven Barth

I'm building native code compilers for Android. I've been assisting the PascalDevelop project available in the Play Store:

https://play.google.com/store/apps/details?id=com.assoft.PascalDevelop

I'm working with the 3.0.0rc2 release and building whichever units will. The current version of the app ships with the older 2.6.x compiler.

What we've discovered is that if we try to run the compiler on Android 5 (Lollipop) or greater the binary won't load and complains that it isn't a "Position Independent Executable" (PIE). This is a feature similar to PIC. In GCC they have a separate flag -fPIE as opposed to the -fPIC. The purpose is to make the whole executable relocatable to facilitate "randomized address spaces".

If I build a standard "program" (not library) with -Cg do I get a PIE... or does that only affect linking for libraries? I haven't been able to find anything on the iNet regarding PIE and FPC.

THX - Jon

Sent from my Debian Linux laptop -- http://www.debian.org/intro/about Jon Foster JF Possibilities, Inc. 541-410-2760 Making computers work for you!

Reply by email

Adriaan van Os
to Jon Foster
Jon Foster wrote
If I build a standard "program" (not library) with -Cg do I get a PIE... or does that only affect linking for libraries? I haven't been able to find anything on the iNet regarding PIE and FPC.

Wouldn't that just be a linker option, passed-on to ld ?

Adriaan

Reply by email

Sven Barth
to Adriaan van Os
"Adriaan van Os" wrote 9 lines
Jon Foster wrote: > > If I build a standard "program" (not library) with -Cg do I get a PIE... > or does that only affect linking for libraries? I haven't been able to > find anything on the iNet regarding PIE and FPC. Wouldn't that just be a linker option, passed-on to ld ?

Not if the compiler needs to ensure that the code it generates is generated position independently as well. I don't know though in how far the requirements for PIC are different from PIE.

Regards,
Sven

Reply by email

Jonas Maebe
to Jon Foster: I'm building native code compilers for Android. I've been assisting the PascalDevelop…
Jon Foster wrote 10 lines
What we've discovered is that if we try to run the compiler on Android 5 (Lollipop) or greater the binary won't load and complains that it isn't a "Position Independent Executable" (PIE). This is a feature similar to PIC. In GCC they have a separate flag -fPIE as opposed to the -fPIC. The purpose is to make the whole executable relocatable to facilitate "randomized address spaces". If I build a standard "program" (not library) with -Cg do I get a PIE... or does that only affect linking for libraries? I haven't been able to find anything on the iNet regarding PIE and FPC.

The problem is that the startup code for Android, which is handwritten assembly and hence not affected by any compiler switches, contains non-PIC code.

This has been fixed in trunk fairly recently, but it was too late for 3.0.

Jonas

Reply by email