similar to: A small build fix for some MinGW toolchains

The Wine development release 5.5 is now available. What's new in this release (see below for details): - Builtin libraries use the new UCRTBase C runtime. - Compatibility mode used when reporting Windows version. - Better support for debug information in PE files. - Support for linguistic case mappings. - More attributes supported in WebServices. - Various bug fixes. The source

The Wine development release 4.5 is now available. What's new in this release (see below for details): - Support for Vulkan 1.1. - Better support for kernel objects in device drivers. - Still more Media Foundation APIs implemented. - Support for SVG elements in MSHTML. - Fixes for case conversion troubles in Turkish locale. - Various bug fixes. The source is available from the

I have been doing some heavy testing with the new FLAC version, and I found that CreateFile function in grabbag had been left out of UTF-8 treatment at some point. This causes re-encoding an existing flac to the same name to break the file if it contains non-ascii characters. Attached patch fixes this. -------------- next part -------------- diff --git a/include/share/win_utf8_io.h

On Aug 14, 2019, at 1:26 PM, Timo Sirainen via dovecot <dovecot at dovecot.org> wrote: > > It probably has something to do with using mbox format. Are the IMAP UIDs changing unexpectedly? Errors/warnings logged related to it? Unfortunately it's a rather troublesome mailbox format. There are likely some bugs in Dovecot mbox code, but it's difficult and time consuming to try to

In order to minimize edit/compile/debug turn time, is there a way to compile llvm tools so that the majority of the files are compiled as if for release (eg, no debug symbols), and only the handful of files that I have touched are compiled for debugging? This will reduce the load on the file system, linker and gdb tremendously. At present, AFAICT, it's all or nothing. -------------- next part

On Tue, Aug 13, 2019 at 03:26:17PM +0200, Christoph Hellwig wrote: > On Mon, Aug 12, 2019 at 07:51:56PM +1000, David Gibson wrote: > > AFAICT we already kind of abuse this for the VIRTIO_F_IOMMU_PLATFORM, > > because to handle for cases where it *is* a device limitation, we > > assume that if the hypervisor presents VIRTIO_F_IOMMU_PLATFORM then > > the guest *must*

On 14 Aug 2019, at 22.35, Amir Caspi via dovecot <dovecot at dovecot.org> wrote: > > On Aug 14, 2019, at 1:26 PM, Timo Sirainen via dovecot <dovecot at dovecot.org <mailto:dovecot at dovecot.org>> wrote: >> >> It probably has something to do with using mbox format. Are the IMAP UIDs changing unexpectedly? Errors/warnings logged related to it? Unfortunately

Hi, I have a doubt regarding *getAnalysisUsage.* My assumption is that, as analysis passes will not change the IR, all the passes required by an analysis pass should be preserved. Say, I have an analysis pass which requires another analysis pass called *SomeAnalysis* and I have not added *AU.addPreserved<SomeAnalysis>() *to my pass. Would the pass manager still considers the *SomeAnlaysis

Hello, I am currently trying to connect my Dovecot mail server to Microsoft's Azure-AD and use it as password and user database. I am using version 2.3.7.1. Using the Azure-AD as passdb already works. In this context I noticed that the scope implementation is not yet merged. Since I haven't found any hints for an OAuth2 userdb implementation yet, I wanted to ask if there are any plans

Just ran into the same problem, but with `-DLLVM_BUILD_TOOLS=ON` since the tools link against shlib and use the C++ interface I can't use Cosmin's solution. I managed to get through with using `RelWithDebInfo` instead of `Debug` On Sat, Jun 22, 2019 at 5:20 AM Cosmin Apreutesei via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Update: looks like the the problem was that the

We have a customer where their VM running Asterisk appears to have crashed. Fortunately, we had some debugging enabled. The asterisk messages file has this... (in notepad+ the blank line in the middle is all [NUL][NUL] [NUL][NUL]....) [08/12 15:30:55.880] VERBOSE[6920] app_mixmonitor.c: Begin MixMonitor Recording CBRec/IS__a37ae004-c780-4c7f-88a9-a04402f0ab4e-0000e70f [08/12 15:30:55.881]

Hi, I gotta ask you - brew doesn't build latest llvm on Mavericks so i got binaries but 4.0.1 from brew has also toolchains and from what i can see it's just a matter of a directory with llvm's dirs copied and having Info.plist, is that so simple to make Toolchains out of llvm binaries? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL:

Kenia Kuo <kenkillerkuo at gmail.com> writes: [snip] > Currently, I tried the toolchains of ARM and PowerPC that have the > different versions of libraries, obviously the generated bitcode are > different. > So I wonder whether the version of library is the only reason why the > generated bitcode are different.

The MinGW-w64 project, whose toolchains we use for 64-bit Windows, have made some changes to their conventions *and* removed all the older binary builds from their site. The current toolchains are not suitable for use with R 2.11.x, and I've re-packaged an older version (which is) as http://www.stats.ox.ac.uk/pub/Rtools/oldWin64toolchain.zip The most critical change is to no longer have

Hi David, Thank you for your reply. In fact, my question originally came from the google native client. I thought that the bitcode can be shared among the different targets as it inherently is. Therefore, I used the clang to generate the bitcode to prove that my thought is right, and I supposed that the different bitcode caused from the different versions of libraries before. Thanks for the

Hi Óscar, Thank you for your reply. It looks like the limitations are the platform's API and ABI (included the size of variable). So, if there are two platforms that have the same API, ABI but different ISAs, the bitcode can be shared. Can I say that? Thanks, Kenia Kuo 2012/9/25 Óscar Fuentes <ofv at wanadoo.es> > Kenia Kuo <kenkillerkuo at gmail.com> writes: > >

Hi all, I'm currently working on the implementation for LLVM of the RISCV Bit Manipulation ISA extension described by Clifford Wolf in the following presentation: https://content.riscv.org/wp-content/uploads/2019/06/17.10-b_wolf.pdf and the following document: https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-0.90.pdf The aim is to provide the intrinsic functions to the user in

The Wine maintenance release 5.0.2 is now available. What's new in this release (see below for details): - Various bug fixes The source is available from the following locations: https://dl.winehq.org/wine/source/5.0/wine-5.0.2.tar.xz http://mirrors.ibiblio.org/wine/source/5.0/wine-5.0.2.tar.xz Binary packages for various distributions will be available from:

Hi, I'm using clang to build my project as follows: $ clang++ -ccc-host-triple arm-none-linux-gnueabi --sysroot=/usr/local/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc/ -o foo.o -emit-llvm -c foo.cpp $ clang++ -ccc-host-triple arm-none-linux-gnueabi --sysroot=/usr/local/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc/ -o main.o -emit-llvm -c main.cpp $ llvm-link foo.o main.o -o

The Wine development release 5.6 is now available. What's new in this release (see below for details): - Still more Media Foundation work. - Improvements to Active Directory LDAP support. - A few more modules converted to PE. - Improvements to gdb proxy mode. - Various bug fixes. The source is available from the following locations: