similar to: [LLVMdev] Issue compiling LLVM 2.6 on Windows with MinGW

Reza Sheykhi <hajishey at msu.edu> writes: > I got the following answers: > > which perl > /usr/bin/perl > > which llvm-config > /usr/local/bin/llvm-config > > which llvm-as > /usr/local/bin/llvm-as > > /usr/bin/llvm-confing --version > bash: /usr/bin/llvm-confing: No such file or directory Uh, there is a typo on the command above, it should be

I got the following answers: which perl /usr/bin/perl which llvm-config /usr/local/bin/llvm-config which llvm-as /usr/local/bin/llvm-as /usr/bin/llvm-confing --version bash: /usr/bin/llvm-confing: No such file or directory /usr/local/bin/llvm-config --version 2.8 Quoting Óscar Fuentes <ofv at wanadoo.es>: > Reza Sheykhi <hajishey at msu.edu> writes: > >> Thank you

Hi, I am just letting you know that I have not been able to build LLVM using CMake since I ran svn up yesterday. And it would be great if somebody could tell me whether the problem is on my end. What I did was, ~/llvm$ svn up ~/llvm$ mkdir cmakebuild ~/llvm$ cd cmakebuild ~/llvm/cmakebuild$ cmake -DCMAKE_BUILD_TYPE:STRING="Release" -DLLVM_TARGETS_TO_BUILD:STRING="X86" ..

Hi Folks, I am building LLVM 3.9.1 using the Yocto build system for a cross build. The compiled bins/libs work totally fine on the target machine however there seems to be an intermittent race condition during the build which causes a build failure. On the failed builds I usually see things being linking/compiling twice e.g. Linking CXX static library ../libLLVMSupport.a cd

We can't guarantee what storage duration the caller's request for a thread name has; and in fact, if the caller uses plugin_name() for their thread name, then the moment .unload is called, our threadlocal storage is pointing to la-la-land and we get a nice SEGV while trying to print any debug message. So copy the user's string instead. Signed-off-by: Eric Blake

When accepting a connection on a TCP or Unix domain socket we recorded the peer address in both the thread_data struct and thread-local storage. But for no reason because it was never used anywhere. Since we were only allocating a ‘struct sockaddr’ (rather than a ‘struct sockaddr_storage’) it's likely that some peer addresses would have been truncated. Remove all this code, it had no

If the plugin .pread method did not fill the buffer with data then the contents of the heap could be leaked back to the client. To avoid this create a thread-local data buffer which is initialized to zero and expanded (with zeroes) as required. This buffer is shared between pread and pwrite which makes the code a little bit simpler. Also this may improve locality by reusing the same memory for

On 11/16/2017 09:13 PM, Eric Blake wrote: > We can't guarantee what storage duration the caller's request > for a thread name has; and in fact, if the caller uses > plugin_name() for their thread name, then the moment .unload > is called, our threadlocal storage is pointing to la-la-land > and we get a nice SEGV while trying to print any debug message. > So copy the

On 4/23/19 10:09 AM, Richard W.M. Jones wrote: > If the plugin .pread method did not fill the buffer with data then the > contents of the heap could be leaked back to the client. To avoid > this create a thread-local data buffer which is initialized to zero > and expanded (with zeroes) as required. > > This buffer is shared between pread and pwrite which makes the code a >

Hi, I'm confused by the comment and the source code of lib/Support/Mutex.cpp and lib/Support/RWMutex.cpp. In these files there are: // This variable is useful for situations where the pthread library has been // compiled with weak linkage for its interface symbols. This allows the // threading support to be turned off by simply *not linking against -lpthread*. // In that situation, the

Hi, The old llvm::sys::RWMutex use platform-specific lock mechanism to implement read/write lock. For example, SRWLock on Windows and pthread read/write lock on *nix systems. However, in comparison with the approach that implement read/write lock base on std::atomic, the old methods not only has potential performance issue(Sorry I can't provide concrete evidence, any benchmark result is

I've hit this weird compiler error when building llvm/clang $ clang --version clang version 2.9 (trunk 125254) Target: x86_64-apple-darwin10 Thread model: posix Source rev is 125326 $ make llvm[1]: Compiling APFloat.cpp for Release build llvm[1]: Compiling APInt.cpp for Release build llvm[1]: Compiling APSInt.cpp for Release build llvm[1]: Compiling Allocator.cpp for Release build llvm[1]:

Hi I've been able to semi compile (i.e. excluded code not present on the platform) the source code of the LLVM tblgen tool on the MinGW platform. However, when linking the object files the linker does not succeed: -------------------------- Linking tblgen debug executable (without symbols) C:/MinGW/msys/local/build/llvm/lib/Debug/libLLVMsystem.a(Signals.o)(.text+0x7e3): In function

Hello, Takumi, you are absolutely right! It was a problem with Perl. Many thanks! That problem solved, tried to compile again the kaleidoscope example but unfortunatelly now I get the link errors found bellow: $g++ -g –O3 toy.cpp `llvm-config –cppflags –ldflags –libs core`-o toy c:/llvm-2.7/Release/lib/libLLVMSystem.a(Signals.o):Signals.cpp:(.text+0x4d4): undefined reference to

This is a quick hack to experiment with parallel threading model in the python plugin. Changes: - Use aligned buffers to make it possible to use O_DIRECT. Using parallel I/O does not buy us much when using buffered I/O. pwrite() copies data to the page cache, and pread() reads data from the page cache. - Disable extents in the file plugin. This way we can compare it with the python

On Thu, Aug 06, 2020 at 11:22:00PM +0300, Nir Soffer wrote: > This is a quick hack to experiment with parallel threading model in the > python plugin. > > Changes: > > - Use aligned buffers to make it possible to use O_DIRECT. Using > parallel I/O does not buy us much when using buffered I/O. pwrite() > copies data to the page cache, and pread() reads data from the

I'm trying to compile llvm (cvs head) on windows (WinXP sp2) using the lastest mingw, but I'm getting the link errors found below. It seems that the tools are not being linked with win32 api lib (libimagehlp.a and libpsapi.a) which defines the missing symbols. The TOOLS_VERBOSE link command is at the end of the mail and does not contain those libraries. The configure line I'm

On Mon, 15 Apr 2024 07:53:16 +0200 Daniel M?ller via samba <samba at lists.samba.org> wrote: > I did it: > root at dom2:~# samba-tool dbcheck --fix > Checking 705 objects > Reset nTSecurityDescriptor on CN=Deleted Objects,DC=tlk,DC=loc back > to provision default? Owner > mismatch: SY (in ref) DA(in current) Group mismatch: SY (in ref)

Thanks Kenneth, but it looks like the problem lies elsewhere :ar -cru /Users/nraynaud/Desktop/geek/llvm-svn/build/Debug/lib/libLLVMSystem.a /Users/nraynaud/Desktop/geek/llvm-svn/build/lib/System/Debug/Alarm.o /Users/nraynaud/Desktop/geek/llvm-svn/build/lib/System/Debug/Disassembler.o /Users/nraynaud/Desktop/geek/llvm-svn/build/lib/System/Debug/DynamicLibrary.o

2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to spend 10 minutes waiting