similar to: some portability fixes ...

The underscores are wrong. The comment is also correct. Also remove the configure.ac option. Otherwise it tries to compile the windows unicode stuff which POSIX(cygwin) does not understand. --- configure.ac | 2 +- include/share/compat.h | 2 +- src/libFLAC/stream_decoder.c | 3 --- src/libFLAC/stream_encoder.c | 3 --- src/share/grabbag/file.c | 8 +------- 5 files

On 19/02/02 18:09, Likai Liu shaped the electrons to say: > >It's partially done in the patch I've sent you, completelly done in my > >current version... I can send you the second patch, you will save some > > work. > > how is the calculation being done? do you extract the bitrate from the > stream data, or do you use a different method? I'd advocate *that*

Hi I found a small Bug when compiling OpenSSH under Win32 using Cygwin. When you use SSH as a interactive Shell everthing looks normal but when you try to transfer binary data via SSH you will get only garbage. Example: ssh -l root -i ./.ssh/identity server1 cat /tmp/test.tar.gz > c:\test.tar.gz The problem is that stdout is opend as Text-File so every LF which

On 19/02/02 23:09, Likai Liu shaped the electrons to say: > Ricardo Galli wrote: > >By assigning a timestamp to each packet read from the source socket. I > > think the only sane way to do it. > > great idea. with this implementation, actually you can set a smaller > buffer size, but wait a longer time for recovery. once congestion is > clear, previous "missed"

Hi, attached is a patch which solves the following problem: Sometimes scp could hang in Cygwin when used as remote end using the -t option. This is due to a binmode/textmode problem which could be raised by the login shell which is used by the user and it's setting of textmode on stdin. The patch solves that problem by explicitly setting binmode on stdin. Besides solving the hanging

You might want to fix this: diff -x CVS -uwrN ../OggVorbis.clean/vorbis-tools/oggenc/platform.c ./vorbis-tools/oggenc/platform.c --- ../OggVorbis.clean/vorbis-tools/oggenc/platform.c Thu Feb 1 01:25:36 2001 +++ ./vorbis-tools/oggenc/platform.c Thu Feb 1 01:23:08 2001 @@ -52,7 +58,7 @@ } #endif -#ifdef __WATCOMC__ || __BORLANDC__ +#if defined(__WATCOMC__) || defined(__BORLANDC__) void

Some libcs like uClibc-ng can optionally disable deprecated functions. utime is one of them. When done so, both the header and the function go missing. This fixes flac_utime to work in such a situation. --- include/share/compat.h | 10 +++++++++- src/libFLAC/metadata_iterators.c | 9 +++++++-- src/share/grabbag/file.c | 9 +++++++-- 3 files changed, 23 insertions(+), 5

I don't know if anyone would be interested in this but I'm including a patch to allow for offsets when transferring files with SCP. It's pretty simple and assumes the user knows what they are doing (for example, if transferring with a wild card the offset would apply to all files). -A is the number of bytes offset from the beginning of the files. -Z is the number of bytes inset

I have to compile icecast-1.3.11 under Win32, and want to apply the patch of Li-Kai Liu: http://www.xiph.org/archives/icecast-dev/0066.html But I could not find the "win32config.h" file. I installed Subversion to grab the repository but I didn't find it either. Does anybody have this file and would like to send me? Peter -- "Sie haben neue Mails!" - Die GMX Toolbar

sorry folks, i should have done this properly the first time i post my changes. the attachment contains a gzipped version of unified recursive diff ... this diff is made between a fresh cvs copy of icecast 1.3.11 and the source branch of icecast 1.3.11-mingw that i have. some things are missing, but don't worry about that. i'm not going to explain why individual files present in one

Hello, I'm trying to use LLVM on Windows, using the MinGW toolchain that comes with Cygwin (gcc -mno-cygwin, not the standalone msys package). Has anyone successfully built LLVM from sources with this toolchain? The ./configure scripts automatically detects a Cygwin environment. I've spent some time trying to let it know that it should compile for MinGW. FWIW, here's what I've

Greetings. I have an image I've created with a bunch of chost flags which works on my machine when it comes to native boot. if I take that same image into a vm managed via libvirt, I get kernel panic. I'd assume that something is missing from my vm config, question is what and what I can do about it? here is the flags part of lscpu in native and vm: https://dpaste.com/3TR8QJ5G8 and the

Dixi quod? >Builtins work fine, calling external programmes does >not. It seems to hang in jobs.c:j_waitj() and sending >it SIGCHLD seems to not trigger jobs.c:j_sigchld() >at all. This is probably some kind of signals being >not delivered correctly ? see here for a bug with the >same symptoms: http://dev.haiku-os.org/ticket/5567 >http://dev.haiku-os.org/changeset/35836 >

On Tue, Nov 17, 2020 at 11:32:29AM +0100, daggs wrote: >Greetings. > >I have an image I've created with a bunch of chost flags which works on my machine when it comes to native boot. >if I take that same image into a vm managed via libvirt, I get kernel panic. >I'd assume that something is missing from my vm config, question is what and what I can do about it? >here is

Hello, Thanks to recent changes in the SVN, I was able to successfully build LLVM under Windows in the following environments: 1. Cygwin; 2. MinGW/MSYS; 3. "gcc -mno-cygwin" (a.k.a MinGW on Cygwin). For 3., I've had to make a few manual changes to the build system. Care is needed because non-Cygwin external commands require Windows paths and Cygwin's make does not like path

Thank you all. It looks like -mno-red-zone flag is already in master branch since commit 7d70885d, but it seems it is applied to all EFI builds. IIUC, the problem only affects efi64 builds. So here's the modification of my patch to only apply -mno-red-zone flag to efi64 target. The patch is against master. I verified that it builds correctly in master. Please feel free to accept or reject

When trying to compile R on Windows 10 64-bit using LTO as I always do, I encountered a segmentation fault early in the compilation. I am uncertain as to what it means (please see below for error extract). I am using the most recent version of Rtools43 (5863) and updated its libraries prior to starting the build. My EOPTS is " -march=native -pipe -mno-rtm" and my

On Thu, 14 Dec 2000 10:06:39 +1100, Michael Smith wrote: >>I've done a port for OS/2 using Watcom C++, including a simple command line >>player based on vorbisfile_example.c, which can be downloaded from >>http://silk.apana.org.au/utils.html >>It'd be nice if my changes could be commited to CVS, should I just post >>patches here? > >Yes, unless

Hi all, I was just trying to build myself a RC3 set of Ogg/Vorbis libs and tools, but the build of libvorbis bombs out on me while making all in examples. I've ./configure'd with no options, which gave no warnings or errors. After that a normal make gives the below attached output. Can anyone tell me what I've done wrong ? I've also tried removing the examples/ directory. After

jaromil wrote: >sorry if i'm quoting myself, but i feel i could have reported more > >i'm thinking about using this library: http://xmlrpc-c.sourceforge.net/ >which features the infrastructure of a solid http daemon (abyss, on top >of w3c-libwww library) for running a xml-rpc server accepting registered >function calls. > as icecast already has its own http parser