On Sep 12, 2012, at 1:59 PM, ext [email protected] <[email protected]> wrote:
> > On Sep 12, 2012, at 12:42 PM, ext Thiago Macieira <[email protected]> > wrote: >> >> The incompatibilities are manageable, for sure. Can you check if >> /usr/library/libicucore.dylib contains versioned C symbols? For example, >> here >> they are versioned: >> >> $ nm -D /lib64/libicuuc.so | grep ucnv_close >> 00000035de655740 T ucnv_close_48 > > nm /usr/lib/libicucore.dylib | grep ucnv_close > 000000000005849e T _ucnv_close > > (no "-D" on OS X nm) > >> Whether we can rely on it always being there, that's something you need to >> tell me. But in any case, we can always say that future OSX versions aren't >> supported until we get our hands on them and test. > > I wish I had that kind of inside information :) As noted in the blog I > pointed to the headers are not present, which makes me a little bit worried. > Apple has a history of making incompatible changes to system libraries like > libicu, which is why macports duplicates everything for example. > > I think we should go a little bit beyond "future versions are not supported" > though, and actually make an effort to make sure our binaries keep running. Ideally yes, but there's always limits to how far this can go. We also don't know how Apple might change it's app store policies in the future or other things. So some effort is ok, but I think it's more important to simply follow up on what's happening and provide updated Qt packages in case there's a need. Cheers, Lars _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
