similar to: install-strip issue

The first patch will make "make install-strip" work. The second spends a few cycles avoiding "1 files to consider." Both are trivial but IMHO useful. --- Makefile.orig Wed Mar 13 06:38:42 2002 +++ Makefile Wed Mar 13 06:40:58 2002 @@ -12,6 +12,7 @@ LDFLAGS= INSTALLCMD=/bin/install -c +INSTALLMAN=/bin/install -c srcdir=. @@ -56,8 +57,8 @@ ${INSTALLCMD} -m 755 rsync

I am guessing that since the error is on the first instance of the use of foo$(VAR): foo.o construct, that the Irix makefile parser doesn't know how to deal with this line. Obviously they don't use GNU make.... So here is a patch to Makefile.in that simplifies the use of variables. This only uses constructs that should work in all makes. It should not break anything, and it

This is an updated version of my patches to get rsync to build and run its tests on the Stratus VOS operating system. I have updated this patch to apply cleanly to the current copy of HEAD. I also ran the test suite and discovered that I needed to tweak a few spots in the Makefile to append the executable suffix (VOS is one of the few systems that has a required executable suffix). There are a

Hi, I have already sent this once, but since the problem persists here it is again. Please consider the attached patch for inclusion in the rsync distribution. The patch fixes the problem that 'make install-strip' tries to strip the manpages and thus fails. An other part of the patch adds DESTDIR (for package building). This is nowadays part of all automake generated Makefile's,

Hello, I can not install rsync 2.5.5. on a Caldera Open Unix 8.0.0 Operating System. After ./configure I enter the command "make" and I get the following Message: UX:make: FEHLER: Zeile 66: Syntaxfehler Where can I get help? I add the files: config.log and Makefile. P. Schnickmann -------------- next part -------------- This file contains any messages produced by compilers while running

Hi, 1. "make install-strip" (in rsync-2.5.x) tries to strip the manpages and thus fails; attached is a patch fixing the Makefile logic (and also adding DESTDIR -- convenient for package-building or test-installing). 2. I just fetched rsync-2.5.2 but the build (on i686-linux) badly fails. The complete log from configure and make is attached. regards Peter Breitenlohner

Since progressmeter.o has moved to libssh, we don't need to explicitly link it into scp and sftp any longer. Index: Makefile.in =================================================================== RCS file: /cvs/openssh/Makefile.in,v retrieving revision 1.255 diff -u -r1.255 Makefile.in --- Makefile.in 10 Feb 2004 02:01:14 -0000 1.255 +++ Makefile.in 11 Feb 2004 17:10:40 -0000 @@ -137,8 +137,8

Hi, I would like to ask you to consider the attached patch for inclusion into the next samba release. The patch addresses the following three points: 1. 'make install' with VPATH fails at one point ( $(srcdir)/script/findsmb vs. script/findsmb ) 2. support for 'make DESTDIR=<somewhere> install' (e.g. to build a binary package) 3. support for 'configure

I am getting the following errors when compiling SAMBA 2.2.4 on HP-UX 11.00. Anyone have any ideas on what's causing the problem? Using FLAGS = -O -I./popt -Iinclude -I./include -I./ubiqx -I./smbwrapper -D_HPUX_SOURCE -D_POSIX_SOURCE -D_LARGEFILE64_SOURCE -D_ALIGNMENT_REQUIRED=1 -D_MAX_ALIGNMENT=4 -DLOGFILEBASE="/opt/samba/var" -DCONFIGFILE="/opt/samba/etc/smb.conf"

I am getting the following link errors when compiling SAMBA 2.2.4 on HP-UX 11.00. Anyone have any ideas on what's causing the problem? Using FLAGS = -O -I./popt -Iinclude -I./include -I./ubiqx -I./smbwrapper -D_HPUX_SOURCE -D_POSIX_SOURCE -D_LARGEFILE64_SOURCE -D_ALIGNMENT_REQUIRED=1 -D_MAX_ALIGNMENT=4 -DLOGFILEBASE="/opt/samba/var"

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

Christian Weisgerber <naddy@mips.inka.de> wrote: > | # nasm build rule: > | %.lo: %.s Even with gmake, this really works only by accident. Automake generates a competing suffix rule, and gmake apparently gives the rule above a higher priority than the suffix rule (or that just happens to be the evaluation order). Matt, since you seem to understand automake, can you come up with

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

Matt Zimmerman <mdz@debian.org> wrote: > Aha. In FLAC__fixed_restore_signal, the index variable 'i' is declared > unsigned, then used like so: [...] With the following trivial patch applied, > everything works on Alpha, at least with my test sample. Against 0.9 or CVS? While this clearly fixes a bug, 0.9 still dies for me. #0 0x1600692a8 in

That sounds like the application param is still used as part of the process though? Would allowing the user to specify the application work in the Solokey case? What is stored in the private keyfile? The documentation says no private key is stored there. So is it just information used to reseed the public/private key? Thanks, Kevin ________________________________________ From: openssh-unix-dev

There are problems in the configure option handling code for http streaming that was added to the XMMS plugin for 1.1.2. In configure.c, flac_cfg.stream.proxy_host and other pointers to strings are initialized with pointers to an empty string "". Subsequent code in FLAC_XMMS__init() and flac_configurewin_ok() passes these pointers to g_free(). Since they don't point to memory that

This affects the XMMS plugin. configure.in has this test: AC_CHECK_TYPES(socklen_t, [], []) And src/plugin_xmms/http.c is the only consumer: #ifndef HAVE_SOCKLEN_T typedef unsigned int socklen_t; #endif Together this looks bogus to me. The configure check looks for socklen_t in the default headers. If it isn't found there, socklen_t will be typedef'ed. However, at least on

I'm currently trying to figure out why RC3 oggenc with iconv support will - work, but enter replacement characters into tags instead of converting to UTF-8; - dump core; or - catch an assert(); depending on the locale settings. (On FreeBSD, with Chuguev iconv.) I think I'm getting a handle on the assert(). It's this one: assertion "(!k && !ibl) || (k == (size_t)(-1)

libogg 1.1's included regression tests ("make check") fail at least on alpha: ---------------> ./test_bitwise Small preclipped packing (LSb): ok. Null bit call (LSb): ok. Large preclipped packing (LSb): ok. 32 bit preclipped packing (LSb): ok. Small unclipped packing (LSb): ok. Large unclipped packing (LSb): ok. Single bit unclipped packing (LSb): ok. Testing read past end

Here's the promised Sun audio system plug-in. I have tested this on OpenBSD. It should work without changes on NetBSD, too. Jeremy, could you please verify this? After a few minor tweaks it now also compiles on Solaris 2.7. Alas, I can't verify whether it actually plays anything there. I guess this could also with little effort be made to work on SunOS4. Attached: - Diff to