similar to: Borland Builder

The following block in os.h needs to be changed for vorbis to work under Borland: Original: #ifndef __GNUC__ #ifdef _WIN32 # define alloca(x) (_alloca(x)) # define rint(x) (floor((x)+0.5)) #endif #endif New: #ifndef __GNUC__ #ifdef _WIN32 # ifdef __BORLANDC__ # include <malloc.h> # else # define alloca(x) (_alloca(x)) # endif # define rint(x) (floor((x)+0.5)) #endif

I'm trying to link against libvorbis.a using GnuWin32 without the Cygwin layer (that is, Mingw32). Unfortunately the linker complains about a missing function: rint(). This function is used a couple of times in libvorbis and as far as I understand this is a standard C library function. My problem is, that I cannot find rint() in any of the common DLLs nor do I know how MSVC resolves this

Why does the source use `int64_t'. Is this suppose to be built with GCC? I have Mumit Kahns gcc, version 2.8.1. Do I need a 2.9.5 version to get the `int64_t' type? I have substituted a typedef of `long long' in os_types.h. This seems to make sense? The rint() macro also seems to be having some problems. I guess there are two meanings to __GNUC__ and _WIN32. One is the OS and

I am a mingw coder and I needed to make the following changes to the CVS source from 9/13/00 to get a build: os_types.h L36C16 reads had to change "unsigned _G_int32_t" to "_G_uint32_t" to resolve the compile error: ..\include\vorbis\os_types.h:36:parse error before 'ogg_uint32_t' ..\include\vorbis\os_types.h:36:warning:data definition has no type or storage class

Hello, I recently attempted to build theora 1.1.1 with mingw-w64-gcc 7.1 and msys and it fails to build the encoder_example.c example program. There are multiple declarations of the function 'rint'. The source file created its own version of the function that rounds AWAY from zero. MinGW-W64 has its own version of the 'rint' function, which does not round away from zero.

>Win95. Unfortunately, the encoder_example segfaults. I get the same >results from Cygwin as well. Problem solved! (Or rather, worked around...) The problem with the segfault appears to have indeed been with alloca. There is a function _alloca in libgcc.a that comes with the mingw32 distribution of gcc-2.95.2. After examining the generated assembly code from envelope.c (and others),

Hello Monty, I tried to complile vorbis under win32 (using MS Visual C 5.0) I found some things: 1.) In bitvise.c there must be buffer cleared after malloc: void _oggpack_writeinit(oggpack_buffer *b){ memset(b,0,sizeof(oggpack_buffer)); b->ptr=b->buffer=malloc(BUFFER_INCREMENT); + memset(b->ptr,0,BUFFER_INCREMENT); b->storage=BUFFER_INCREMENT; } void

Hello Monty, I tried to complile vorbis under win32 (using MS Visual C 5.0) I found some things: 1.) In bitvise.c there must be buffer cleared after malloc: void _oggpack_writeinit(oggpack_buffer *b){ memset(b,0,sizeof(oggpack_buffer)); b->ptr=b->buffer=malloc(BUFFER_INCREMENT); + memset(b->ptr,0,BUFFER_INCREMENT); b->storage=BUFFER_INCREMENT; } void

Hello, I believe llvm.rint description in LangRef is not quite complete. Llvm seems to map math.h:rint() call to llvm.rint intrinsic, and the LangRef says that the result of llvm.rint matches the result of libm rint() call. Next, LangRef states that llvm.rint "returns the operand rounded to the nearest integer." Shouldn't the specification also say that "the actual rounding

Hi Cameron, Thank you for the comments, but I am confused even more now ☺ > llvm.rint won't honor the FPEnv in all cases. It falls under the default FPEnv The default FPEnv section specifies round-to-nearest rounding mode. In this case, how is it correct to map rint() user call to llvm.rint intrinsic call? If this is just a temporary inconsistency, and the long term solution is to map

This is also pretty simple. Just a small patch to configure.in to set the right compiler flags and changes to os.h to (a) not have deeply nested ifdefs, making the file needlessly hard to read, (b) break up the sections by functionality and (c) don't assume that every non-Win32 has the floating versions of math library functions. -tim Index: configure.in

Dear Friends. I found something very puzzling with constOptim(). When I change the parameters for ConstrOptim, the error messages do not seem to be consistent with each other: > constrOptim(c(0.5,0.3,0.5), f=fit.error, gr=fit.error.grr, ui=ui,ci=ci) Error in constrOptim(c(0.5, 0.3, 0.5), f = fit.error, gr = fit.error.grr, : initial value not feasible > constrOptim(c(0.5,0.9,0.5),

----- Original Message ----- > > On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter < > schnetter at cct.lsu.edu > wrote: > > > > > > > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed < david.tweed at arm.com > > wrote: > > > > > > > | LLVM does not currently have special lowering handling for round(), > | and >

On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote: > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > >> | LLVM does not currently have special lowering handling for round(), and >> I'll propose a patch to add that, but the larger question is this: should >> fast-math change the tie-breaking

Hello, all! My program is written on Borland C Builder 6 Not properly method TForm-> Show () works; And on operational system Ubunto 10.10 it works properly, and already in Ubuntu 11.10 method TForm-> Show () works not properly. Elements of a window receive focus of input from the keyboard, and the window remains not active! The heading of a window and is not painted in color of an active

Hi! I'm new to winelib. I'm trying to port a Borland C++ Builder 6.0 application, but I need VCL library: vcl.h. Any ideas?? I would want to make it run natively on Linux. The code is as follows: //--------------------------------------------------------------------------- #include <vcl.h> #pragma hdrstop USEFORM("textS.cpp", TextStuff); USEFORM("aboutS.cpp",

mikolajz wrote: > Winelib allows you to compile a Win32 application > to an ELF binary that can be run directly on Linux > (provided the winelib is installed). Not so. The ELF binary must be run via wine-preloader. In other words, it's really no more convenient than using wine on a win32 binary. - Dan

N?stor Amigo Cairo wrote: > So I will need to rewrite the application to run on Linux, but this > sounds strange, doesn't it?? I have not completely understood then the > purpose of winelib. Do you mean that it is not possible to build an > application from source (written using Win32 API) using gcc on Linux > and executing it natively?? Correct. You can't run it directly

hello, I try to include the speex header to a bcb project. Speex headers are the latest one. My first problem was to use the lib file with bcb. I solved this issue by restructing the lib file. The second problem is to access the constant called "extern const SpeexMode speex_nb_mode;" through borland's c++ builder. I could analyze the export table of the libspeex.dll. Unfortunately I

N?stor Amigo Cairo wrote: > Hi! > > I'm new to winelib. I'm trying to port a Borland C++ Builder 6.0 > application, but I need VCL library: vcl.h. > > Any ideas?? I would want to make it run natively on Linux. You can't. Winelib still requires Wine to run it. It's a library not an executable. If you want to write native Linux application that can run by itself