similar to: [LLVMdev] SysUtils.c compile problem on Mac OSX 10.3 with llvm-1.4

On Tue, 27 Sep 2005, Kevin J. Stephano wrote: > I am currently running on a Mac OSX 10.3.8 and trying to > compile llvm-1.4 on my local machine for Prof. Adve's class. > > I am using Apple's provided gcc 3.3 as my compiler. > > I ran into this compile error: > SysUtils.c: In function `executeProgram': > SysUtils.c:119: error: `RTLD_NEXT' undeclared (first

Hi Chris, > Also note, LLVM 1.4 will be released in the next few days, so if waiting is > an option, you might choose to do so. Alright, I've got llvm and llvm-gcc from RELEASE_14 cvs and tried building it under cygwin. 1) The first problem is with llvm in SysUtils.c: int executeProgram(const char *filename, char *const argv[], char *const envp[]) { ................ execveTy

On Wed, 2004-08-04 at 12:21, John Criswell wrote: > In regards to Misha's comments about the automatic execution of bytecode > files, there are several ways to do it: > > 1) Have bytecode files start with #!<JIT/llee/whatever> (portable) > 2) Encapsulate with ELF > 3) Register the type with the kernel (Linux only) > > I don't really care for the llee

Reid Spencer wrote: > On Wed, 2004-08-04 at 08:24, John Criswell wrote: > > >>o Configuration Files >> >>If it isn't too much trouble, I think we should go with XML for the >>following reasons: >> >>1) We wouldn't need to implement a parsing library. There are several >>XML parsing libraries available, and I'm guessing that

Reid Spencer wrote: > On Wed, 2004-08-04 at 12:21, John Criswell wrote: > >>In regards to Misha's comments about the automatic execution of bytecode >>files, there are several ways to do it: >> >>1) Have bytecode files start with #!<JIT/llee/whatever> (portable) >>2) Encapsulate with ELF >>3) Register the type with the kernel (Linux only)

On Wed, 2004-08-04 at 08:24, John Criswell wrote: > o Configuration Files > > If it isn't too much trouble, I think we should go with XML for the > following reasons: > > 1) We wouldn't need to implement a parsing library. There are several > XML parsing libraries available, and I'm guessing that they're available > in several different programming

Hello, I am trying to compile an rpm of samba 4.7.1 on centos 7. I have everything compiling but the problem is when I go to install the rpms, yum complains that samba-python requires libdnsserver-common-samba4.so. That file is part of samba-dc-libs which I believe doesn't work on centos 7 due to incompatibility with mit-kerberos. Does anyone know if there is a way to build this file without

Hi everyone. Since a few days I can't connect with a server via x2go. I get the following error message: Connection failed. Failed to start X2Go Agent session with ID stefsimo-60-1560249248_stDMATE_dp24. X2Go Agent terminated unexpectedly. Aborting session startup. Did you get the same error? cat /etc/centos-release CentOS Linux release 7.6.1810 (Core) cat /proc/version Linux version

I just checked in my changes to bugpoint and Makefile.programs in the test suite. These changes shouldn't conflict with yours. revision 75292 revision 75293 bugpoint now works for remote ARM if you run it directly from the command line. It doesn't work correctly when invoked from the test makefile because envvar PWD is being set to /bin/pwd and so causing GCC::ExecuteProgram to

Hi Eli, Thanks for the reply. I tried with -Xlinker="-ldl ". However it does not seem to make a difference. It seems that when bugpoint is run with --run-jit, the linker args are not passed to gcc (from tools/bugpoint/ExecutionDriver.cpp) : if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) RetVal =

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);

On Tue, Oct 28, 2008 at 12:17 PM, Prakash Prabhu <prakash.prabhu at gmail.com> wrote: > Generating reference output from raw program: <cbe><gcc> > Error running tool: [snip] > /tmp/cc08IpX8.o: In function `SyLoadModule': > bugpoint-test-program.bc.cbe.c:(.text+0x25705): undefined reference to > `dlopen' [snip] This is saying that compilation with CBE is

Hello, David > bugpoint now works for remote ARM if you run it directly from the > command line. It doesn't work correctly when invoked from the test > makefile because envvar PWD is being set to /bin/pwd and so causing > GCC::ExecuteProgram to do the wrong thing. I'm not sure what is going > on with that, perhaps something in the makefile hierarchy is setting > PWD to

Hi, LLI now supports -load but bugpoint LLI:ExecuteProgram() still assumes that it doesn't. The attached patch makes bugpoint pass -load arguments to LLI and lets one to use bugpoint with programs that depend on native shared libraries. best regargs, Timo Lindfors -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-bugpoint-load1.patch Type: text/x-diff

Hi Prakash, Unfortunately it looks like you need to do quite a bit of investigation into this. However, I hope I can provide some useful tips. 1. In general, lli and llc generate exact the same code except lli default to static codegen while llc defaults to dynamic-no-pic codegen. So try passing -relocation-model=dynamic-no-pic to lli. If this works, that means there are issues with

I've got a situation where I need to hook a dlopen() made by VDDK, a proprietary library, where it passes a relative name expecting to resolve to a copy of several libraries, including libstdc++.so, that it installs alongside itself, and fails to load if that resolves to the system libstdc++.so. The simplest solution of providing LD_LIBRARY_PATH is enough to load VDDK, but then poisons

Hi, I have a program that runs when statically compiled using llc and gcc but crashes with a segmentation fault when run with lli. I am trying to debug it with bugpoint and the initial part of bugpoint seems to be suggesting that I am somehow missing the linking with the libraries having dlsym/dlopen although I am passing it to lli : *$ bugpoint -run-jit

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

> I will investigate. I'm in the middle of it as well. Best regards, Viktor ----- Original Message ----- From: "David Goodwin" <david_goodwin at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, July 10, 2009 2:43 PM Subject: Re: [LLVMdev] Heads up! Working on bugpoint >I just checked in my changes to bugpoint and

David, Please find attached 2 diffs. Please notice that RemoteRunSafely.sh may get moved to the test suite sub-tree. We have targeted different areas fso far which is great. What's your plan? I have been thinking of using -run-custom and -safe-run-custom argumants for the cross-tools to keep bugpoint out of knowing any target details ans such. Best regards, Viktor ----- Original Message