similar to: [LLVMdev] making cygwin nightly builds available?

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

Hello, Reid. You wrote Friday, January 21, 2005, 11:14:41 PM: RS> FYI, work progresses on the Win32 native port which you might also find RS> interesting. It might even get done before the cygwin stuff. Jeff Cohen RS> is working on that. Perhaps he can indicate the status of that effort. There is too much work to do native Win32 builds. I've tried to get llvm compiled on mingw32

Hello, Jeff. You wrote Saturday, April 29, 2006, 10:45:02 PM: JC> Yes, I know mingw doesn't support dbghelp. I can still rant about it :) ;) Well. Maybe this library will be included in some next versions of mingw's win32api package. Anyway, we can make such library just "on-fly" from the corresponding .dll. JC> This is what's already there. What changed? Maybe

Hello, Jeff. You wrote Saturday, April 29, 2006, 7:35:46 PM: JC> Bison 1.875 is known to have problems building LLVM. Please upgrade to JC> a newer version (at least 1.875d). The current version is 2.1. Hmm.. I haven't found any problem building LLVM with that bison. ;) The problem, when ld crashed compiling llc is much more serious. It seems to be linker bug. -- With best regards,

Hello, Jeff. You wrote Saturday, April 29, 2006, 10:50:08 PM: JC> You will. You haven't gotten that far yet. It shows up as a crash JC> running gccas. Ok. Switched to 2.1 JC> As for ld crashing, I have no suggestions. It seems to be bug in bfd/cofflink.c file of libbfd. I can even name the function, where weird thing happens. But it's out of my possibilities to debug this

BTW: I've also had to make this change when building tools. (I'm building right now and noticed that it doesn't come up anymore, maybe someone checked it in in the last week or so) On Sat, 29 Apr 2006, Anton Korobeynikov wrote: > Hello, Jeff. > > You wrote Saturday, April 29, 2006, 10:45:02 PM: > > JC> Yes, I know mingw doesn't support dbghelp. I can still rant

Hello, Reid. You wrote Saturday, February 19, 2005, 6:49:30 AM: RS> i686-pc-cygwin RS> don't know about mingw. i686-pc-mingw32 for mingw. -- With best regards, Anton mailto:asl at math.spbu.ru Saturday, February 19, 2005 9:07:04 AM Faculty of Mathematics & Mechanics, Saint-Petersburg State University

On 8/4/06, Anton Korobeynikov <asl at math.spbu.ru> wrote: > > Hello Anton > > Thu, 3 Aug 2006 23:13:52 +0400 you wrote: > > > I won't be available for the next 10-12 hours if you'll need some more > > files. > Well. I have one idea. Could you please execute "sort --version" from > your cygwin shell and let me know, whether it's GNU one

Hello, Greg. You wrote Saturday, May 6, 2006, 10:24:16 PM: GP> If anyone has any insight I'd love to hear it. GP> Meanwhile, I'll continue to investigate... Currently I'm working on bootstrapping llvm-gcc4 on mingw32 platform. There are some serious miscompartibilities preventing build. I'll let know the results. Anyway, it's common knowledge, that msys itself have

Thanks for the suggestion, Andre. I downloaded GNAT GPL 2007, and followed the directions on your web page. Now I get a lot of C++ errors. In fact, the output I captured to a log file is over six megabytes just from the start of the problem command to the termination of the make. I'm obviously not going to include it all here, but the command and the first few errors are copied below.

I've read that LLVM can convert from C++ to C code. So I've used it in such a way: I'm Windows-user so I used MinGW. I employed this file as the test: llvm-hello.cpp: #include <iostream> int main(int argc, char* argv[]) { system("pause"); return 0; } result of "llvm-g++ C:\llvm_hello.cpp -o C:\llvm_hellopp.exe" worked just fine. as a result of

Hello, Henrik. You wrote Friday, May 13, 2005, 5:52:11 PM: HB> However, me and others will try to help you to compile the cfe. Please HB> submit your compiling errors on this mailing list. I've compiled CFE on cygwin this winter without any problems. I really didn't change anything to let it work. -- With best regards, Anton mailto:asl at math.spbu.ru

Hello, Chuck. You wrote Tuesday, May 16, 2006, 6:03:14 PM: C> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: BFD C> 2.16.91 C> 20050610 assertion fail C> /netrel/src/binutils-20050610-1/bfd/cofflink.c:1926 C> make[2]: *** This is a bug in binutils also seen in mingw32 build. :( I've sent bug report to binutils bugzilla this weekend. Hope, this will be

Hello, Chuck. You wrote Tuesday, May 16, 2006, 6:03:14 PM: C> /netrel/src/binutils-20050610-1/bfd/cofflink.c:1926 C> make[2]: *** I've tracked this assertion some more deep. The problem is in LLVMSelectionDAG.o file. If I run the next lines, I've got and assertion: ld -r -o LLVMSelectionDAG.o ScheduleDAGList.o ScheduleDAGRRList.o ld -o llc LLVMSelectionDAG.o If I remove one of

Hello, Reid. You wrote Tuesday, May 16, 2006, 11:13:19 PM: RS> What does the assertion say? The same text, as in the original e-mail: <=cut=> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: BFD 2.16.91 20050610 assertion fail /netrel/src/binutils-20050610-1/bfd/cofflink.c:1926 <=cut=> This assertions is in big function named: bfd_boolean

Hello, Chuck. You wrote Tuesday, May 16, 2006, 6:03:14 PM: C> I shall skip llc and have another try. The cheap workaround is to use .a files instead of relinked .o. If you want, I can send patch. -- With best regards, Anton mailto:asl at math.spbu.ru Thursday, May 18, 2006 7:22:54 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University

Hello, Everyone. All blackmagic (playing with pwd, etc) in my build description has gone with patched bash (pwd builtin was just hardly disabled). It's not good, I myself prefer modifying libstdc++ configure script to use PWD_CMD environmental variable as main gcc ones. I'm working on this feature. -- With best regards, Anton mailto:asl at math.spbu.ru

I see that some of the system header-file definitions have the internal keyword. For example, define internal void @__cxx_global_var_init() section "__TEXT,__StaticInit,regular,pure_instructions" { entry: call void @_ZNSt8ios_base4InitC1Ev(%"class.std::ios_base::Init"* @_ZStL8__ioinit) %0 = call i32 @__cxa_atexit(void (i8*)* bitcast (void

"Anton Korobeynikov" <asl at math.spbu.ru> writes: >> at all, it would be great if you reflect your changes on the file list >> inside the corresponding CMakeLists.txt when you add, remove or rename >> a .cpp file. > > Isn't is possible for cmake just to glob everything in the corresponding > directory? Yes, but then the build would not notice a

Hi Eric, > llvm-main.o: In function `__static_initialization_and_destruction_0': > /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: > undefi\ > ned reference to `std::ios_base::Init::Init()' > /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: > undefi\ > ned reference to `std::ios_base::Init::~Init()'