search for: setlastmodificationandaccesstime

Hi, I've been trying to get LLVM working as a JIT compiler on Android for a while. It works now, except that the setLastModificationAndAccessTime function won't build because the Bionic C library lacks both futimes and futimens. There doesn't appear to be any "nice" workaround for this problem: the only ways I can think of to make setLastModificationAndAccessTime work are either to go by /proc/self/fd or invoke the sys...

...us to remove our ugly workaround for not having this functionality. Steve On Mon, Nov 25, 2013 at 8:30 AM, James Lyon <jameslyon0 at gmail.com> wrote: > Hi, > > I've been trying to get LLVM working as a JIT compiler on Android for a > while. It works now, except that the setLastModificationAndAccessTime > function won't build because the Bionic C library lacks both futimes and > futimens. There doesn't appear to be any "nice" workaround for this > problem: the only ways I can think of to make > setLastModificationAndAccessTime work are either to go by /proc/self/fd or...

...gt; > On Mon, Nov 25, 2013 at 8:30 AM, James Lyon <jameslyon0 at gmail.com > <mailto:jameslyon0 at gmail.com>> wrote: > > Hi, > > I've been trying to get LLVM working as a JIT compiler on Android > for a while. It works now, except that the > setLastModificationAndAccessTime function won't build because the > Bionic C library lacks both futimes and futimens. There doesn't > appear to be any "nice" workaround for this problem: the only ways > I can think of to make setLastModificationAndAccessTime work are > either to go by...

...13 at 8:30 AM, James Lyon <jameslyon0 at gmail.com<mailto: >> jameslyon0 at gmail.com>> wrote: >> >> Hi, >> >> I've been trying to get LLVM working as a JIT compiler on Android >> for a while. It works now, except that the >> setLastModificationAndAccessTime function won't build because the >> Bionic C library lacks both futimes and futimens. There doesn't >> appear to be any "nice" workaround for this problem: the only ways >> I can think of to make setLastModificationAndAccessTime work are >>...

...:jameslyon0 at gmail.com <mailto:jameslyon0 at gmail.com>>> > wrote: > > Hi, > > I've been trying to get LLVM working as a JIT compiler on > Android > for a while. It works now, except that the > setLastModificationAndAccessTime function won't build > because the > Bionic C library lacks both futimes and futimens. There > doesn't > appear to be any "nice" workaround for this problem: the > only ways > I can think of to make setL...

...t;jameslyon0 at gmail.com<mailto: >>> jameslyon0 at gmail.com>> wrote: >>> >>> Hi, >>> >>> I've been trying to get LLVM working as a JIT compiler on Android >>> for a while. It works now, except that the >>> setLastModificationAndAccessTime function won't build because the >>> Bionic C library lacks both futimes and futimens. There doesn't >>> appear to be any "nice" workaround for this problem: the only ways >>> I can think of to make setLastModificationAndAccessTime work are &...

...e missing on Android, they're defined in libgcc.a, the problem is that they don't get linked in unless they're referenced. I don't know how this problem is avoided on ARM/Linux/glibc normally, but something pulls them in there according to my testing. The way to avoid disabling setLastModificationAndAccessTime is to rewrite it to take a path and use utime/utimes instead (incidentally the setLastModificationAndAccessTime function is only used by llvm-ar). I don't know why it was written the way it is now; i.e. I'm not sure what systems have futimens but not futimes and vice-verse. I would gues...

...hack. > Hi James, I may be wrong, but I remember LLVM treating "androideabi" as "aeabi", which is wrong. This may be the source of your problem, and I think we should teach Clang/LLVM to understand the Android ABI in its full form. There's one other minor change since setLastModificationAndAccessTime can't > be supported on Android; all relevant system calls are missing from the C > library. I've therefore changed the code to fail at runtime rather than > compile-time here. This sounds worse... I'd rather we fixed the behaviour than the cause... cheers, --renato --------...

