similar to: NameNumericTail

Sorry, spoke too quickly! The problem was caused by my editing the MkRules file with an editor that replaces tabs with spaces. Make evidently requires that all lines start with a tab (see http://www.delorie.com/djgpp/v2faq/faq22_17.html). Perhaps worth warning windoze users like myself of such perils in readme.packages or somewhere similar! Now I have a new problem, but it looks fixable.

Hi. Here are my patches and makefiles for compiling ogg, vorbis and vorbis-tools on DOS with DJGPP. They can build them from cvs snapshots and need minimal maintainance (even extract source lists from `makefile.am's). Everything seems to work, except one FP exception on encode at middle bitrates (lowest two and highest bitrates don't cause it) - I don't think it's my

Attached patch adds support nasm coff obj format for djgpp -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-support-nasm-coff-obj-format-for-djgpp.patch Type: application/octet-stream Size: 1227 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20170113/8c51e0dc/attachment.obj>

Attached patch works around for DJGPP missing wcswidth() in flac/utils.c:strlen_console() -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-flac-utils.c-strlen_console-workaround-for-DJGPP-mis.patch Type: application/octet-stream Size: 683 bytes Desc: not available URL:

I'm wondering if there is anyone who might be interested in working with this guy to get the djgpp cross-compiler into the Fedora repos? https://groups.google.com/forum/m/#!topic/comp.os.msdos.djgpp/8gp0LtLY6DI -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Hi Alex, After outlining some of the rationale for using native-wrapped, there were a couple of responses that indicated native-wrapped support was reasonable, but they preferred to see bitcode-only first (Phillip and Rafael). This is essentially what this proposal and the patches do - I've implemented some of the basic support for looking for and parsing the native-wrapped sections, but the

Several folks have previously written that valgrind notices a memory leak in R's readline code. It looks like it leaks a copy of every input line. % ~/R-svn/r-devel/R/bin/R --debugger=valgrind --debugger-args=--leak-check=full --vanilla ==10725== Memcheck, a memory error detector. ==10725== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==10725== Using LibVEX rev 1658, a

GPM Modula-2 and Oberon-2 Compilers File locations: ftp.fit.qut.edu.au:/pub/gpm ftp.psg.com:/pub/modula-2/gpm WEB Site: http://www.fit.qut.edu.au/CompSci/PLAS/GPM/ The Gardens Point Modula (GPM) compilers are an ongoing development project for the Programming Languages and Systems Group in the Faculty of Information Technology at the Queensland University of Technology.

On 12/2/2011 9:09 AM, Alan Garny wrote: > > However, there is one new (minor) issue which is that when building my > application I get a warning from the linker about auto-importing > having been activated without --enable-auto-import being specified on > the command line. Indeed, for some reason, the vtable for > llvm::CallInst has to be resolved...?! This is clearly not

unsigned int and FLAC__uint32 are used interchangeably, leading to warnings with platforms (e.g. djgpp) where int32_t is long: bitreader.c: In function `FLAC__bitreader_read_rice_signed': bitreader.c:721: warning: passing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer type bitreader.c: In function `FLAC__bitreader_read_rice_signed_block': bitreader.c:850:

On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> warnings with platforms (e.g. djgpp) where int32_t is long: > > Is `sizeof int == 4` though? Yes, obviously it is > I couldn't image FLAC working correctly > if it wasn't. > > Erik

Hello, I develop some R package on Linux machine with C subroutines. The programs in C are well compiled on Linux machine and so I have some ".so" files. Now, I want to do the same work on windows, so I install R (the last version) on windows, with Active Perl and djgpp, which is, as I know, the gcc version for windows (to compile C program), but unfortunately when I run "R CMD

As discussed in the high-level ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), we would like to add support for native object wrapped bitcode and ThinLTO information. Based on comments on the mailing list, I am adding support for ThinLTO in both normal bitcode files, as well as native-object wrapped bitcode. The following RFC describes the planned file format of

What was used to compile the syslinux win32 binary? I tried djgpp but no luck. Think it's choking on the windows.h header. Can somebody help me out. Guessing a combo of cygwin and mingw but gonna try and get a word before I bang my head against the wall. -andy

Hello, somewhere on one of the rsync webpages I have seen a list of hosts which have running public rsync services, at least I think it has been on the rsync webpages, but I can't find it there anymore. Or is it anywhere else? Where can this list of rsync hosts be placed? I appreciate your feedback. Have a nice day Michael -- Michael Schmidt mschmidt@fh-koblenz.de MIRROR OF:

Hello, just being fascinated by rsync I wanted to look at the distribution files at ftp://rsync.samba.org, but it was not possible to get a ftp connection to that address. Is the ftp service down there? Thanks in advance for any soon helpful hint. Have a nice day Michael -- Michael Schmidt mschmidt@fh-koblenz.de MIRROR OF Ghostscript * X-Windows X11

Hello SYSLINUX, I have been searching for a resource for the "Disk error" messages coming out of isolinux. I am seeing the message "isolinux: Disk error 20, AX=425 c, drive EF" on many occasions where a combination of questionable Linux OS media comes in contact with touchy LITE-ON DVD/RW Drives attempting to load Red Hat Linux. We know that changing the Drive or

I have made available the work of the last weekend that I mentioned in my previous messages on ftp://sirio.stat.unipd.it/pub/R. Many thanks to Peter D. and Ross I. for their suggestions. If you think that the work is of some interest, I can upload it to CRAN. guido m. This is the README enclosed in the distribution. -------------------------------------------------------------------------

I downloaded `file' for djgpp, and it verbosly identified my mp3 by bitrate, sample rate, mono/stereo, option bits, etc. WAVs are also uidentified well. Only vorbis was identified simply as "Ogg-Vorbis compressed sound file" without any info. So I decided I must fix this to replace my aliases that use `od' to read the bitrate and number of channels. Here is the result

- Replaced blanket #define of 8 & 64 bit types with typedefs for each platform to match 16 & 32 bit types. - Updated existing typedefs for each platform to fix odd values and improve consistency. --- include/opus_types.h | 125 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 100 insertions(+), 25 deletions(-) diff --git a/include/opus_types.h