Andreas,
that is actually not your problem - the stubs are generated in glib, so your
package can do nothing about it, your compile flags won't change it. The only
way to fix it is on my end, the proper way is to upgrade to Xcode 14 for the
package builds, but that requires some changes to the build machine, so I'll do
it on Monday when I'm at work, so hold on tight in the meantime.
Cheers,
Simon
Explanation of the issue for posterity: the issue is caused by Xcode 14 which
generates those stubs[1], but can also handle them. However, older Xcode
versions cannot. We are using macOS 11 target and SDK to ensure compatibility
with older macOS versions, but apparently Xcode 14 assumes that the linking
will still happen with Xcode 14 even if libraries are compiled for older
targets. Therefore the proper fix is to make sure that packages are also linked
with Xcode 14. Another work-around would be to compile glib with
-fno-objc-msgsend-selector-stubs so it would also work with older Xcode, but
it's more future-proof to just upgrade Xcode.
[1] https://github.com/llvm/llvm-project/issues/56034
> On Jun 17, 2023, at 7:07 PM, Andreas Blätte
> wrote:
>
> Dear colleagues,
>
>
>
> after submitting a release of my package RcppCWB (no problems with test
> servers), CRAN check results reported ERRORS on the macOS check systems:
> https://cran.r-project.org/web/checks/check_results_RcppCWB.html
>
>
>
> The core is that when test loading the package, you get the error: Symbol not
> found: _objc_msgSend$UTF8String
>
>
>
> Picking up a solution discussed here (disable objc_msgSend stubs in clang), I
> modified the configure script of my package to pass the flag
> “-fno-objc-msgsend-selector-stubs“ to the linker, which I thought would solve
> the problem.
>
>
>
> However: The CRAN Debian system for incoming R packages uses clang 15, which
> does not accept this flag any more, resulting in an error.
>
>
>
> Certainly, I could refine my configure script to address a very specific
> scenario on CRAN macOS systems, i.e. making usage of the flag conditional on
> a specific clang version. But I am not sure whether this is the way to go. It
> would feel like a hack I would like to avoid.
>
>
>
> Has anybody encountered this error? Is there a best practice or a recomended
> solution? I would be very glad to get your advice!
>
>
>
> Kind regards
>
> Andreas
>
>
>
> --
>
> Prof. Dr. Andreas Blaette
>
> Professor of Public Policy
>
> University of Duisburg-Essen
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
