similar to: SDK

Hi, I've started making an Ogg Vorbis SDK, as per IRC topic instructions :) Some questions: Its just targetting MSVC right? Not borland/whatever? Should it install the headers/libraries in the msvc dir (c:\Program Files\Microsoft Visual Studio\VC98\(Include|Lib)), or should it put them in the same directory as the document (c:\Program Files\Ogg Vorbis SDK\(Include|Lib)), and have the sample

Hello, Thank you very much for quick response. I need only xapian-core. As I wrote on my case compilation with Visual Studio 2015 successful, just I have runtime errors, while the same code on LINUX runs fine. I'll try the hints from (https://trac.xapian.org/browser/git/xapian-core/INSTALL?rev=RELEASE/1.4#L54) and maybe to migrate my project to VS2017 and test it again. If I understand

I am interested in starting a project to port stable versions of OpenSSH to C#, compilable as a stable .Net Library. I was wondering what the list's feelings would be on such a port, if any one else would be interested in such a port, and for any suggestions on raising interest from others to perform such a port. I have nothing against Java and would welcome a similar effort from that arena.

Before I start reinventing the wheel, has anything been done or is there any work ongoing to provide a P/Invoke based interface to parts or all of libFLAC or even a native port of libFLAC to C#/.NET? Regards, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20051221/2b360697/attachment.html

Dear XAPIAN developers, I think your code is devoted also to be compiled on Windows with Microsoft compiler. I think so because 1. There are many #ifdef _MSC_VER like code 2. And if I remember correctly the xapian documentation, xapian has also C# bindings. I need the xapian library for Windows Microsoft compiler. I created visual studio 2015 project and included almost all source

Joe Groff <arcata at gmail.com> writes: >> MSVC is not the system compiler. Certainly, it is not distributed with >> the system. Actually, MSVC was a secondary player on Windows for a long >> time, with several other C++ ABI-incompatible options available. > > > It isn't shipped with the system, but it's freely available as part of the > Windows SDK,

On Thursday, March 28, 2013, Óscar Fuentes wrote: > Chandler Carruth <chandlerc at google.com <javascript:;>> writes: > > >> And here there is no "Windows ABI" here at all. Because every compiler > >> (MSVC, gcc / clang, Borland) does its own stuff. This is why I said > >> that the proposal naming is confusing. > >> > > >

Chandler Carruth <chandlerc at google.com> writes: >> And here there is no "Windows ABI" here at all. Because every compiler >> (MSVC, gcc / clang, Borland) does its own stuff. This is why I said >> that the proposal naming is confusing. >> > > I don't know anything about Borland, and I don't think that matters. But I > think that the

On Jan 11, 2013, at 10:02 AM, <dag at cray.com> wrote: > "Daniels, Marcus G" <mdaniels at lanl.gov> writes: > >> Anyway, I thought the question here amounted to how to ensure that >> people can make binaries of LLVM libraries and a working clang >> executable on Windows. > > No, it's more than that. Many (most?) groups integrate clang

A while back llvm::format() was introduced that made it possible to combine printf-style formatting with llvm streams. However, this still comes with all the risks and pitfalls of printf. Everyone is no-doubt familiar with these problems, but here are just a few anyway: 1. *Not type-safe.* Not all compilers warn when you mess up the format specifier. And when you're writing your own

On Tue, Nov 8, 2011 at 8:02 AM, Don Williamson <don.williamson at yahoo.com> wrote: > > > OK, it's not that bad - it's even better than before :) > > The main issue is RWMutex.inc and the use of PSRWLOCK. This requires _WIN32_WINNT to be >= 0x0600, which is not true for VS2005 SP1. > > Rather than #define _WIN32_WINNT 0x0600 (the file notes that this should

Hi, At the Build conference recently, Microsoft had a session about Windows on ARM(64), [1]. As case example of a large, nontrivial app rebuilt for this arch, they demonstrated VLC. The presentation claimed that this was built with MSVC, with zero changes to the source. This actually isn't true; the app that was demonstrated was actually built with Clang and LLD with mingw-w64 as SDK

Dear all, In the download section of the Speex web site, you can find the Windows DLLs until the 1.2beta2 version, but for the newest version 1.2rc1 there aren?t any available. Therefore, I?m trying to generate the Windows DLLs for the 1.2rc1 version using the MSVC 2005 project files available in the source code. After a lot of problems, finally I have generated the DLLs. However there is a

Hi Oscar, >> MSVC is not the system compiler. Certainly, it is not distributed with > >> the system. Actually, MSVC was a secondary player on Windows for a long > >> time, with several other C++ ABI-incompatible options available. > > > > > > It isn't shipped with the system, but it's freely available as part of > the > > Windows SDK,

So are you saying that LLVM can be built as ARM64 on Windows now? CMake doesn't show me an option for ARM64 when using MSVC on Windows. I have the latest CMake. On Mon, May 21, 2018 at 2:34 AM, Martin Storsjö via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > At the Build conference recently, Microsoft had a session about Windows on > ARM(64), [1]. As case example of

I'm studing wine for my thesis but I've an question: if I can use native dll for an application because are there many builtin dll in usr/lib/wine? I understand for system dll like kernel32.dll, user32.dll etc Thanks.

On Tue, Oct 11, 2016 at 8:59 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > I On Oct 11, 2016, at 6:22 PM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > A while back llvm::format() was introduced that made it possible to > combine printf-style formatting with llvm streams. However, this still > comes with all the risks

Hello Erik, Thank you to work. I have not checked to build them, though, I can tell you some comments, excuse me. * General - Please post patches to cfe-commits and to llvm-commits, too. (IMHO it would not be needed to split articles apart each lists as long as each would be related.) - If you can, please attach files w/o CRLF(dos encodings), or with attached text/plain. - You may

Do your 32768 registers also have sub registers? I can't tell you exactly what to change. I'm not familiar with the code. I would just be running grep or something. ~Craig On Fri, Jul 14, 2017 at 10:23 AM, hameeza ahmed <hahmed2305 at gmail.com> wrote: > Thank you so much. I think there is no issue with my definitions since i > have to use larger registers i.e 65536 bit

I have made changes in 3 files: LaneBitmask.h, codegenregisters.cpp and miparser.cpp. files are attached here. Now i am getting following errors. which means registerinfo.inc file is not generated successfully. /PIM/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:733:24: error: no member named 'XMM8' in namespace 'llvm::X86' if ((RegNo >= X86::XMM8 && RegNo <=