Recent

Author Topic: 32-bit RIP relative reference out of range error for string constants in Cocoa  (Read 561 times)

LazProgger

  • Jr. Member
  • **
  • Posts: 91
When using the "external string constants" defined in NSPasteboard or NSFileManager in 64-Bit Cocoa such as NSFileType, NSFileCreationDate, NSStringPboardType and so on, I get an error of the following type:

ld: 32-bit RIP relative reference out of range (-4297995934 max is +/-4GB): from _..._$$_...$crc9E1F315A (0x1002E35F0) to _NSStringPboardType@0x00000000 (0x00000000) in '_..._$$_...' from /Users/.../lib/x86_64-darwin/FileAttributes.o for architecture x86_64

In 32-Bit Carbon, the following was possible:

Code: Pascal  [Select]
  1. var
  2.   AKey: NSString;
  3. begin
  4.   AKey := NSURLIsHiddenKey; // or any other constant
  5. end;

Now, I always get this error, no matter how I use the constants. Also something like ANSMutableDictionary.setObject_forKey(ADate, NSFileModificationDate), what was possible in Carbon, is not possible when compiling for 64 Bit Cocoa.

Does someone have an idea what one can do here?
« Last Edit: August 09, 2019, 02:39:36 pm by LazProgger »

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2290
    • havefunsoft.com
Does someone have an idea what one can do here?
what are your compiler options used? any custom settings?
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

trev

  • Sr. Member
  • ****
  • Posts: 252
  • Former Delphi 7 and Delphi 10.2 User
> Does someone have an idea what one can do here?

Are you sure you're using the 64 bit compiler?
o Lazarus v2.1.0 r61775, FPC v3.3.1 r42640, macOS 10.14.6 (with sup update), Xcode 10.3
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.0 (Parallels VM)
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 18.04 (Parallels VM)

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 674
> Does someone have an idea what one can do here?

Are you sure you're using the 64 bit compiler?
Yes, they are ("rip" is a 64 bit register).

My guess is that they disabled position-independent code (PIC; compiler option -Cg-).

LazProgger

  • Jr. Member
  • **
  • Posts: 91
My guess is that they disabled position-independent code (PIC; compiler option -Cg-).

Thank you very much! That was it! I have removed the -Cg- compiler option and it is working now!

It was an old app made for Carbon. I cannot remember exactly, but probably I have read somewhere at that time that you need the -Cg- option for Carbon. Can that be? So, for Cocoa it seems to be different?!


Are you sure you're using the 64 bit compiler?

Yes, it was the 64 bit compiler. And my app is also showing as 64 bit in the Activity Monitor now.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 674
My guess is that they disabled position-independent code (PIC; compiler option -Cg-).

Thank you very much! That was it! I have removed the -Cg- compiler option and it is working now!

It was an old app made for Carbon. I cannot remember exactly, but probably I have read somewhere at that time that you need the -Cg- option for Carbon. Can that be? So, for Cocoa it seems to be different?!
No, it was never necessary for Carbon. Someone may have suggested it to get faster code, but as you found it out, it can also result in unlinkable code.

LazProgger

  • Jr. Member
  • **
  • Posts: 91
No, it was never necessary for Carbon. Someone may have suggested it to get faster code, but as you found it out, it can also result in unlinkable code.

Strange, I must have read it somewhere, otherwise I would have never come to the idea to add that option.

Just for knowledge: Is there a reason beyond getting faster code to use that option at all?

At least this thread can be found by other people now having the same problem.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 674
Just for knowledge: Is there a reason beyond getting faster code to use that option at all?
No. It also makes it impossible to put the generated code in a (dynamic) library.

LazProgger

  • Jr. Member
  • **
  • Posts: 91
No. It also makes it impossible to put the generated code in a (dynamic) library.

Okay. Thanks for clarification. I will remove that from all of my projects.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2290
    • havefunsoft.com
If i remember correctly Apple requires ALL applications to be PIC (or PIE Position Independent Executable) to be publishable at App Store: https://developer.apple.com/library/archive/qa/qa1788/_index.html
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

LazProgger

  • Jr. Member
  • **
  • Posts: 91
https://developer.apple.com/library/archive/qa/qa1788/_index.html

I have tested an application file, once created with the -Cg- option and once without with the tool mentioned in the link:

$ otool -hv /path/to/MyApp.app/MyApp

And both programs don't have the mentioned PIE flag.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2290
    • havefunsoft.com
maybe it's iOS (arm) requirement.
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 674
Position-independent code (PIC) is a requirement for creating a position-independent executable (PIE), but the linker only creates a PIE executable by default if you target Mac OS X 10.7 or later (use the command line option -WM10.7 or higher; by default, FPC targets Mac OS X 10.5 for x86-64).