search for: libsupport

> 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 t...

> 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...

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" for "System"? I...

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 mention its inclusion in libSupport > > (important) and fix file paths (mechanical, less important)....

...tablegen. Can we split support and ADT into > two - the parts that tablegen depends on and the parts that it doesn’t? > > In all the comments downthread, I think there is one thing that hasn't > been mentioned: doing a split like this makes tblgen evolution more > difficult. If libsupport was split into “used by tblgen” and “not used by > tblgen” sections, and then a new tblgen feature needs to use other parts of > libsupport, they’d have to be moved into the “used by tblgen” directory. > > Splitting libsupport as a whole out into its own llvm subproject has come > up...

...the static libraries vmcore, asmparser, and support.a. Then I tried to compile these LLVM modules as shared libraries, by set SHARED_LIBRARY = 1 for those makefiles. It did generate the *.so libraries. However, when I linked with the shared libraries, it always complained that ...llvm/lib/Debug/libsupport.so: undefined reference to `dlerror' ...llvm/lib/Debug/libsupport.so: undefined reference to `dlopen' ...llvm/lib/Debug/libsupport.so: undefined reference to `dlsym' Do you have any suggestion for this problem? Also, do you have any plan to enhance your makefiles to provide developers...

Hi llvm team, There's an inconsistency between gold plugin, which is built with large file support, because gold requires that, and the rest of LLVM (libLTO, libSupport) which are built w/o it. It means that every function in libLTO, libSupport, etc which uses off_t is inaccessible from LLVMgold. The most important problem here is that LLVMgold actually uses such functions from libLTO and libSupport, which causes subtle problems in some cases. I see four possible...

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 "Support" for "System"? I wasn't around when the transition w...

...lprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn’t? > > In all the comments downthread, I think there is one thing that hasn't been mentioned: doing a split like this makes tblgen evolution more difficult. If libsupport was split into “used by tblgen” and “not used by tblgen” sections, and then a new tblgen feature needs to use other parts of libsupport, they’d have to be moved into the “used by tblgen” directory. > > Splitting libsupport as a whole out into its own llvm subproject has come up many times th...

...> I've done on many occasions), I'm not sure the llvm project wants to > maintain and support a generic c++ library. > Sorry, I'm not sure to follow you, because my impression is that we're *already* maintaining a generic C++ library in-tree. The fact that the mess that is libSupport today does not allow to split ADT (or other generic utilities in libSupport) out-of-tree easily does not change that. > Given that I don't think use outside of llvm is a great line to split on. > I think on the opposite that it is a valuable line because it matches a conceptual layer....

...re is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn’t? >> >> In all the comments downthread, I think there is one thing that hasn't been mentioned: doing a split like this makes tblgen evolution more difficult. If libsupport was split into “used by tblgen” and “not used by tblgen” sections, and then a new tblgen feature needs to use other parts of libsupport, they’d have to be moved into the “used by tblgen” directory. >> >> Splitting libsupport as a whole out into its own llvm subproject has come up many...

...s that tablegen depends on and the parts that it doesn’t? >>>>> >>>>> In all the comments downthread, I think there is one thing that hasn't >>>>> been mentioned: doing a split like this makes tblgen evolution more >>>>> difficult. If libsupport was split into “used by tblgen” and “not used by >>>>> tblgen” sections, and then a new tblgen feature needs to use other parts of >>>>> libsupport, they’d have to be moved into the “used by tblgen” directory. >>>>> >>>>> Splitting libsupp...

On Fri, 13 Apr 2007, Devang Patel wrote: >> I think libhello should drop its use of SlowOperationInformer. > > That'll fix Hello example. However, anyone trying to load their custom > pass will likely to run into this again. It is a long-standing issue. The deal is that libsupport (and many others) are .a files. If one of the .o files in the .a file is used by a plugin, but not by the tool, they will get link errors. There isn't a good solution to this, I'd rather keep libhello as a santity test rather than a test for a complete solution. :) For any specific...

On Apr 13, 2007, at 12:28 PM, Chris Lattner wrote: > On Fri, 13 Apr 2007, Devang Patel wrote: >> And this brings back CommandLine Error: Arugment blah defined more >> than once! >> >> And without this, opt -load .../LLVMHello.dylib -hello does not work >> on Darwin because dyld is not able to find SlowerOperationInformer ;) > > I think libhello should drop

...he parts that it doesn’t? >>>>>>> >>>>>>> In all the comments downthread, I think there is one thing that >>>>>>> hasn't been mentioned: doing a split like this makes tblgen evolution more >>>>>>> difficult. If libsupport was split into “used by tblgen” and “not used by >>>>>>> tblgen” sections, and then a new tblgen feature needs to use other parts of >>>>>>> libsupport, they’d have to be moved into the “used by tblgen” directory. >>>>>>> >>>&g...

...of the build. I noticed that gtest has an > option to output test results in XML form, although I have not played > with this personally, it might be useful in this regard. The only thing I'm concerned about here is extending build time. For example, if we have a lot of unit tests for libsupport (e.g. densemap), I wouldn't want those tests to be run unless libsupport changes. It should just be a "small matter of makefile hackery" to get this going I suppose. Is there a final proposed version of the patch with the changes Misha asked for? If so, I'll review and...

...#39;ve done on generating source-level debugging info into a DebugInfoBuilder class like I described earlier. I went and added a new file to the "Support" directory (in include and lib). However, when I try to compile it, it complains of a circular dependency error between libCore and libSupport: find-cycles.pl: Circular dependency between *.a files: find-cycles.pl: libLLVMCore.a libLLVMSupport.a The odd part is, that no other file in LLVM even references my header, so I'm not sure where the cycle is. The headers that I am including in my .cpp file are: #include <...

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

...t;>>>>>>> >>>>>>>>> In all the comments downthread, I think there is one thing that >>>>>>>>> hasn't been mentioned: doing a split like this makes tblgen evolution more >>>>>>>>> difficult. If libsupport was split into “used by tblgen” and “not used by >>>>>>>>> tblgen” sections, and then a new tblgen feature needs to use other parts of >>>>>>>>> libsupport, they’d have to be moved into the “used by tblgen” directory. >>>>>>&gt...

...that the generated makefiles could handle two targets building simultaneously, but you may be right. >> >> I don’t think we should solve this with separate directories though because that is a waste. A better solution would be making a custom command & target that builds the native libSupport, then make all tablegen targets depend on that one. >> >> That way we only build the native libSupport once. >> >> -Chris >> >>> On Sep 28, 2015, at 1:48 PM, Alex Wang <aw1621107 at gmail.com> wrote: >>> >>>> >>>> On...