Open Quuxplusone opened 4 years ago
Do you have any more specific information about how it fails submission?
In general, though, I'm not sure this is an appropriate bug for LLVM as an open-source project; seems more like something that should be reported directly to Apple.
> Do you have any more specific information about how it fails submission?
Well, the Apple submission process is pretty blackbox, so you just get general
messages. When you directly submit, you just get back a:
ITMS-90562: Invalid Bundle - The app cannot be processed because options not
allowed to be embedded in bitcode are detected in the submission. It is likely
that you are not building the app with the toolchain provided in Xcode.
And if you try to locally distribute a developer build, you get a "Error (60),
couldn't rebuild from bitcode."
Not super helpful, other than pinpointing the bitcode. We can ship fine for
iOS, since we aren't required to submit with bitcode and then everything works.
But for tvOS, bitcode is required, and so you get the failures.
(In reply to John McCall from comment #2)
> In general, though, I'm not sure this is an appropriate bug for LLVM as an
> open-source project; seems more like something that should be reported
> directly to Apple.
Yeah, for sure. Apple obviously just said use Xcode, so I thought I'd try
here. I think the only chance of it working long-term is if LLVM wants it to,
but yeah, I totally understand this not being a priority. I just hoped, since
Apple is posting patches back, that it all ends up being the same thing
eventually.
Thanks!
There really isn't any way for LLVM to maintain compatibility here. I'm not sure if this is an intentional incompatibility or not; if it is, it's futile to try to subvert it upstream, and if it isn't, Apple should just fix the bug.
If you do report this to Apple, please include the command line that produced the rejected bitcode. It's possible that there's some specific flag that's against policy.
(In reply to John McCall from comment #4)
> If you do report this to Apple, please include the command line that
> produced the rejected bitcode. It's possible that there's some specific
> flag that's against policy.
Oh, I apparently skimmed over the point where you mentioned that you'd
already reported this. I can ask people internally whether this is
intentional if you give me a command line.
(In reply to John McCall from comment #5)
>
> Oh, I apparently skimmed over the point where you mentioned that you'd
> already reported this. I can ask people internally whether this is
> intentional if you give me a command line.
Here you go:
c:/devel/libs/AppleOnWin/osx-toolchain/bin/clang.exe -arch arm64 -c -pipe -
fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer -fno-vectorize -
fno-unroll-loops -fembed-bitcode -Wall -mtvos-version-min=10.2 -O2 -isysroot
c:/devel/libs\AppleOnWin\appletvos --target=arm-apple-tvos10 radfft.cpp -o
radfft.o
(In reply to Jeff Roberts from comment #6)
> (In reply to John McCall from comment #5)
> >
> > Oh, I apparently skimmed over the point where you mentioned that you'd
> > already reported this. I can ask people internally whether this is
> > intentional if you give me a command line.
>
> Here you go:
>
> c:/devel/libs/AppleOnWin/osx-toolchain/bin/clang.exe -arch arm64 -c -pipe
> -fvisibility=hidden -fno-strict-aliasing -fno-omit-frame-pointer
> -fno-vectorize -fno-unroll-loops -fembed-bitcode -Wall
> -mtvos-version-min=10.2 -O2 -isysroot c:/devel/libs\AppleOnWin\appletvos
> --target=arm-apple-tvos10 radfft.cpp -o radfft.o
Oh, and it doesn't seem to be complaining about the command line itself - I can
hexedit that down to nothing, and get the same warnings...
Right now, the bitcode out of clang/LLVM isn't compatible with Apple's bitcode.
That is, if you build a ios or tvos app containing LLVM bitcode, it will fail submission.
I'm wondering if there is any effort to make these compatible. It looks like most of the bitcode stuff is being submitted by Apple, so it seems like they want to get all this integrated into one codebase.