View Issue Details

IDProjectCategoryView StatusLast Update
0036653FPCCompilerpublic2020-03-29 16:53
ReporterAdriaan van Os Assigned ToJonas Maebe  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.3.1 
Fixed in Version3.3.1 
Summary0036653: Linker complains about weaklinked vm_kernel_page_size symbol on darwin x86_64 when building android crosscompiler
Descriptionrtl/darwin/sysmach.inc has

    vm_kernel_page_size: vm_size_t; cvar; weakexternal; //__OSX_AVAILABLE_STARTING(__MAC_10_9, __IPHONE_7_0)

so vm_kernel_page_siz is marked weakexternal. I still get an error

    Undefined symbols for architecture x86_64:
      "_vm_kernel_page_size", referenced from:
          _SYSTEM_$$_DARWIN_INIT_PAGE_SIZE in system.o

when building a cross-compiler for Android on OSX 10.8.5, using fpc-3.0.4 and the command

    make clean crossall crossinstall OS_TARGET=android CPU_TARGET=arm INSTALL_PREFIX=/usr/local BINUTILSPREFIX=arm-linux-androideabi-

The build error disappears when I comment out the reference to vm_kernel_page_size in darwin_init_page_size

 procedure darwin_init_page_size;
    begin
{
      if (@vm_kernel_page_size<>nil) and (vm_kernel_page_size>vm_page_size) then
        darwin_page_size:=vm_kernel_page_size
      else
}
        darwin_page_size:=vm_page_size;
    end;

Is this a bug ? Caused by @vm_kernel_page_size ?
TagsNo tags attached.
Fixed in Revision44396
FPCOldBugId
FPCTarget-
Attached Files

Activities

Jonas Maebe

2020-02-03 22:13

manager   ~0120864

That is inherent to how (weak) linking works on Darwin: at link time, the symbol must exist somewhere (even if only in a stub library). The reason is that on Darwin, the linker records in the binary from which library a symbol gets imported (so-called two-level namespaces).

At run time, the symbol does not have to exist if it was declared as "weak" (its address will be nil if it doesn't exist).

I guess I can add an ifdef that you can use to exclude that variable's use. When you use it, it will mean the compiled code may not work optimally when used on newer macOS versions though.

Adriaan van Os

2020-02-03 23:36

developer   ~0120867

If darwin has this strange weak-linking requirement, then the better solution is to load symbols, that may not be available, at run-time dynamically.

Adriaan van Os

2020-02-03 23:37

developer   ~0120868

I can look into that.

Jonas Maebe

2020-02-04 08:30

manager   ~0120871

As mentioned, it's not strange in the context of two-level namespaces (which prevents symbol name collisions when linking your program against a new library). It's the only way it can work if you record which library each symbol comes from.

The issue with dlsym is that you either let the run time linker pick any library that contains the symbol (thereby negating the whole advantage of two-level namespaces), or you must manually specify in which library it should search the symbol (which can be an issue, as Apple occasionally moves symbols to different libraries -- they do this in a versioned way, so that applications linked against the old version of the library keep working, but it can cause issues if you look it up at run time).

This is also why in Xcode, Apple only supports linking against the latest macOS SDK since quite a while, even though you can perfectly target older (Mac) OS X/macOS versions while doing so. Of course, that indeed does not help when you are compiling on an older system.

Adriaan van Os

2020-02-04 09:45

developer   ~0120876

What Apple does, is just marketing politics, it has nothing to do with technology a such. They just want to manipulate users and developers into using the latest "technology" fashion. Solving this problem now, with the theoretical risk that the symbol will move to another library, which can be fixed with an update, is better than doing nothing, not solving the problem, because that is the "politically correct" way of serving a fashion shop in Cupertino that keeps changing things for marketing reasons.

Jonas Maebe

2020-02-04 20:20

manager   ~0120888

I'm fairly sure both the weak symbols and two-level namespaces have worked like that since the NeXTStep days.

Jonas Maebe

2020-02-22 16:52

manager   ~0121193

You can around it with -k-U -k_vm_kernel_page_size. That will also cause the symbol to be looked up dynamically in all loaded libraries if it cannot be found at (static) link time, without the need for using dlsym. It has the same downsides as dlsym though.

Sven Barth

2020-03-03 23:01

manager   ~0121343

This fails on powerpc-darwin as well. In my case when building the native 3.3.1 compiler...

Issue History

Date Modified Username Field Change
2020-02-03 17:07 Adriaan van Os New Issue
2020-02-03 17:10 Adriaan van Os Summary Linker complains about weaklinked vm_kernel_page_size symbol on darwin x86_64 when building aarch android crosscompiler => Linker complains about weaklinked vm_kernel_page_size symbol on darwin x86_64 when building android crosscompiler
2020-02-03 17:10 Adriaan van Os FPCTarget => -
2020-02-03 22:13 Jonas Maebe Note Added: 0120864
2020-02-03 23:36 Adriaan van Os Note Added: 0120867
2020-02-03 23:37 Adriaan van Os Note Added: 0120868
2020-02-04 08:30 Jonas Maebe Note Added: 0120871
2020-02-04 09:45 Adriaan van Os Note Added: 0120876
2020-02-04 20:20 Jonas Maebe Note Added: 0120888
2020-02-22 16:52 Jonas Maebe Note Added: 0121193
2020-03-03 23:01 Sven Barth Note Added: 0121343
2020-03-29 16:53 Jonas Maebe Assigned To => Jonas Maebe
2020-03-29 16:53 Jonas Maebe Status new => resolved
2020-03-29 16:53 Jonas Maebe Resolution open => fixed
2020-03-29 16:53 Jonas Maebe Fixed in Version => 3.3.1
2020-03-29 16:53 Jonas Maebe Fixed in Revision => 44396