similar to: [LLVMdev] Ideal way to build llvm and friends?

I applied the patch Gene wrote here: https://github.com/triton/nixpkgs/commit/06e146b2ce5eaaa54ebea061dd5797f89ae2c37c The tree after that commit is entirely based on gcc5. In order to do a test with gcc4.9, I reverted: https://github.com/triton/nixpkgs/commit/8ccc1f121f379f4d66ce0a66f581c49d25fb4e15#diff-d7222640d82ff920625e9311d05a0137 and then built two images, one entirely based on gcc4.9

On 4/5/23 10:31, Aki Tuomi wrote: > Hi! > The crash occurs inside libldap. > Aki Thanks Aki, It was against openldap 2.6.3. Subsequently, I tried openldap 2.6.4 which is in nixpkgs unstable, but I wasn't able to test this because of an issue at the Portunus/openldap end of things. I think I'm out of time for experimenting with ldap for now, but I may come back around to this

> > On Oct 20, 2011, at 3:13 AM, Shea Levy wrote: > >> Hello, >> >> The llvm 2.9 configure script fails to check for groff, causing a >> failure very late in the game when building man pages, and, on OSX, >> sw_vers. I'll try to write a patch for this myself, but autoconf is >> largely black magic to me so I thought I'd throw this out there in

https://bugzilla.netfilter.org/show_bug.cgi?id=1247 Bug ID: 1247 Summary: Module crash due to broken count Product: netfilter/iptables Version: unspecified Hardware: other OS: other Status: NEW Severity: blocker Priority: P5 Component: unknown Assignee: netfilter-buglog at

Hi all, I'm trying to understand why LLVM uses @rpath as the install name in its dynamic libraries on macOS. This complicates the process of linking against libLLVM from third-party tools and isn't nearly as common a practice on macOS as it is on Linux. I tried tracing through history on the LLVM repo and the main thing I could find was a commit from ages ago saying that the libraries are

On 05/02/2012 01:00 PM, Dave Zarzycki wrote: > Shea, > > Feasible? Sure, anything is feasible. A good idea? Not really. The internal lld file format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the reason why linkers can often be slow is because the

Shea, Feasible? Sure, anything is feasible. A good idea? Not really. The internal lld file format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the reason why linkers can often be slow is because the intermediate and final object file formats are conflated. davez On

On 12/19/11 7:19 PM, Howard Hinnant wrote: > On Dec 19, 2011, at 7:14 PM, Shea Levy wrote: > >> Hello all, >> >> Is it possible, if using libc++ and compiler-rt, to have a clang with no >> runtime dependencies on any GCC components on Linux? If not, will this >> ever be possible? > We are working on a new libc++abi: http://libcxxabi.llvm.org/ which carries

Hello all, Is it possible, if using libc++ and compiler-rt, to have a clang with no runtime dependencies on any GCC components on Linux? If not, will this ever be possible? Cheers, Shea Levy

On 10/19/11 11:58 PM, Eli Friedman wrote: > On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy<shea at shealevy.com> wrote: >> 2. Are target-specific behaviors documented for each supported target? > When anything has target-specific behavior, that fact should be > documented. Beyond that, if you have a question about what some > construct is supposed to do, please ask. What I

> Regardless of any of that, given that TBD files _are_ an integral part of the apple platform, supporting them is certainly a necessity in order to have a working apple linker. So, if making LLD work for Apple/MachO is the justification for adding TBD support to LLVM, that seems self-evidently a reasonable thing to do. On the other hand, it looks like the LLD mach-o code is unmaintained

On Thu, Oct 20, 2011 at 2:37 AM, Shea Levy <shea at shealevy.com> wrote: >. The > (probably impossible) end-goals to this project would be a) that every > program which passes its checks would be as safe to run in kernel mode > with full memory access as it would be in user mode That would be a very useful thing to have for embedded systems. Some such as uCLinux run ports of

On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy <shea at shealevy.com> wrote: > Hello, > > I'd like write a program that performs static analysis of code at the > LLVM assembly/bitcode level, and to do so I plan on extensively > referencing the language reference. As I hope to eventually use this > tool as part of a security analysis of untrusted code, I need to be >

On Oct 20, 2011, at 2:37 AM, Shea Levy wrote: > On 10/19/11 11:58 PM, Eli Friedman wrote: >> On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy<shea at shealevy.com> wrote: >>> 2. Are target-specific behaviors documented for each supported target? >> When anything has target-specific behavior, that fact should be >> documented. Beyond that, if you have a question

On Dec 19, 2011, at 7:14 PM, Shea Levy wrote: > Hello all, > > Is it possible, if using libc++ and compiler-rt, to have a clang with no > runtime dependencies on any GCC components on Linux? If not, will this > ever be possible? We are working on a new libc++abi: http://libcxxabi.llvm.org/ which carries the llvm license. Howard

Hello, Would it be feasible to use the internal lld file format as the native executable format for an OS? Are there performance or space considerations that would make this a poor choice? Cheers, Shea Levy P.S. please CC me on replies, I'm not subscribed.

Hello, I'd like write a program that performs static analysis of code at the LLVM assembly/bitcode level, and to do so I plan on extensively referencing the language reference. As I hope to eventually use this tool as part of a security analysis of untrusted code, I need to be rather strict in my interpretation of the document. As such, I have some questions about how the implementers

Hello, The llvm 2.9 configure script fails to check for groff, causing a failure very late in the game when building man pages, and, on OSX, sw_vers. I'll try to write a patch for this myself, but autoconf is largely black magic to me so I thought I'd throw this out there in case someone more experienced in this stuff wants to fix this. Cheers, Shea Levy

On Oct 20, 2011, at 3:13 AM, Shea Levy wrote: > Hello, > > The llvm 2.9 configure script fails to check for groff, causing a > failure very late in the game when building man pages, and, on OSX, > sw_vers. I'll try to write a patch for this myself, but autoconf is > largely black magic to me so I thought I'd throw this out there in case > someone more experienced

On 23/04/2018 6:33 AM, Peter Simons wrote: > Hi, > > I just tried to upgrade Nixpkgs to R 3.5.0, but unfortunately the new > version fails its regression test suite. We configure the build using > the flags "--without-recommended-packages", in case that's relevant. You > can see a complete build log with all relevant information at [1]. > Anyway, the test