After rebuilding a lot of port libs until I obtained the LC_VERSION_MIN_MACOSX, I ran into this new Apple rejection reason:
Guideline 2.5.1 - Performance Your app links against the following non-public framework(s): • Contents/Frameworks/libcrypto.1.1.dylib/___sprintf_chk • Contents/Frameworks/libp11-kit.0.dylib/___sprintf_chk • Contents/Frameworks/libmpfr.6.dylib/___sprintf_chk • Contents/Frameworks/libgnutls.30.dylib/___sprintf_chk • Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strdup • Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strlen • Contents/Frameworks/libidn2.0.dylib/_sprintf • Contents/Frameworks/libx264.157.dylib/___sprintf_chk • Contents/Frameworks/libssl.1.1.dylib/___sprintf_chk • Contents/Frameworks/libxml2.2.dylib/___sprintf_chk Next Steps The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. Is it possible to rebuild those libs without those symbols? I found this link which may be relevant (I am not a C developer) https://stackoverflow.com/questions/12201625/disable-using-sprintf-chk#12203365 <https://stackoverflow.com/questions/12201625/disable-using-sprintf-chk#12203365> Regards, Adrian > On 2 Mar 2021, at 07:14, Ryan Schmidt <[email protected]> wrote: > > On Mar 1, 2021, at 17:16, Adrian Georgescu wrote: > >> I am just a new user so bear with me. >> >> It seems that now Apple rejects any library part of a notarised application >> (and Mac App Store) if it does not comply with certain rules. >> >> One of this rules is that each binary or library must indicate the minimum >> OS version is suppose to run on. >> >> This can be checked with otool like in this example: >> >> otool -l libvpx.dylib |grep -A 2 -B 3 LC_VERSION_MIN_MACOSX >> cmdsize 24 >> uuid 1EDC0CF1-9D58-30B4-AF67-A0DEEAF3BAF4 >> Load command 8 >> cmd LC_VERSION_MIN_MACOSX >> cmdsize 16 >> version 10.11 >> >> If your app depends on 3rd party libs you can install them using Mac Ports. >> But the default built binaries do not always work. >> >> The only way to obtain this flag set while using port is to install from >> source using -s parameter >> >> But for some libraries even this is not enough (libvpx and libsdl are some >> examples I ran into). >> >> The option for generating this flag is at linking stage and the option for >> creating this flag must be passed to the linker for this and this is not >> always possible by just using port install -s command. >> >> For example installing libvpx library (and many others) was not possible >> using -s because the library was not ready to use this flag. >> >> I have to edit the Makefiles and pass this flag to the linking stage: >> >> -mmacosx-version-min=10.11 >> >> 10.11 or whatever minimum version the lib or app is suppose to run on. >> >> May I suggest that this must be documented somehow in the port recipes. > > I am not aware of Apple's increasingly inconvenient requirements in this > regard. > > MacPorts adopted the strategy of setting the MACOSX_DEPLOYMENT_TARGET > environment variable in all phases. It was our understanding that this was > equivalent to setting -mmacosx-version-min, therefore we make no effort to > set -mmacosx-version-min and have not had any qualms in removing conflicting > -mmacosx-version-min directives when we encounter them. > > If this is not longer satisfactory to Apple, then we will need to change how > MacPorts works and fix all ports (a huge undertaking, of course).
