On Mar 2, 2021, at 15:10, Andrew Udvare wrote: > This is not related to MacPorts really. I would strongly not suggest > attempting to pull in MacPorts-built libs into your app you plan to > distribute. MacPorts libs can really only be trusted to work with MacPorts > packages that use them. > > You either have to build the libs yourself or use something like Carthage. >
> The reason you get this issue is because those dylibs from MacPorts contain > definitions of sprintf_chk which is a private symbol to Apple (already > defined in their own lib or possibly just because it starts with __). > Clang/GCC usually generates this code when you use sprintf as part of source > fortification (-D_FORTIFY_SOURCE). You have to build those libs without such > features. You can try -D_FORTIFY_SOURCE=0 and every library you want to use > must be built with this. Carthage packages probably have this fixed. Although it's not the primary purpose of MacPorts, it's within scope to expect MacPorts libs to be reusable in other projects. We already do a couple things to that end, such as setting MACOSX_DEPLOYMENT_TARGET to the build OS version and linking with -headerpad_max_install_names so that libraries can be relocated using install_name_tool or dylib_bundler. So if there are some easy changes we can make in MacPorts generally or in a small number of ports specifically to make them more useful for this purpose, that's reasonable to do. However if it requires us to disable source fortification we may not want to do that since I thought fortification was a good thing, designed to make programs safer. But using Carthage or CocoaPods instead of MacPorts when your goal is to get libraries to redistribute with your project is also a reasonable approach. Whichever approach you use, make sure the combination of licenses of the libraries and your program allow redistribution.