...in RTDyldMemoryManager.cpp which did the same thing for fewer functions. They should now be picked up through the sys::DynamicLibrary::AddSymbol mechanism in both cases. The symbols required for ARM/Android are then added by an identical hack just below. There's one other minor change since setLastModificationAndAccessTime can't be supported on Android; all relevant system calls are missing from the C library. I've therefore changed the code to fail at runtime rather than compile-time here. James -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-android.patch Type: t...

...RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The second patch modifies the setLastModificationAndAccessTime function to use utime (so it takes a filename) rather than just refusing to compile if futimes and futimens are not available, due to Renato's suggestion. I don't know whether this has external users, but the function didn&...

...anager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. >> >> I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The second patch modifies the setLastModificationAndAccessTime function to use utime (so it takes a filename) rather than just refusing to compile if futimes and futimens are not available, due to Renato's suggestion. I don't know whether this has external users, but the function didn'...

...dMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. > > I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The second patch modifies the setLastModificationAndAccessTime function to use utime (so it takes a filename) rather than just refusing to compile if futimes and futimens are not available, due to Renato's suggestion. I don't know whether this has external users, but the function didn'...

...the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The second patch modifies the setLastModificationAndAccessTime function to use utime (so it takes a filename) rather than just refusing to compile if futimes and futimens are not available, due to Renato's suggestion. I don't know whether this has external users, but the function didn'...

...dMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. > > I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The second patch modifies the setLastModificationAndAccessTime function to use utime (so it takes a filename) rather than just refusing to compile if futimes and futimens are not available, due to Renato's suggestion. I don't know whether this has external users, but the function didn'...

...anager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. >> >> I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The second patch modifies the setLastModificationAndAccessTime function to use utime (so it takes a filename) rather than just refusing to compile if futimes and futimens are not available, due to Renato's suggestion. I don't know whether this has external users, but the function didn'...

...yldMemoryManager.cpp which did the same thing for fewer functions. They should now be picked up through the sys::DynamicLibrary::AddSymbol mechanism in both cases. The symbols required for ARM/Android are then added by an identical hack just below. > > There's one other minor change since setLastModificationAndAccessTime can't be supported on Android; all relevant system calls are missing from the C library. I've therefore changed the code to fail at runtime rather than compile-time here. > > James

...yldMemoryManager.cpp which did the same thing for fewer functions. They should now be picked up through the sys::DynamicLibrary::AddSymbol mechanism in both cases. The symbols required for ARM/Android are then added by an identical hack just below. > > There's one other minor change since setLastModificationAndAccessTime can't be supported on Android; all relevant system calls are missing from the C library. I've therefore changed the code to fail at runtime rather than compile-time here. > > James

...de in RTDyldMemoryManager.cpp which did the same thing for fewer functions. They should now be picked up through the sys::DynamicLibrary::AddSymbol mechanism in both cases. The symbols required for ARM/Android are then added by an identical hack just below. There's one other minor change since setLastModificationAndAccessTime can't be supported on Android; all relevant system calls are missing from the C library. I've therefore changed the code to fail at runtime rather than compile-time here. James

On Jun 24, 2013, at 4:18 PM, Stefan Teleman <stefan.teleman at gmail.com> wrote: > I'll file the bug about the endian stuff, but we'll also have to have > an <endian.h> in Solaris as well. Do you still have issues after r182419? commit 01ef4f6982451e6a7c00a713d9ae677d3a15d042 Author: Jakob Stoklund Olesen <stoklund at 2pi.dk> Date: Tue May 21 13:36:13 2013

On Mon, Jun 24, 2013 at 6:17 PM, Jorge Rodrigues <skeept at gmail.com> wrote: > Norm, > > thanks for the help. Applying the fix solves the issue I mentioned but now I > have more issues. > > I can install clang, but when running I cannot compile and link files. > If I compile with -c flag it works but compiling the following x.c file > gives an error: >