View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0036653||FPC||Compiler||public||2020-02-03 17:07||2020-03-29 16:53|
|Reporter||Adriaan van Os||Assigned To||Jonas Maebe|
|Fixed in Version||3.3.1|
|Summary||0036653: Linker complains about weaklinked vm_kernel_page_size symbol on darwin x86_64 when building android crosscompiler|
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
if (@vm_kernel_page_size<>nil) and (vm_kernel_page_size>vm_page_size) then
Is this a bug ? Caused by @vm_kernel_page_size ?
|Tags||No tags attached.|
|Fixed in Revision||44396|
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.
||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.|
||I can look into that.|
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.
||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.|
||I'm fairly sure both the weak symbols and two-level namespaces have worked like that since the NeXTStep days.|
||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.|
||This fails on powerpc-darwin as well. In my case when building the native 3.3.1 compiler...|
|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|