No, you're right. We're “leaking” symbols that have no use outside of our library. We're fixing this and should have a release out either today or tomorrow.
This is a strange question, so I apologize if it doesn't make sense.
Our app is a plugin to a host application. On macOS, we make use of libTurboFloat.dylib. The manufacturer of the host application noted that their latest build makes use of the boost library. Some of their users are experiencing hard crashes and the host app manufacturer believes that the reason is libTurboFloat.dylib is “exporting boost symbols”. They suggested that we verify this by using `nm -gU libTurboFloat.dylib` and sure enough, the boost symbols are listed. See below for just some symbols that are listed when running this command.
They have suggested that we can “hide these symbols from the .bundle that is built from our codebase". Do you have any guidance or tips for this?
Thanks,
Arie
Here are the symbols that are listed:
0000000000083f10 D __ZGVN5boost4asio6detail10call_stackINS1_14strand_service11strand_implEhE4top_E
0000000000083ef0 D __ZGVN5boost4asio6detail10call_stackINS1_15task_io_serviceENS1_27task_io_service_thread_infoEE4top_E
0000000000084698 D __ZGVN5boost4asio6detail12service_baseINS0_21stream_socket_serviceINS0_2ip3tcpEEEE2idE
0000000000084690 D __ZGVN5boost4asio6detail12service_baseINS0_2ip16resolver_serviceINS3_3tcpEEEE2idE
0000000000083ef8 D __ZGVN5boost4asio6detail12service_baseINS1_14kqueue_reactorEE2idE
0000000000083f18 D __ZGVN5boost4asio6detail12service_baseINS1_14strand_serviceEE2idE
0000000000083f00 D __ZGVN5boost4asio6detail12service_baseINS1_15task_io_serviceEE2idE
0000000000084060 D __ZGVZN5boost4asio5error17get_misc_categoryEvE8instance
0000000000083f90 D __ZGVZN5boost4asio5error18get_netdb_categoryEvE8instance
0000000000083ff0 D __ZGVZN5boost4asio5error21get_addrinfo_categoryEvE8instance
000000000004edc0 T __ZN5boost11this_thread18interruption_pointEv
000000000004f090 T __ZN5boost11this_thread20disable_interruptionC1Ev
000000000004f040 T __ZN5boost11this_thread20disable_interruptionC2Ev
000000000004f110 T __ZN5boost11this_thread20disable_interruptionD1Ev
000000000004f0e0 T __ZN5boost11this_thread20disable_interruptionD2Ev
000000000004ef00 T __ZN5boost11this_thread20interruption_enabledEv
No, you're right. We're “leaking” symbols that have no use outside of our library. We're fixing this and should have a release out either today or tomorrow.
Awesome, thanks for the quick reply and for understanding. Can you notify here when it's ready? I'll integrate it into our build.
Thanks Wyatt!!