> Env.Host.sh ends up with > CPUNAME of ARM when I think it ought to be intel.
Well, CPUNAME or CPU aren't used for any deep magic, they are just strings used to form some directory names etc. I don't think we would win much by using a separate CPU and CPUNAME string for the iOS simulator. The only place I can think of where the architecture really matters, i.e. inline assembly code is used etc, is in bridges, and there we can then use #ifdef __arm__ . But yeah, I admit this is something I am not totally sure of. Still, I think we can continue as now, pretending that the iOS simulator also is "ARM", until something definitely shows that it causes lots of complications. > The problem is that main.c > and a couple of other C files #include the objective-C headers. I don't > find a main.m or command line option to force the file to be compiled as > Objective-C so I'm wondering how this is intended to work. Which main.c in particular? We do have a couple of files with the .cxx extension that actually are Objective-C++ for iOS in vcl (and for Mac OS X we have many ), and there are makefile tweaks in place to make that work. At least it used to work last time I checked... --tml _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
