Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.