search for: stlport

Hi Jack, I'm almost there with Android..... I've actually got the static and dynamic libraries built. I'm choking on the test suite. Do you want to take a shot at working around Android and [embedded, lame] STLport? I would try removing the call to rend() in std::map<_Key, _Tp, _Compare, _Alloc>::rend(). But I really should not modify program code. Fiddling with a Makefile is one thing, but modifying source code is another. Jeff arm-linux-androideabi-g++ --sysroot=/opt/android-ndk-r8e//platforms/andr...

Good to hear that. Doesn't seem to be a popular combination since googling results little information on this. Is it possible for you to show the changes to LLVM? Personally I don't like STLport, not sure the real benefit versus using compiler's STL. On Tue, Apr 17, 2012 at 12:04 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > We are able to compile it internally, but it required some changes to > LLVM to get it to work.**** > > ** ** > > *From:* llvmde...

I am curious to see if anyone has ever been successfully compiled LLVM with STLport? I tried compiling LLVM 3.0 with STLport-5.2.1, and failed. Thanks, Welson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120417/e3322a36/attachment.html>

We are able to compile it internally, but it required some changes to LLVM to get it to work. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Welson Sun Sent: Tuesday, April 17, 2012 11:48 AM To: LLVM Developers Mailing List Subject: [LLVMdev] STLport I am curious to see if anyone has ever been successfully compiled LLVM with STLport? I tried compiling LLVM 3.0 with STLport-5.2.1, and failed. Thanks, Welson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

...diff against 3.0. The reason we are using it is because of problems with statically linking libstdc++ on certain Linux distributions. From: Welson Sun [mailto:welson.sun at gmail.com] Sent: Tuesday, April 17, 2012 7:49 PM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] STLport Good to hear that. Doesn't seem to be a popular combination since googling results little information on this. Is it possible for you to show the changes to LLVM? Personally I don't like STLport, not sure the real benefit versus using compiler's STL. On Tue, Apr 17, 2012 at 12:04 PM,...

...atch re-attached with the correct ordering > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Joerg Sonnenberger > Sent: Wednesday, April 18, 2012 8:39 AM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] STLport > > On Wed, Apr 18, 2012 at 03:04:00PM +0000, Villmow, Micah wrote: > > Sure, here is our diff against 3.0. > > A large part of that seems to be applied already. The last chunk looks > wrong though? > > Joerg > _______________________________________________ > LL...

On Wed, Apr 18, 2012 at 03:04:00PM +0000, Villmow, Micah wrote: > Sure, here is our diff against 3.0. A large part of that seems to be applied already. The last chunk looks wrong though? Joerg

On Wed, Apr 18, 2012 at 04:42:00PM +0000, Villmow, Micah wrote: > Oops, I had the arguments backward. Patch re-attached with the correct > ordering The casts for spelling NULL with explicit cast shouldn't be necessary. What is the error you are dealing with? Joerg

...ordering > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > > On Behalf Of Joerg Sonnenberger > > Sent: Wednesday, April 18, 2012 8:39 AM > > To: llvmdev at cs.uiuc.edu > > Subject: Re: [LLVMdev] STLport > > > > On Wed, Apr 18, 2012 at 03:04:00PM +0000, Villmow, Micah wrote: > > > Sure, here is our diff against 3.0. > > > > A large part of that seems to be applied already. The last chunk looks > > wrong though? > > > > Joerg > > _____________...

...y for libc & system calls >>> makes perfect sense, and I'm not trying to suggest changing it. >>> >>> I think the most similar situation is is this one: >>> >>> In the previous version of ThreadSanitizer we used a private copy of >>>> STLport in a separate namespace and a custom libc (small subset). >>>> >>> >>> My proposal is very similar except without the need to modify the C++ >>> standard library in use. Instead, I'm suggesting post-processing the >>> library to ensure that the st...

...compiler provides and without third party packages. Thanks, reid. On Fri, 2004-09-24 at 07:46, Jeff Cohen wrote: > I added the include of cstudio and it fails with plain VC7.1; the file > does not exist. > > Add it for now. If it is impossible to build with VC7.1 and without > STLPort, then there really isn't a choice. I have to research the issue > myself to see if it's possible to avoid using STLPort. > > > On Fri, 24 Sep 2004 07:42:51 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > Someone needs to adjudicate on whether I add...

