similar to: setlinebuf vs. setvbuf: Caldera OpenUNIX8.

Hi, in configure.in the patch for `setvbuf' is missing while in sftp-int.c the HAVE_SETVBUF define is used: Index: configure.in =================================================================== RCS file: /cvs/openssh_cvs/configure.in,v retrieving revision 1.286 diff -u -p -r1.286 configure.in --- configure.in 2001/05/17 03:32:51 1.286 +++ configure.in 2001/05/22 11:59:54 @@ -460,7 +460,7

dash didn't compile in DEBUG mode against klibc for all long time. Now it fails at link stage for not having setlinebuf(3). Fixes: usr/dash/show.o: In function `opentrace': show.c:(.text+0x86): undefined reference to `setlinebuf' Signed-off-by: maximilian attems <max at stro.at> --- the last open error, looks more like a klibc bug to me, will fix it

Erik de Castro Lopo wrote: > lvqcl, > > Would you be able to have alook at this one? I think its > Windows related: > > https://sourceforge.net/p/flac/feature-requests/114/ > The relevant changes are <http://git.xiph.org/?p=flac.git;a=commitdiff;h=6a6207b52a86b1d7980a5233e297c0fc948bed7d> and

Martijn van Beurden <mvanb1 at gmail.com> ?????(?) ? ????? ?????? Wed, 24 Sep 2014 16:09:38 +0400: > Well, from the code it's clear that quite some effort was put > into making libFLAC usable on platforms that have no FPU, as > there is a integer-only define that actually works. I could > think of small handheld recorders like the Zoom H1 or something > like that to use

Hello, I'm trying samba-2.0.6 on my Sony NEWS-OS 4.2.1aRD which is based on 4.3BSD, having trouble with compilation. Also I have question and want be helped to solve the problem. Yes, I can compile it with dirty hack which is found at ftp://ftp.tutrp.tut.ac.jp/pub/sony-news/samba/samba-news4.diff There are some problems about this old and specific system. 1. It does not have setvbuf(). 2.

Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently memory usage of FLAC decoding is about 1MB, so this patch is increasing memory usage tenfold, also for platforms that do not need this. It is a non-problem on my system anyway. Op 26-09-14 om 10:36 schreef Janne Hyv?rinen: > I made some changes to the previous patch. I don't know why I > originally didn't put the

I have been running a lot of large compression tests to see how well Martijn van Beurden's new presets do and was once again reminded how real the fragmentation problem still is. To have decent speed it's necessary to run multiple encoders in parallel. In my setup FLAC was compressing four files at the same time and each instance writes tiny bits of data to disk at once. A

Decoding flac files is also prone to producing fragmented files. NTFS has the ability to completely avoid fragmentation if it is told the file size before hand, but that would require using special Windows-only functions. Increasing the write buffer from the default 512 bytes to 10 MB already reduces the problem tremendously. -------------- next part -------------- diff --git

When I try to start X, I get the following. Any help here? I track stable via cvsup, sup'd on 4/29/03, and cvs up the system having problems, which is running FreeBSD 4.8-STABLE /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol "__stderrp" objdump -r /usr/lib/libm.so.2 show the symbol __stderrp. What library resolves that and why is it not defined? Daryl Spartz

dash didn't compile in DEBUG mode against klibc for all long time. Now it only fails at link stage for not having setlinebuf(3) and freopen(3). Fixes: usr/dash/show.o: In function `opentrace': show.c:(.text+0x36): undefined reference to `freopen' show.c:(.text+0x86): undefined reference to `setlinebuf' Skip setlinebuf and use fclose/fopen inside SMALL. Signed-off-by: maximilian

On 12/10/2015 5:58 PM, lvqcl wrote: > Erik de Castro Lopo wrote: >> lvqcl, >> >> Would you be able to have alook at this one? I think its >> Windows related: >> >> https://sourceforge.net/p/flac/feature-requests/114/ >> > > The relevant changes are >

Hi Folks: I used that one example for AGI script on C web, only to fill the working with the Asterisk. I compiled and it worked great. I executed accidentally the ls -l command in directory where was the source and executable, I noted and was surprised that because the executable size was to further 20 times more than source. I executed the gcc -Os source.c -o executable.agi command several

[It seems the last time this came up was in march, under the heading of "Sony Cybershot should be in hardware notes". This message is intended mainly to document what I've managed to track down.] The m500s still will not sync with pilot-link 0.11.7 in -STABLE. An easily triggerable panic is another issue [1]. The pilot-link code first opens /dev/ugenX and then switches to

1. Large 1 MB I/O, all reads and write to file systems 1MB (can use setvbuf to do this with out coding) e.g a awk programme doing 8K I/O to read 2GB file took 16 min, a perl programme doing 1MB I/O took 16 seconds. 2. When doing rsync -a /dir1/dir2 /dir3/dir4 Do not use pipe's, as they only read/write 5k at a time this is extremly slow, check it out with Solaris truss. Use sockets with

Miroslav Lichvar wrote: > Hm, does this mean that every process encoding FLAC files will now > need extra 10MB of memory? Is that ok for small devices with limited > memory? What small device do you have in mind? The smallest device I could possibly imagine *encoding* FLAC on is Rasberry Pi which has 512Meg of RAM. If you really are concerned about this (and knowing that it has little

lvqcl, Would you be able to have alook at this one? I think its Windows related: https://sourceforge.net/p/flac/feature-requests/114/ Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

now with the proper flags passed and the jobs.c fix dash allmost compiles in DEBUG mode, the last two failures happen in show.c, which assumes some buffering functions that klibc doesn't provide: usr/dash/show.o: In function `opentrace': show.c:(.text+0x36): undefined reference to `freopen' show.c:(.text+0x86): undefined reference to `setlinebuf' afais this code dates from the

lvqcl wrote: > IMHO it's better to move setvbuf() out of libFLAC/stream_encoder.c > into flac/encode.c. Why do you thing that is better? > I can see two ways to do this: > > 1) Add a new function to libFLAC API that have access to > encoder->private_->file and can call setvbuf: > > FLAC_API FLAC__bool FLAC__stream_encoder_set_buffer_size(FLAC__StreamEncoder

On 10.12.2015 19:58, lvqcl wrote: > LRN wrote: > >> The commit mentioned in the feature request should not cause such >> behaviour, as it only does short-lived operations (opens a file, does >> stuff, closes the file immediately after) and is clearly distinguishing >> between disk files and pipes (which is how you, presumably, stream data to >> other processes

Hello I'm pretty much a newbie when it comes to C, but I have to use this language to write a couple of AGI proggies because I need them to be statically compiled. Strangely enough, Google didn't return much when looking for the "Hello, world!" of AGI in C. The following doesn't work: The file never gets written: =========== //check_cid.c #include <stdio.h> #include