similar to: [LLVMdev] questions about shared library ...

Hi, Yiping! I am not sure of the answer to your question, but I am forwarding it to the LLVMdev list where I am sure someone will be able to answer you. Please send development questions directly to LLVMdev and you will get a response quicker, as it is read by many LLVM developers. ----- Forwarded message from Yiping Fan <fanyp at cs.ucla.edu> ----- Date: Mon, 31 Oct 2005 17:20:24 -0800

Hi, Until recently I've been building LLVM with SHARED_LIBRARY=1. However, sith current svn, build now fails with unresolved symbols building opt. I've done a clean checkout, configure and make so it's not down to any local changes I've made. I'm building with: ./configure --enable-assertions \ --enable-expensive-checks=no \ --enable-pic \ --enable-targets=host-only \

> Ah, ok. In that case, I think that it would be best to make a new page for > libSupport, and have it defer to SystemLibrary.rst for discussion of the > "libSystem" parts of libSupport. The major necessary changes for > SystemLibrary.rst would then be to mention its inclusion in libSupport > (important) and fix file paths (mechanical, less important). Sorry, but at least

On Mon, May 27, 2013 at 5:47 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > AFAIK, libSupport does more than what this document describes (for > example, > > it contains ADT, which are portable and not system-specific, contrary to > the > > second paragraph of the document). Does it make sense to just globally > > replace "Support"

I suspect my change adding --enable-shared broke you, since that configure option didn't exist before last week (r97119). SHARED_LIBRARY is not one of the variables you're supposed to be able to set on make's command line (http://llvm.org/docs/MakefileGuide.html#variables). What are you using it for? What happens if you remove it? On Tue, Mar 2, 2010 at 1:35 PM, James Williams

> AFAIK, libSupport does more than what this document describes (for example, > it contains ADT, which are portable and not system-specific, contrary to the > second paragraph of the document). Does it make sense to just globally > replace "Support" for "System"? I wasn't around when the transition was > made, so I don't know. Please get a confirmation

Yeah. We need to have more extra fields in the instruction. Fo example, during high-level synthesis, we must schedule an instruction to a certain control step (or cycle), and bind it to be execute on a certain functional unit, etc. Besides the in-memory exchange of the information, we also want on-disk exchange. That introduces the write-out/parse-in problem. Thanks ----- Original Message -----

Thanks a lot. A see the shared library in linux version. I initially tried doing this in cygwin where I dont see the shared library being built. Do u think it could have been cygwin that is the problem? Aparna On Mon, Apr 13, 2009 at 5:16 PM, Milos Puzovic <milos.puzovic at gmail.com>wrote: > In order to generate shared libraries you need to have SHARED_LIBRARY > and

I'm CC'ing the llvm-dev list because other people are more knowledgeable about the bytecode format/encoding than I am. Please follow-up the replies to the list. On Wed, Oct 20, 2004 at 11:27:53AM -0700, Yiping Fan wrote: > We also want to extend the llvm instructions/intrinsic > functions/types/passes to support our high-level synthesis for > hardware. First of all, we want to

In order to generate shared libraries you need to have SHARED_LIBRARY and LOADABLE_MODULE defined in the Makefile. See here for more details: http://llvm.org/docs/MakefileGuide.html#libraries On 13 Apr 2009, at 20:46, aparna kotha wrote: > I am trying to run the LLVM hello world pass. I observe that in the > OUPUT_DIR/lib the LLVMHello.a and LLVMHello.la libraries are >

Hi, In buildling XPS using LLVM's makefile system, I'm finding that there's a few things lacking in our support for LLVM-based projects. The items below should help but may require changes to project makefiles. I thought I'd check before just going and doing it. 1. Various autoconf generated variables (e.g. abs_top_srcdir) are set in the makefiles but not used. They

Fair enough, i sort of regret mentioning that specific method of splitting originally. For the record, i think any splitting should make sense on its own merit without considering tablegen, and hopefully the end result of "tablegen eventually depends on less stuff" would happen naturally On Sun, Jun 4, 2017 at 10:37 AM Chris Lattner <clattner at nondot.org> wrote: > > >

On Fri, 14 Jan 2005, Reid Spencer wrote: > In buildling XPS using LLVM's makefile system, I'm finding that there's > a few things lacking in our support for LLVM-based projects. The items > below should help but may require changes to project makefiles. I > thought I'd check before just going and doing it. ok. > 1. Various autoconf generated variables (e.g.

On Mon, May 27, 2013 at 7:36 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Ah, ok. In that case, I think that it would be best to make a new page > for > > libSupport, and have it defer to SystemLibrary.rst for discussion of the > > "libSystem" parts of libSupport. The major necessary changes for > > SystemLibrary.rst would then be to

On Mon, May 27, 2013 at 11:34 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > ping,is there any other problems in this patch? > > AFAIK, libSupport does more than what this document describes (for example, it contains ADT, which are portable and not system-specific, contrary to the second paragraph of the document). Does it make sense to just globally replace

Hi, I'm trying to figure out which LLVM libraries (er.. object files that is) I should link with my programs. It isn't clear to me what the build output of LLVM is. I tried the new make "install" target and got a plethora of .o files. The few .a files I got had _likely_to_conflict_ names such as "libsupport.a" and "libtarget.a". None of the .o files are

I am trying to run the LLVM hello world pass. I observe that in the OUPUT_DIR/lib the LLVMHello.a and LLVMHello.la libraries are generated. But I am confused as to how to generate the .so library file from here. I am kinda new to compilers and hence the question I know is basic , but couldnt figure the answer out myself. Thanks a lot for your help. Regards -- -- Aparna Kotha Research

I believe because cygwin behaves like windows (it is just a posix layer over window) it doesn't have dynamic linking hence only static libraries have been built. On 13 Apr 2009, at 23:16, aparna kotha wrote: > Thanks a lot. > > A see the shared library in linux version. I initially tried doing > this in cygwin where I dont see the shared library being built. Do > u

Yes, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported,

2017-05-31 17:11 GMT-07:00 Michael Spencer <bigcheesegs at gmail.com>: > On Mon, May 29, 2017 at 10:22 AM, Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> 2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: >> >>> On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < >>> llvm-dev