similar to: [LLVMdev] VS build is broken again

Dmitri Makarov <nebraskin at yahoo.com> writes: >> Is it reasonable to ask > > Yes, it's reasonable. Since this is open source we depend on contributions from the community, etc... You know how the song goes. Seriously, I'll like to see a healthy MSVS build as much as you, but someone must do the work. > Moreover, I'd be content with a build system that

On May 17, 2008, at 2:44 PM, Óscar Fuentes wrote: > I don't know how much LLVM build system is tied to the GNU toolchain > or > how much it depends on *nix features, but suppossing that adding > support > for MSVC++ is impractical, perhaps it would be simpler to implement a > Makefile-based build system for MSVC++ than to keep up to date the > project files. This would

SimplifyLibCalls.cpp is no longer part of Transforms\IPO and Transforms\Scalar\SimplifyCFG.cpp is renamed to SimplifyCFG.cpp or something to that effect ( I didn't look up the actual checkins ). Having fixed that, I still can't get through the build: Creating library C:\work\s\llvm\win32\\bin\Win32\Debug/opt.lib and object C:\work\s\llvm\win32\\bin\Win32\Debug/opt.exp 1>opt.obj : error

I'm building llvm in MSVS 2008. LoopUnroll.cpp includes UnrollLoop.h line 23: #include "llvm/Transforms/Utils/UnrollLoop.h" but there's no UnrollLoop.h anywhere to be found. My svn tree is synced to TOT. What am I missing?

If you look at an .sln file, there's a long sequence of digits associated with every project, something like this 8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942. For the lack of a better word I called it "encoding". After I changed the dependencies between projects in the solution, msvs replaced those numeric sequences by new ones literally for every project in the solution file. The diff now

Hi Dmitri, I know what you are saying, but in the end I think we are lucky if diffs against project files have any meaningful information. Nobody right now assumes responsibility for regularly updating the VS files, so we routinely get patches from different people when they decide to upgrade the project files, and these patches change the .sln files in arbitrary ways. If you have

Ted, Thanks for taking care of this. I found that in order to build clang (in addition to the vcproj changes I posted earlier today) I had to add a dependency such that the clangDriver project depends on the CodeGen (basically the CodeGen checkbox has to be checked in the list of the clangDriver's dependencies). This in effect adds codegen.lib to the list of libraries linked into clang.exe

On May 17, 2008, at 11:51 PM, Dmitri Makarov wrote: > This in effect adds codegen.lib to the > list of libraries linked into clang.exe and solves all the unresolved > symbol errors in the clang build. I would submit the diff, but it > looks like visual studio changes all the encodings of projects in the > .sln file, so the diff includes a lot of irrelevant lines. Changes all the

attached is the diff of vcprojs that need to be changed to fix the VS build as of revision: 51224. I don't know if this catches all the missing bits, but this does build all the way through. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvs.patch URL:

Ted, Attached is the diff against TOT. It makes the VS build work for me. Solution/project files work with VS 2005. Project files in clang need not to be modified. As it happens, the solution file for clang is part of the llvm tree ( go figure... ) Thanks Dmitri --- Ted Kremenek <kremenek at apple.com> wrote: > Hi Dmitri, > > I know what you are saying, but in the end I

On Sunday 18 May 2008, Óscar Fuentes wrote: > Chris Lattner <sabre at nondot.org> writes: > > [snip] > > > Others have suggested alternative build systems before like cmake. > > Apparently cmake can autogenerate VC++ and Xcode project files from > > the same thing that it builds from on unix systems. > > cmake creating VC++ project files does not appeal

Hi Dmitri, For what version of VS did you update the project files? Ted On May 17, 2008, at 3:00 PM, Dmitri Makarov wrote: > attached is the diff of vcprojs that need to be changed to fix the VS > build as of revision: 51224. > > I don't know if this catches all the missing bits, but this does build > all the way through. > > > Index: win32/Analysis/Analysis.vcproj

AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) back. We need to stop supporting this host platform. I'm aware of essentially 2 reasonably important use cases for supporting MinGW + win32threads: 1) Sane host toolchain on Windows that doesn't require downloading MSVC. (I'm dubious about the value of this one...) 2) Cross-compiling a Windows clang.exe (and

Cyrille Berger wrote: > On Sunday 18 May 2008, Óscar Fuentes wrote: >> Chris Lattner <sabre at nondot.org> writes: >> >> [snip] >> >>> Others have suggested alternative build systems before like cmake. >>> Apparently cmake can autogenerate VC++ and Xcode project files from >>> the same thing that it builds from on unix systems. >>

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > How does updating the CMake produced VC++ project files work ? > I mean: > > -I have CMake produce VC++ project files > -Compile the solution > -Do a svn update and pick up a couple of files > -Have CMake produce new project files > -Now, do I have to rebuild the entire solution again ? AFAIK, it should do the right

On a fresh installation of XCP 1.6 there is no interface in XCP Network Management. While in comman line ifconfig -a shows me both physical interfaces. I would appreciate for an ideas on what. -- Best regards, Makarov Alexey _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users

https://bugzilla.mindrot.org/show_bug.cgi?id=1998 Bug #: 1998 Summary: Arbitrary command execution using SCP Classification: Unclassified Product: Portable OpenSSH Version: 5.8p1 Platform: All OS/Version: Linux Status: NEW Severity: security Priority: P2 Component: scp AssignedTo:

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".

Many thanks to the 23 people who took the time to respond to the survey. It really will help me spend my time more effectively. As promised, here are the results. I have inserted some comments inside [brackets]. 1. Have you downloaded wxRuby? YES 19 NO 4 2. Have you successfully built wxRuby? YES 14 NO 8 [We really need binary downloads so people don''t have to build anything.

With current settings, MSVS links debug version of flac.exe (and other .exe and .dll files) with the release version of libogg_static.lib. MSVS issues a "warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library" What's the reason in this setting? What is better: * to change the settings so that MSVS will link debug .exe files with