similar to: [LLVMdev] Building 2.9 on WinXP

Hi, In X86MachObjectWriter::RecordX86Relocation I found the comment if (Target.isAbsolute()) { // constant // SymbolNum of 0 indicates the absolute section. // // FIXME: Currently, these are never generated (see code below). I cannot // find a case where they are actually emitted. Type = macho::RIT_Vanilla; } Is the FIXME still true? I've got some code that

Can I assume we're talking about MCJIT since a file format and relocations are involved? Some changes are required in order to get MCJIT to generate ELF object files. Eli Bendersky submitted a patch some time ago to modify the target triple code to enable this, but after a bit of discussion there didn't seem to be a consensus for accepting this proposal. If you want to try it out, the

Hi Verena, Windows + MachO is likely to run into lots of problems once you start passing in non-trivial code. The relocation model is very tied to Darwin. I believe some folks doing JIT on Windows have had some success w/ ELF. Hopefully someone more familiar with the specifics of that will chime in. -Jim On Jun 29, 2012, at 8:58 AM, Verena Beckham <verena at codeplay.com> wrote: >

Hi Jim, Andrew, Thanks, I read the discussions about using ELF + MCJIT + Windows and was hoping MachO would work just as well. Since you don't need to modify LLVM to be able to output MachO this was my first choice. But are you saying MachO will not work as well as ELF? Thanks for the patch Andrew, that will have to be my plan B in this case. Verena On 29/06/2012 23:47, Kaylor, Andrew

Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at

Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at

Friends, I changed one line of a package at the source level and then rebuilt it. When I run R CMD check, I get an error: installing R.css in C:/polsplineRS.Rcheck ---------- Making package polsplineRS ------------ adding build stamp to DESCRIPTION making DLL ... making hareall.d from hareall.c making heftall.d from heftall.c making lsdall.d from lsdall.c making lspecall.d from lspecall.c

Hey Daniel, Thank you for your help. I appreciate this. Your last tweak looks reasonable. However, there are 2 things with that: 1. It has changed the behaviour of the FindExecutable method. Before this change, it searched the directory the executable has been started from, then directories from PATH. Now it checks the current working directory first (makeAbsolute does this for just a file

Hello! As discussed in the previous thread about "Dovecot deliver logging problem and procmail" I have made a small patch for procmail to deliver through dovecot's deliver program (or any other delivery program). So Procmail does not write the mailboxes directly any more. So delivery is done through pipes and an external program which can deliver the files. Since dovecot's

On Fri, Dec 16, 2011 at 12:17:32PM -0500, David Fang wrote: >>> These results have far fewer failures than svn-trunk, and are also >>> comparable to bootstrapping with gcc-4.6.2, summarized here: >>> http://paste.lisp.org/display/126363 >>> (Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.) >>> This consistency between

Samba: binary kit from samba.org Samba version: 2.0.6 computer: SGI indigo2 with a 250MHz 4400 CPU, 64MB RAM, Irix 6.5.6m me: tarjei.jensen@kvaerner.com It looks like every time smbd spawns, the child process seems to die a horrible death and leave a core file. As a result I am unable to use any netbios services on the machine. The core file which I have examined says that the process died with

>> These results have far fewer failures than svn-trunk, and are also >> comparable to bootstrapping with gcc-4.6.2, summarized here: >> http://paste.lisp.org/display/126363 >> (Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.) >> This consistency between different bootstraps of the release gives me >> some hope that g++-4.0.1 is

After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. However, I'm also seeing a lot of new problems which weren't exposed before. After spending the better part of two

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

The Wine development release 1.3.29 is now available. What's new in this release (see below for details): - Extensive support for VBScript. - Various improvements to the calendar common control. - A number of XRender fixes and optimizations. - Several new functions in the MSVCP runtime. - A number of audio fixes. - DirectDraw cleanups. - Various bug fixes. The source is

I have download source ?1.10? from the internet and build it into lib Then I create a project as the helpdoc said I using vc2005(vc8) The source in my test project is as follow??copy from the helpdoc? #include <xapian.h> #include <iostream> using namespace std; int main(int argc, char **argv) { // Simplest possible options parsing: we just require three or more