[cfe-dev] linking with libclang for ios
Anton Smirnov
dev at antonsmirnov.name
Mon Jul 7 23:40:30 PDT 2014
I was said that `stat` is not supported on iOS:
https://devforums.apple.com/message/1000186#1000186
Any suggestion for replacement/walk-around?
2014-07-07 15:28 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
> Hey.
>
> 2014-07-07 14:39 GMT+06:00 Alp Toker <alp at nuanti.com>:
>
>
>> On 07/07/2014 11:14, Anton Smirnov wrote:
>>
>>> Hi, Alp.
>>>
>>> 2014-07-07 12:52 GMT+06:00 Alp Toker <alp at nuanti.com <mailto:
>>> alp at nuanti.com>>:
>>>
>>>
>>>
>>> On 07/07/2014 09:24, Anton Smirnov wrote:
>>>
>>> I've started to edit Mutex.cpp and RWMutex.cpp and found it's
>>> not used at all if "LLVM_ENABLE_THREADS" was off during config.
>>> So it seems that my issues was solved with it.
>>>
>>>
>>> Great
>>>
>>>
>>> Thanks for pointing me right direction ;)
>>>
>>>
>>> Anyway i'm having another issue:
>>>
>>> *2014-07-07 12:19:54.090 LibClangUsage7Demo[64275:60b] started*
>>>
>>>
>>> *Detected an attempt to call a symbol in system libraries that
>>> is not present on the iPhone:*
>>>
>>> *stat$INODE64 called from function
>>> _ZN4llvm3sys2fs6statusERKNS_5TwineERNS1_11file_statusE in
>>> image LibClangUsage7Demo.*
>>>
>>>
>>> Is stat missing in ios simulator? It seems that i will have to
>>> fix such issues one-by-one..
>>>
>>> Is there any ios-friendly version of llvm/clang? Is it ios
>>> simulator limitations (systems calls to absent systems methods)?
>>>
>>>
>>> The LLVM/clang codebase is meant to be portable..
>>>
>>> So, the OS filesystem symbols are available but not implemented on
>>> your platform:
>>>
>>>
>>> What does it mean "available but not implemented"? I'm not sure i
>>> understand it as i have no compile/link errors, runtime errors only.
>>> Does it mean it has required functions declarations in headers while
>>> compiling, symbols while linking but absent for some reason in runtime?
>>> How can that be? i expect to have linker errors if required system calls
>>> are absent.
>>>
>>> I'm using xcode toolchain and sysroot to cross-compile for ios so i
>>> expect it to have valid and actual headers and compiled systems libs.
>>>
>>> What can i do to fix stat missing in llvm::sys::status(..) ? Any flags
>>> or change invocation to any existing system method?
>>>
>>>
>>> That's good news because it means there's a good chance you can
>>> get your application working without porting LLVM's System module.
>>>
>>>
>>> I'm afraid i will discover a lot of places with runtime errors (due to
>>> missing system libs) ;(
>>> Does anybody know any other expected missing/not implemented calls for
>>> ios?
>>>
>>
>> This is a standard iOS platform? Try configuring with
>> -mios-simulator-version-min=7.1
>
>
> Yes, it's standard iOS Platform (iOS Simulator). I've tried 7.0, does it
> make sense?
> I've found few similar issue reports but they relate to 3/4 xcode vrsion
> and pretty ancient ios versions.
>
>
>
>>
>>
>>
>>> As I recall, you wanted to perform an in-memory compilation and
>>> produce LLVM IR, and I suggested using the clang-interpreter demo
>>> as a starting point.
>>>
>>>
>>> At that point i'm just trying to have actual llvm/clang working via
>>> Clang-C API. This means i don't have to have any major modifications, just
>>> cross-compile with right configure params.
>>>
>>> Probably the next step will be look into Cling modifications for
>>> LLVM/Clang and making it working.
>>>
>>
>> Curious, what do you need the modifications for?
>>
>
> Cling requires modified LLVM/Clang and it has it's own LLVM/Clang repos.
> I will start trying your clang-interpreter first which seems to do pretty
> the same.
>
>
>>
>> (Unless it's synced up to LLVM SVN very recently it'll be missing the
>> fixes from this discussion.)
>>
>>
>>
>>
>>> Let's take that a little further..
>>>
>>> You'll need to modify the clang-interpreter sample so it loads C
>>> source code for the main file from memory instead of trying to
>>> read from the filesystem which apparently doesn't existing on your
>>> platform. The code you use shouldn't include any headers or
>>> that'll incur filesystem access.
>>>
>>>
>>> Actually i can access files in ios app sandbox so i expect LLVM/Clang
>>> working for files in it.
>>>
>>
>> Okay, should work fine if you need file access. Try the configure switch
>> I suggested.
>>
>>
>>
>>
>>> Meanwhile I've added non-JIT interpreter support in clang r212083,
>>> and if that still doesn't work you can modify the sample to print
>>> IR to check if things work.
>>>
>>>
>>> Great! How i can i try it? Any example to interpret "hello-world"?
>>>
>>
>> Sure, just run:
>>
>> ./clang-interpreter hello.cpp
>>
>> It mostly accepts the same arguments as normal clang.
>>
>
> Good, i will give it a try.
>
>
>>
>> Alp.
>>
>>
>>> With some luck it won't attempt to read from the filesystem at all
>>> after that, so won't hit the missing OS features.
>>>
>>> If there are more errors, we'll need to refine the approach a
>>> little and eliminate other kinds of file accesses but that should
>>> be the general angle of attack.
>>>
>>> It sounds like a fun project, keep the list posted :-)
>>>
>>>
>>> Well, yes it is. I'm just making proof of concept. Any help is
>>> appreciated.
>>>
>>>
>>> Alp.
>>>
>>>
>>>
>>> Regards, Anton.
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Anton.
>>>
>>>
>>> 2014-07-06 17:16 GMT+06:00 Anton Smirnov
>>> <dev at antonsmirnov.name <mailto:dev at antonsmirnov.name>
>>> <mailto:dev at antonsmirnov.name <mailto:dev at antonsmirnov.name>>>:
>>>
>>>
>>>
>>> I've just tried to rebuild libclang.a
>>> with -miphoneos-version-min=7.0 - no luck.
>>> Also i've removed --enable-optimized --disable-assertions
>>> configure flags and it confirmed error line (Mutex.cpp):
>>>
>>> // Destroy the attributes
>>> errorcode = pthread_mutexattr_destroy(&attr);
>>>
>>> Should setting LLVM_ENABLE_THREADS to "off" help?
>>>
>>>
>>>
>>>
>>> 2014-07-06 12:03 GMT+06:00 Alp Toker <alp at nuanti.com
>>> <mailto:alp at nuanti.com>
>>> <mailto:alp at nuanti.com <mailto:alp at nuanti.com>>>:
>>>
>>>
>>>
>>> Did you try building with LLVM_ENABLE_THREADS off?
>>>
>>> Also consider trying ToT to get the latest fixes.
>>>
>>> Alp.
>>>
>>>
>>>
>>> On 06/07/2014 08:23, Anton Smirnov wrote:
>>>
>>> I've found Mutex.cpp file in llvm sources and it
>>> seems
>>> it's not the first mutex-related call in constructor.
>>> This makes me think it's really absent method in
>>> system libs:
>>>
>>> // Construct a Mutex using pthread calls
>>>
>>> MutexImpl::MutexImpl( bool recursive)
>>>
>>> : data_(0)
>>>
>>> {
>>>
>>> // Declare the pthread_mutex data structures
>>>
>>> pthread_mutex_t* mutex =
>>>
>>> static_cast<pthread_mutex_t*>(
>>> malloc(sizeof(pthread_mutex_t)));
>>>
>>> pthread_mutexattr_t attr;
>>>
>>>
>>> // Initialize the mutex attributes
>>>
>>> int errorcode = pthread_mutexattr_init(&attr);
>>>
>>> assert(errorcode == 0); (void)errorcode;
>>>
>>>
>>> // Initialize the mutex as a recursive mutex, if
>>> requested, or normal
>>>
>>> // otherwise.
>>>
>>> int kind = ( recursive ? PTHREAD_MUTEX_RECURSIVE :
>>> PTHREAD_MUTEX_NORMAL );
>>>
>>> errorcode = pthread_mutexattr_settype(&attr,
>>> kind);
>>>
>>> assert(errorcode == 0);
>>>
>>>
>>> #if !defined(__FreeBSD__) && !defined(__OpenBSD__) &&
>>> !defined(__NetBSD__) && \
>>>
>>> !defined(__DragonFly__) && !defined(__Bitrig__)
>>>
>>> // Make it a process local mutex
>>>
>>> errorcode = pthread_mutexattr_setpshared(&attr,
>>> PTHREAD_PROCESS_PRIVATE);
>>>
>>> assert(errorcode == 0);
>>>
>>> #endif
>>>
>>>
>>> // Initialize the mutex
>>>
>>> errorcode = pthread_mutex_init(mutex, &attr);
>>>
>>> assert(errorcode == 0);
>>>
>>>
>>> // Destroy the attributes
>>>
>>> errorcode = pthread_mutexattr_destroy(&attr); //
>>> fails here
>>>
>>> assert(errorcode == 0);
>>>
>>> // Assign the data member
>>> data_ = mutex;
>>>
>>> }
>>>
>>> I've marked where it fails.
>>> How can that be that previous mutex-related methods
>>> success and this one fails?
>>> What can i do to fix it?
>>>
>>> Regards, Anton.
>>>
>>>
>>> 2014-07-05 19:31 GMT+06:00 Anton Smirnov
>>> <dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name> <mailto:dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name>>
>>> <mailto:dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name>
>>>
>>> <mailto:dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name>>>>:
>>>
>>>
>>> Hi.
>>>
>>> I was able to cross-compile llvm/clang for
>>> i386 and
>>> i'm trying to
>>> use it in my ios app.
>>> Also i was able to add headers and static libs
>>> (both
>>> libLLVM*.a
>>> and libclang*.a) and compile/link the project
>>> with no
>>> errors.
>>>
>>> But when trying to run simple app i'm getting
>>> error:
>>>
>>> *Detected an attempt to call a symbol in system
>>> libraries that is
>>> not present on the iPhone:*
>>>
>>> *pthread_mutexattr_destroy$UNIX2003 called
>>> from function
>>> _ZN4llvm3sys9MutexImplC2Eb in image
>>> LibClangUsageDemo3.*
>>>
>>>
>>>
>>> What can i do in order to fix it?
>>>
>>> Is it llvm/clang issue or i'm doing smth wrong?
>>>
>>> Regards, Anton.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>> <mailto:cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>>
>>>
>>>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>>> -- http://www.nuanti.com
>>> the browser experts
>>>
>>>
>>>
>>>
>>> -- http://www.nuanti.com
>>> the browser experts
>>>
>>>
>>>
>> --
>> http://www.nuanti.com
>> the browser experts
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140708/383cff4e/attachment.html>
More information about the cfe-dev
mailing list