similar to: [patch] Mingw32 and DLLs (updated)

Jean-Marc Valin wrote: ... > I think the amount of Windows crap is getting a bit ridiculous. Does > anyone know of a solution to keep things manageable? I mean, the same > autotools files manage the build for Linux PCs, Blackfins and MacOS (and > others). Yet, we need one set of files for each MS compiler version > (good thing they don't practice "release early, release

Mikael Magnusson wrote: > Jean-Marc Valin wrote: > ... > > I think the amount of Windows crap is getting a bit ridiculous. It always was. I'm just surprised you took so long to realise it :-). > The autotools files can also be used to build Win32 libraries using > mingw32 (preferably cross-compiling on GNU/Linux). It's currently > possible to build static libs. To

Mikael Magnusson writes: > Package: libspeex1 > Version: 1.1.6-1 > Severity: wishlist > > Is there anything that keeps 1.1.6-1 in experimental from being uploaded to > unstable? Do you know when it will happen? > > I'm debianizing iaxclient, which needs speex version 1.1.x. Currently I'm > using 1.1.6-1 in experimental, which is working fine. >

Did you check it against the trunk in SVN? If it's not applied, and you can hook Jean-Marc up with an email address like yours, I'm sure he will get right on it. :) Tom Mihai Balea <mihai@hates.ms> wrote: > > Hi all, > > Did anything happen to this patch? > It seems to me that it fixes a valid issue, but I'm not an expert. > Anyways, I didn't see

On 12/3/07, Erik de Castro Lopo <mle+la@mega-nerd.com> wrote: > I just checked and there is nothing needed in configure.ac. > > In the Makefile.am that creates the shared library you need to add > "-no-undefined" to the LDFLAGS variable like this: > > libspeex_la_LDFLAGS = -no-undefined @WHATEVER_WAS_THERE_BEFORE@ Which symbols will it export? I think default

So I've been looking around for people who have built shared libraries on windows and have run in to a bit of a stumbling block. I'm able to compile without the BUILD_SHARED_LIBS flag but if I put turn the flag on as follows: cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=ON ../llvm-2.7 Then call: mingw32-make I get: ... Linking CXX

Hi, I am using premake4 generated make files to compile my projects, which works fine if I am using mingw32-make.exe from the MinGW 32 bit distribution, but doesn't work with the make.exe supplied by the latest RTools 2.16. That make.exe first complains it can't create directories and then that it has "no rule". So how comes there is no mingw32-make.exe along with RTools? I

Ted, > When I try to run lli hello.bc, I get an unsatisfied DLL link error: "This > application has failed to start because pthreadGC.dll was not found." > Hunting around I can't find this DLL anywhere; where should it have come > from? pthreads are required for LLVM. Easy googling ("pthreads mingw32) returns the following place for dlls download:

Hi Shao, On 2016.02.24 23:43, Shao Miller via Syslinux wrote: > Did you happen to notice anything unusual when compiling with MinGW > under Linux, once 'ok' was removed? I seem to recall warnings about > unused results, but not of unused objects. Maybe that's an incorrect > recollection or maybe it's ancient history, however. I got no warnings with the patch on

I checked it against the latest code in the git repository and it wasn't there. Mihai PS: if JM wants a @hates.ms address, I could prolly hook him up. Especially if he throws in some VAD code that's not "a hack" :) On Nov 5, 2007, at 2:08 PM, Tom Grandgent wrote: > Did you check it against the trunk in SVN? > > If it's not applied, and you can hook Jean-Marc up

On Tue, Mar 1, 2016 at 4:21 PM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > First, I'd like to say it would be great if we could get away from relying > on these globally unique pass IDs represented as addresses of globals. Long > ago I tried to hack up a DLL build of LLVM and quickly discovered that > these IDs are the biggest source of dllimported

I realize that R-core must be busy with the imminent release of 2.11.0, so please consider this not urgent. The NEWS file for 2.12.0 (Windows-specific) says, in part: For now, 32-bit packages with compiled code built under 2.{10,11}.x can be used, but this will be disabled before release. For me, this doesn't work without a tweak. For example, > library(mvtnorm) #Error:

On Thu, May 24, 2012 at 12:53 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > One project I'd like to complete pretty soon is to go through the build > instructions, for mingw32, and see if I can't somehow create a mingw64 > build.  I believe the 32-bit platform is dying by the hour so I'm rather > eager to have a mingw64 version of LLVM/Clang.  Also, I'd love

Hello guys, I'm using llvm 3.3 on windows with mingw (triple: "i386-unknown-mingw32") to compile IR code that my program generates. I do it in two phases: first I emit assembly code and then assemble it. TargetMachine targetMachine = target.createTargetMachine(triple); targetMachine.setAsmVerbosityDefault(true); targetMachine.setFunctionSections(true);

There is a problem in speex_preprocess_ctl. Both speech_prob_start and speech_prob_continue are set to 327.67 for all input values except 0 which results in 0. This is in floating point mode. I think the included patch fixes the problem. Mikael -------------- next part -------------- Index: libspeex/preprocess.c =================================================================== ---

On Sat, Jun 16, 2012 at 3:29 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi Takumi, > > THANK YOU for your excellent review! It makes all the work worthwhile in > itself. > > It is getting "late" here (it is early morning) so I am about to call it a > day. But I will contemplate and incorporate your suggestions tomorrow, and > send you a full

I am having a problem using two DLLs with the same name, but obviously located in different directories, in an R session. The troublesome package is the (Bioconductor) Rgraphviz package. It relies on (3rd party software) graphviz and imports functions from (Bioconductor) package graph. Unfortunately, the current stable release of graphviz for Windows

On Mon, Jun 18, 2012 at 6:25 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi all, > > Here's an updated version of my proposed "Building with MinGW on Windows" > document. In summary, the document gives a step-by-step description of how > to build LLVM + Clang on Windows WITHOUT having Microsoft Visual Studio > installed. The high-level goal of the

Hi, I tried to do a build with CMake, Ninja, and MinGW32 and MinG64 respectively: MinGW32 failed on an missing sys/mman.h (POSIX-specific header): D:/test/llvm-trunk/projects/compiler-rt/lib/enable_execute_stack.c:13:22: fatal error: sys/mman.h: No such file or directory #include <sys/mman.h> ^ MinGW64 failed on an #error directive:

Folks, there is an issue pretty buried in the commits list that I suspect should have wider visibility. See r262188 and subsequent discussion. To summarize: it appears that mingw32 was unable to correctly produce a static data member when instantiated as a base class. The "fix" is to then explicitly instantiate the base class separately from its use in a base class. I think this is