[cfe-dev] linking with libclang for ios

Anton Smirnov dev at antonsmirnov.name
Mon Jul 7 02:28:20 PDT 2014


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/20140707/7f3c2367/attachment.html>


More information about the cfe-dev mailing list