search for: dynamiclinking

Hello llvmdev, (just for fun) I've tried to compile LLVM under cygwin. With "make -k" I got only: ----------------- DynamicLinker.cpp: In function `void* GetAddressOfSymbol(const char*)': DynamicLinker.cpp:40: error: `RTLD_DEFAULT' undeclared (first use this function) DynamicLinker.cpp:40: error: (Each undeclared identifier is reported only once for each

On Sat, 25 Oct 2003, Valery A.Khamenya wrote: > (just for fun) I've tried to compile LLVM under cygwin. > With "make -k" I got only: Cool. We don't rountinely use this configuration, so there may be a bit of leg work you'll have to do... :) But that said, we would love to get LLVM working cleanly on it! > ----------------- > DynamicLinker.cpp: In function

OK, seems like I've got some more looking to do. From what I can find, the only difference with OS X and dynamic libraries is that you can't depend on the order of calling static constructors, but not that you can't depend on them getting called. :) If I find that library handling in LLVM needs changes to work with OS X, I'll send a patch. Thanks, -mike On Jun 19, 2004,

On Sun, 28 Nov 2004, Reid Spencer wrote: > The DynamicLibrary.cpp code is written and I believe it to be complete, > but it hasn't been tested much (at all). llvm-ld uses it to load its > plug-in optimization module. The implementation will use ltdl library > if its available, otherwise it tries to use dlopen/dlsym if they are > available, otherwise you get a compile time

Unfortunately it's not that easy, although I'd love to fix it if I can figure out how. OS X 10.3 does have dlfcn.h and dlopen() - for 10.3, they added the dlcompat library that uses the OS X NSLink* stuff to support dlopen and dlsym. configure seems to pick that up fine. It seems like the code that's there already should work fine, so I'm not sure where else to look. I'm

Solved. Short version: You don't need to change DynamicLinker.cpp at all. dlopen() should just work, except that the defaults for libtool are to produce the wrong kind of shared object. On OS X, libtool needs to be passed the -module option to create dlopen-able objects: % diff Makefile.rules.old Makefile.rules 326c326 < Link := $(LIBTOOL) --mode=link $(CXX) --- > Link

On Sat, 19 Jun 2004, Michael McCracken wrote: > I used the following short code to test loading the .dylib, and dlopen > works fine, but dlsym is less pretty - on OS X, it automatically > prepends an underscore to the symbol, which means that if you are > looking for main(), you ask for "main" and it looks for "_main", which > is how the symbols are named in

The DynamicLibrary.cpp code is written and I believe it to be complete, but it hasn't been tested much (at all). llvm-ld uses it to load its plug-in optimization module. The implementation will use ltdl library if its available, otherwise it tries to use dlopen/dlsym if they are available, otherwise you get a compile time warning and (void*)0 if you try to look up a symbol. I'm not sure

On Sat, 19 Jun 2004, Michael McCracken wrote: > Hi, I can't get opt to list (in -help) passes that I load using -load. > I see in the list archives that a similar problem has been brought up > before but I didn't see whether it was resolved. Also, this is on Mac > OS X, and the previous question was about Linux. The problem is that this has not been implemented yet on Mac

Hi, I can't get opt to list (in -help) passes that I load using -load. I see in the list archives that a similar problem has been brought up before but I didn't see whether it was resolved. Also, this is on Mac OS X, and the previous question was about Linux. This problem happens with the Hello pass, so I'll use that to illustrate. I'm using LLVM 1.2. The plugin loads with no

Hi, I'm working on a runtime autotuner that utilizes ORCv2 JIT (I'm closely tracking tip-of-tree), so linking new object files and patching in the new function(s) will happen frequently. One of the concerns my runtime system has is the ability to do one of the following: (1) replacement of the contents of a JITDylib with a new object file [to provide semi-space GC-style reclaiming], (2)

...- Any suggestions on how to debug this? Just knowing which line in the LLVM IR listed above causes this "GOT.func" import would be helpful. Thanks, Ömer [1]: https://gist.github.com/osa1/4c672fe8998c8e8768cf9f7c014c61d8 [2]: https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md

On Fri, 30 Apr 2004, Patrick Flanagan wrote: > Thanks! Grabbed the latest from CVS and added that linker option to the > config file. It looks like it compiles and runs the SPEC tests ok now. Great! > Just to make sure I understand how LLVM works, got a few clarifications: > > 1. The ppc code I'm generating with the -native-cbe is static, correct? Yes, it's purely static

> > There are two problems with this: 1) there is no JIT for PPC yet, so > LLVM will use the interpreter (which is intolerably slow and has other > issues). 2) Spec compiles the executables in one place and them moves > them to another, but it only copies the shell script and not the > bytecode file, so you get that error message. > > The normal solution to this problem

wasm-ld is currently unable to link a shared wasm library (generated with `wasm-ld --shared`) with .o files and produce a working executable. I'm curious if there's a fundamental reason for this, or is this simply something that wasn't needed and could be implemented if needed. I think this could be done by - Resolving "GOT.mem" and "GOT.func" imports and

Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

Sorry for the rapid fire replies, but this configuration works for me: install(DIRECTORY include/ DESTINATION include # FILES_MATCHING PATTERN "*.def" PATTERN "*.h" PATTERN "*.td" PATTERN "*.inc" PATTERN ".svn" EXCLUDE ) install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/ DESTINATION include # FILES_MATCHING PATTERN

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel