search for: archivememb

Displaying 12 results from an estimated 12 matches for "archivememb".

Did you mean: archivemember
2006 May 06
0
[LLVMdev] Still Trying to Build on MINGW
...m is that Path::isValid() will reject a string containing "<" and ">" on Windows. Note that this is not the case on Unix -- compare the implementation of Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. Probably the right place to make the fix is in ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). As per the comment this constructor is being used to make a "sentry node" in an ilist. In the initializations you will see `path("<invalid>")' which on Windows should be something else (perhaps just use `path("--inv...
2006 May 06
4
[LLVMdev] Still Trying to Build on MINGW
1. I got the tools to build. Yay! 2. I got past all the annoying trouble with not finding header files. Yay! Now I'm having problems with this: llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...> C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: <invalid>: path is not valid I'm investigating this with the debugger and so far I've learned that
2006 May 06
2
[LLVMdev] Still Trying to Build on MINGW
...ct a string containing "<" and ">" on > Windows. > > Note that this is not the case on Unix -- compare the implementation of > Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. > > Probably the right place to make the fix is in > ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). > > As per the comment this constructor is being used to make a "sentry node" > in an ilist. In the initializations you will see `path("<invalid>")' which > on Windows should be something else (perhaps just u...
2006 May 06
2
[LLVMdev] Still Trying to Build on MINGW
..." on >>> Windows. >>> >>> Note that this is not the case on Unix -- compare the implementation of >>> Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. >>> >>> Probably the right place to make the fix is in >>> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >>> >>> As per the comment this constructor is being used to make a "sentry >>> node" >>> in an ilist. In the initializations you will see `path("<invalid>")' >>> which >&...
2006 May 06
0
[LLVMdev] Still Trying to Build on MINGW
...ot;<" and ">" on >> Windows. >> >> Note that this is not the case on Unix -- compare the implementation of >> Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. >> >> Probably the right place to make the fix is in >> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >> >> As per the comment this constructor is being used to make a "sentry node" >> in an ilist. In the initializations you will see `path("<invalid>")' which >> on Windows should be something else...
2006 May 07
0
[LLVMdev] Still Trying to Build on MINGW
...dows. >>>> >>>> Note that this is not the case on Unix -- compare the implementation of >>>> Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc. >>>> >>>> Probably the right place to make the fix is in >>>> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >>>> >>>> As per the comment this constructor is being used to make a "sentry node" >>>> in an ilist. In the initializations you will see `path("<invalid>")' >>>> which &g...
2005 Apr 21
0
[LLVMdev] misc CVS patches
...================================================ >RCS file: /var/cvs/llvm/llvm/lib/Bytecode/Archive/Archive.cpp,v >retrieving revision 1.6 >diff -u -r1.6 Archive.cpp >--- Archive.cpp 28 Jan 2005 01:17:07 -0000 1.6 >+++ Archive.cpp 21 Apr 2005 15:13:24 -0000 >@@ -40,8 +40,8 @@ > ArchiveMember::ArchiveMember() > : next(0), prev(0), parent(0), path("<invalid>"), flags(0), data(0) > { >- info.user = 1000; >- info.group = 1000; >+ info.user = getuid(); >+ info.group = getgid(); > info.mode = 0777; > info.fileSize = 0; > info.modTi...
2006 May 07
1
[LLVMdev] Still Trying to Build on MINGW
...not the case on Unix -- compare the >>>>> implementation of >>>>> Path::isValid() in .../Unix/Path.inc to the one in >>>>> .../Win32/Path.inc. >>>>> >>>>> Probably the right place to make the fix is in >>>>> ArchiveMember::ArchiveMember() (Archive.cpp circa line 43). >>>>> >>>>> As per the comment this constructor is being used to make a >>>>> "sentry node" >>>>> in an ilist. In the initializations you will see >>>>> `path(&quot...
2005 Nov 22
2
[LLVMdev] llvm-ranlib: Bus Error in regressions + fix
...b/libstdc++.so.5 #2 0x4009c818 in std::basic_filebuf<char, std::char_traits<char> >::xsputn(char const*, int) () from /usr/lib/libstdc++.so.5 #3 0x400cbed1 in std::ostream::write(char const*, int) () from /usr/lib/libstdc++.so.5 #4 0x0829c9d0 in llvm::Archive::writeMember(llvm::ArchiveMember const&, std::basic_ofstream<char, std::char_traits<char> >&, bool, bool, bool) ( this=0x8356088, member=@0x8356180, ARFile=@0xbfffd630, CreateSymbolTable=false, TruncateNames=false, ShouldCompress=false) at ArchiveWriter.cpp:294 #5 0x0829d297 in llvm::Archive...
2005 Apr 20
8
[LLVMdev] misc CVS patches
On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >
2005 Nov 22
0
[LLVMdev] llvm-ranlib: Bus Error in regressions + fix
...0x4009c818 in std::basic_filebuf<char, std::char_traits<char> > >::xsputn(char const*, int) () from /usr/lib/libstdc++.so.5 > #3 0x400cbed1 in std::ostream::write(char const*, int) () > from /usr/lib/libstdc++.so.5 > #4 0x0829c9d0 in llvm::Archive::writeMember(llvm::ArchiveMember const&, > std::basic_ofstream<char, std::char_traits<char> >&, bool, bool, bool) ( > this=0x8356088, member=@0x8356180, ARFile=@0xbfffd630, > CreateSymbolTable=false, TruncateNames=false, ShouldCompress=false) > at ArchiveWriter.cpp:294 > #5 0x0829...
2007 Jul 05
2
[LLVMdev] PATCH (rest of code changes) "bytecode" --> "bitcode"
Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached