Bazel: Basic CROSSTOOL targeting iOS

[kchodorow]

Doesn't have to be fancy.

[c-parsons]

With damien's recent work on cc_configure.bzl, we create a local-system-relevant CROSSTOOL file, which is certainly a good place to start for creating a more complex system-wide crosstool. It's currently created at ${BAZEL_EXECUTION_ROOT}/external/local_config_cc/CROSSTOOL

This is designed to "just work" for most simple usecases. Is this sufficient?

[c-parsons]

One reason this doesn't work appropriately is that it doesn't support target various common platform types (such as as ios). We should consider either extending cc_configure or providing some sort of common crosstool

[AlexTalks]

@c-parsons agreed, I'm not sure what default configurations would make sense but the generated CROSSTOOL in bazel-bazel/tools/cpp/ (along with the associated BUILD file) provided a good starting point.

[damienmg]

If you encounter problem when trying to build OS X app, can you expand on that bug on the exact problems. We should be able to extends the C++ configuration to just work.

[ulfjack]

I'm not sure there are any open action items here. If you have any specific issues, feel free to file separate bug reports / feature requests.

[c-parsons]

I believe this was mislabeled, based on conversations which spawned this issue.
The request was for a crosstool on OSX host for targeting iOS. The crosstool generated on OSX bazel doesn't generate any ios toolchains, nor make it clear how to create such targets.

One thing to note is that such toolchains must follow implicit naming structure currently. e.g. if you want ot target iOS i386 architecture, you need to have the target named ios_i386....

[ghost]

Any traction on this? Current iOS support is pretty busted without iOS crosstool, and there's a catch 22 -- no one uses it because it's busted, so no one will fix it because they're not using it. For my needs it'd be pretty awesome to be able to build at least frameworks (with a rather large transitive closure of C++ deps) that I could then include into an XCode project that contains just the UI bits, which are by definition not cross platform.

[c-parsons]

I'll be working on this this quarter. I should at the very least have something rudimentary later this month.

[ghost]

FWIW, I'm trying to create my own CROSSTOOL that points to iOS toolchain at the moment. It's not generated, but for my needs it doesn't have to be. I'm using the existing OSX darwin crosstool as a template. My uber-goal is to be able to use several C++ dependencies in iOS transparently, the most important of which is Protocol Buffers. If you'd like, I could share the resulting CROSSTOOL in a gist once I get it working.

[c-parsons]

Sure, I would definitely be interested in seeing what you come up with. I'll try to keep this bug up to date with my progress, as well.
Thanks, and good luck!

[ghost]

At this point it seems to compile stuff, but linker barfs on ld: symbol(s) not found for architecture arm64. I'm probably forgetting a flag somewhere. The *.o files are there, and objdump -disassemble does show aarch64 assembly, so technically _compile_ already works.

[ghost]

Me again (under my personal account).

OK, I got things to build and link. The culprit was

linker_flag: "-undefined" 
linker_flag: "dynamic_lookup"

Which I removed earlier because linker is complaining that this is deprecated for iOS. It does still complain about that, and the resulting library seems suspiciously small, but it doesn't fail. I'll try to link it into an actual iOS app in XCode to test later today.

Is there a workaround for the deprecated flag? I figure one way this could be addressed is by passing in the paths of all the object files that need to be linked. That seems to be what XCode is doing it. But I'm not sure how one would go about doing that in a CROSSTOOL file, assuming it's even possible at all.

[ghost]

Doesn't work. Both *.a and *.so seem to only contain the symbols defined in the source of their immediate target. My understanding is, *.so should link everything but libc++ statically. That does not seem to be happening.

Additionally -fembed-bitcode is incompatible with -undefined dynamic_lookup, and without the latter, linker barfs on not finding the sub-modules to link. Not sure how this can be addressed.

[ghost]

Here's the gist: https://gist.github.com/variac/58c124429615c98019de65f789638d3b

[ghost]

Also, *.so built with a cc_library target contains the absolute path to where it was during build, which prevents its successful dynamic loading at runtime.

otool -L libtest.so
libtest.so:
    bazel-out/local-opt/bin/lib/libtest.so (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

[robbiexperiel]

Has there been any progress on this? I'm currently trying to build an ios_application with cc_library dependencies, and the cc_libraries get compiled to the host architecture even though I pass in --ios_cpu=arm64. I think it's the same bug as this, and from what I understand, building the cc_libraries using a CROSSTOOL for ios would fix the issue.

[c-parsons]

This is in progress; I've had to delay this work for other priorities, but I plan to be actively working on this later this week.

[jgavris]

Hi @c-parsons, could you give an update on where this issue stands with regards to prioritization? I echo @dmitryb-ai2's comments...this is a bit of a catch-22 until we have something to play with.

[c-parsons]

I'm actively working on getting this committed now -- there were some difficult-to-diagnose test failures as a result of the change. I would be surprised if this is not committed by end of week. (Though hopefully today's the day!)

[jgavris]

👋 Hi again @c-parsons, could we get an update here?

[kchodorow]

@c-parsons is out today, but I think this was committed in https://github.com/bazelbuild/bazel/commit/cc21998c299b4d1f97df37b961552ff8168da17f.

[jgavris]

Cool, I saw that. When would this issue be ready to close?

[kchodorow]

I'll leave that question for Chris.

[c-parsons]

As kchodorow has indicated, this has been committed and therefore I'll close this issue.

[robbiexperiel]

Hey, @c-parsons, is there anything special I need to do to get cc_libraries working as dependencies of objc_libraries? I just tried building my ios_application with bazel master and rules_apple master, and am still getting linking errors complaining about the wrong architecture:

ld: warning: ignoring file bazel-out/ios-arm64-min8.0-applebin_ios-darwin_x86_64-fastbuild/bin/path/to/file.a, file was built for archive which is not the architecture being linked (arm64)

According to "lipo -info", the .a file was compiled to x86_64. Are there special flags I need to set, or do the CROSSTOOL changes not actually allow objc_lib -> cc_lib dependencies?

EDIT: After looking at the tests, it seems like "--experimental_enable_objc_cc_deps --experimental_objc_crosstool=all --apple_crosstool_transition" should do it. I'll give that a shot.

[c-parsons]

Indeed, I believe you need --apple_crosstool_transition for this to work properly.
You can feel free to put this in your own bazelrc.
We're in the process of making this on by default (but we still have to migrate some users...)