...hink the current strategy for libc & system calls makes >> perfect sense, and I'm not trying to suggest changing it. >> >> I think the most similar situation is is this one: >> >> In the previous version of ThreadSanitizer we used a private copy of >>> STLport in a separate namespace and a custom libc (small subset). >>> >> >> My proposal is very similar except without the need to modify the C++ >> standard library in use. Instead, I'm suggesting post-processing the >> library to ensure that the standard C++ library c...

I added the include of cstudio and it fails with plain VC7.1; the file does not exist. Add it for now. If it is impossible to build with VC7.1 and without STLPort, then there really isn't a choice. I have to research the issue myself to see if it's possible to avoid using STLPort. On Fri, 24 Sep 2004 07:42:51 -0700 Reid Spencer <reid at x10sys.com> wrote: > Someone needs to adjudicate on whether I add the #include of <cstdio> or...

Hi, Yes, stlport was a pain to deploy and maintain + it calls normal operator new/delete (there is no way to put them into a separate namespace). Note that in some codebases we build asan/tsan runtimes from source. How the build process will look with that object file mangling? How easy it is to integrate it into...

...binary. I'm with you there. In particular, I think the current strategy for libc & system calls makes perfect sense, and I'm not trying to suggest changing it. I think the most similar situation is is this one: In the previous version of ThreadSanitizer we used a private copy of > STLport in a separate namespace and a custom libc (small subset). > My proposal is very similar except without the need to modify the C++ standard library in use. Instead, I'm suggesting post-processing the library to ensure that the standard C++ library code in the runtime is kept complete distinc...

Someone needs to adjudicate on whether I add the #include of <cstdio> or not. I can't test this so, Paolo/Henrik/Jeff, please let me know if I need to add it. Thanks, Reid. On Fri, 2004-09-24 at 07:08, Jeff Cohen wrote: > But I compiled that under vc7.1 as it was! > > On Fri, 24 Sep 2004 15:19:22 +0200 > Paolo Invernizzi <arathorn at fastwebnet.it> wrote: > >

...ckages. > > Thanks, > > reid. > > On Fri, 2004-09-24 at 07:46, Jeff Cohen wrote: >> I added the include of cstudio and it fails with plain VC7.1; the file >> does not exist. >> >> Add it for now. If it is impossible to build with VC7.1 and without >> STLPort, then there really isn't a choice. I have to research the >> issue >> myself to see if it's possible to avoid using STLPort. >> >> >> On Fri, 24 Sep 2004 07:42:51 -0700 >> Reid Spencer <reid at x10sys.com> wrote: >> >>> Someone need...

...Every time it ended with a maintenance nightmare; so currently valgrind has its own private subset of libc. In PIN, they have a private copy of system libc/libstdc++ and, afaict, it is constantly causing pain for the maintainers. In the previous version of ThreadSanitizer we used a private copy of STLport in a separate namespace and a custom libc (small subset). This worked, but had problems too (Dmitry was very angry at STLport for code bloat, stack size increase and some direct libc calls). Until recently this was not causing too much pain in asan/tsan, but our attempts to use the LLVM DWARF read...

...> In particular, I think the current strategy for libc & system calls makes > perfect sense, and I'm not trying to suggest changing it. > > I think the most similar situation is is this one: > > In the previous version of ThreadSanitizer we used a private copy of >> STLport in a separate namespace and a custom libc (small subset). >> > > My proposal is very similar except without the need to modify the C++ > standard library in use. Instead, I'm suggesting post-processing the > library to ensure that the standard C++ library code in the runtime i...

...the point is: Are you interested in taking in account the possibility that the LLVM source code could be compiled with Microsoft compiler on windows? Most of the problems are pretty trivial... for example: - A lot of .cpp lacked the inclusion of the <algorithm> header (I'm using the STLport-4.6.2, the Microsoft implementation of hash_map and co. is too different) - sometimes the std:: prefix is not used for 'sort' or 'find' - C99 style array wich are not supported by the Ms compiler... etc etc There's the interest for *umm* fixing that little problems? Best rega...