similar to: LLVM compilation problem with musl

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had

I've finally managed to extract from Kaleidoscope one particular thing that it seems to me should be working and isn't. Given the global declaration extern "C" void foo() {} within the same program I have RTDyldMemoryManager::getSymbolAddressInProcess("foo") And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? -------------- next part

Hi everybody, I just updated to the latest svn trunk version, but now the code does not compile anymore. It trows an error in "f:\dev\llvm\lib\system\Win32/DynamicLibrary.inc(159) : error C2228: left of '.find' must have class/struct/union". Below you can find the small patch which makes the compiler happy again :-) Sincerely yours Marius Wachtler

Hi Reid, > > if ((err = dlerror())) { > > error("earlier undetected dlerror: %s\n", err); > > } > > p = dlsym(handle, sym); > > if ((err = dlerror())) { > > error("dlsym failed: %s\n", err); > > } > > No, you're not missing anything. The correct way to check for errors > is with

On Fri, 20 Jul 2007, Ralph Corderoy wrote: > I could be missing something, but shouldn't the use of dlsym() be > The authors of dlsym() realised the return value was overloaded AFAICS. Yep, patches welcome :) -Chris -- http://nondot.org/sabre/ http://llvm.org/

> ELLCC (http://ellcc.org), my clang/LLVM based cross development tool chain for > ARM, Microblaze, Mips, Power PC, and X86, now incorporates musl > (http://www.etalabs.net/musl) as its standard C library for Linux. musl is a > MIT licensed, highly POSIX compliant library offering high performance and a > small foot print. I spent several weeks evaluating musl before deciding to use

I want to build LLVM-based toolchain with Musl, I have LLVM sources with clang and lld (under `tools` directory) and libunwind, compiler-rt, libcxx and libcxxabi (under `projects` directory). All are the latest versions cloned from GitHub mirror, branch `master`. I'm trying to configure with the following options: CLANG_DEFAULT_CXX_STDLIB = libc++ CLANG_DEFAULT_RTLIB = compiler-rt

Here is tests/reg-tests-1c.Rout.fail - http://pastebin.com/raw/3QVDUBwT About the libm, I don't know which one R uses. musl has its on libm. http://git.musl-libc.org/cgit/musl/tree/src/math I think I also have openlibm installed, but I don't think that's used. Any more information I can give to help debug this? Thanks. On Mon, Feb 1, 2016 at 3:49 PM, Martin Maechler <maechler

There is incompatibility between R strptime and musl libc. I posted about it on their mailing list, but they need more information I can't provide, so I'm forwarding the message here in hope R developers can help. Thanks. ---------- Forwarded message ---------- From: Rich Felker <dalias at libc.org> Date: Thu, Feb 4, 2016 at 2:07 PM Subject: Re: [musl] strptime() question To: Alba

Le 25/03/2019 à 14:41, Peter Smith a écrit : > Hello David, > > I don't know much about the specifics of Musl, so I'm responding generally. > > As I understand it, clang expects to find the compiler-rt libraries > relative to the resource directory, which you can find out the > location of with clang --print-resource-dir . By default it is > lib/clang/9.0.0

Hello, I wanted to ask if there's a reason efi/wrapper.{h,c} use __uint*_t instead of including stdint.h and using the therein defined uint*_t types? This breaks compilation of the efi blobs on systems with the musl libc since that doesn't define __uint*_t types. -- Simon Thelen

On 5 Jun 2017, at 15:17, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/5/17 5:17 AM, Dmitry Golovin via llvm-dev wrote: >> I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. >> >> The configuration is the following: >> >> LIBCXX_HAS_MUSL_LIBC=ON >>

Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once

Hi, I?m trying to compile libguestfs on Alpine Linux, that uses musl libc (lightweight, fast and simple standards-conformance libc). It fails in the check phase due to missing glibc-style extended printf formatters. -- checking for register_printf_specifier... no checking for register_printf_function... no configure: error: in `/tmp/libguestfs/src/libguestfs-1.32.6?: configure: error: No support

Hi Chris, > Once you have that, you are hitting another problem. Specifically, > the JIT::getPointerToNamedFunction method in > lib/ExecutionEngine/JIT/Intercept.cpp just does a dlsym on missing > symbols. If dlsym returns null, you get the error message. > > The problem here is that .objc_class_name_* are special symbols that > are used by the objc linker support and they

Reid, I'm just curious to know if these errors are on your new year list :) ---------------- make[1]: Entering directory `/C/projects/build/MinGW/llvm-1-1/lib/System' llvm[1]: Compiling DynamicLibrary.cpp for Debug build In file included from c:/projects/src/llvm-1/llvm/lib/System/DynamicLibrary.cpp:25: c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:22: warning:

Hi, Has anyone succeeded in building llvm on AIX? Currently I am investigating several tools for code analyses and I came upon Clang. We at CCV run our core business applications on RS6000/AIX. At our department we develop those applications. The reviews on clang look very promising. I was able to build and run it on Linux (SuSE 12.1) without any problems. I tested it with valgrind sources and

Hello there, I'm building a Linux distribution based on musl and LLVM as default toolchain (including lld/libc++/libc++abi/libunwind rather than GNU). For most of the time this works pretty well. However I'm having troubles with few packages, webkit for instance fails because of max_align_t being redeclared in musl's stddef.h I see that stddef.h is provided by both musl and in the

Not really. I'm pretty much leaving the win32 directory up to Jeff Cohen these days. I don't have a way to replicate the problem. Reid. On Wed, 2004-12-29 at 12:46, Henrik Bach wrote: > Reid, > > I'm just curious to know if these errors are on your new year list :) > ---------------- > make[1]: Entering directory `/C/projects/build/MinGW/llvm-1-1/lib/System' >

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