similar to: [PATCH] modernize configure.ac, update gnulib macros and add the havelib module, remove aclocal.m4

I need to migrate data from a Linux box (PATH_MAX 4096) to Solaris with (PATH_MAX 1024) and it so happens that not only do paths longer than 1K actually exist, but also is the application in no way bound to 4K paths. In an effort to find a generic solution to these issues, I have written liblongpath. See https://code.uplex.de/liblongpath - there is a manpage (online as RST:

Signed-off-by: Doug Goldstein <cardoe at gentoo.org> --- Makefile.am | 2 +- configure.ac | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: fee51bc27d60c7ec9d0371af88a476a232d9a8bd.diff Type: text/x-patch Size: 761 bytes Desc: not available Url :

The attached unified diff fixes configure so that all --with-libfoo options are allowed to be --with-libfoo=PATH. If the option is specified with a PATH, only that PATH is searched for the library. If it is specified as =yes or with no argument, it tries without modifying anything, and then tries looking in /usr/local. The SunOS5 targets no longer add /usr/local to include or library paths

The attached unified diff fixes configure so that all --with-libfoo options are allowed to be --with-libfoo=PATH. If the option is specified with a PATH, only that PATH is searched for the library. If it is specified as =yes or with no argument, it tries without modifying anything, and then tries looking in /usr/local. The SunOS5 targets no longer add /usr/local to include or library paths

Hi Josh (and everyone else on the list), Here's a quick fix for libFLAC.m4 and libFLAC++.m4 for a problem that crops up if you use the macros in an environment where LD_LIBRARY_PATH is set. The macros save LD_LIBRARY_PATH as ac_save_LDPATH, but restore it from ac_save_LD_LIBRARY_PATH. This patch changes ac_save_LDPATH to ac_save_LD_LIBRARY_PATH. Without this, LD_LIBRARY_PATH effectively gets

--On Monday, August 23, 2004 6:50 PM +0900 Jim Tittsler <jt at OnJapan.net> wrote: > You can get dovecot-0.99.10.9-1.FC3.2.src.rpm from the > Fedora Core development tree. (Seems to be working well for us.) I just built this and it has a lot of complaints about underquoted macros in aclocal. Red Hat refers developers to this reference:

I'm trying to build an executable for a program I wrote. The compilation steps go well, but the linking step fails with a libtool "version mismatch" error. My linking command has this prefix: /path/to/R/bin/R CMD LINK gcc -g -std=gnu99 ... etc. The error looks like this: libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 See the end of the message for a possible delete of a closed fd from epoll() problem. Every now and then I get a Panic after a successfull LMTP delivery: 2014-11-12 13:25:31 lmtp(20890): Info: Connect from local 2014-11-12 13:25:32 lmtp(20890): Info: Disconnect from local: Connection closed (in reset) 2014-11-12 13:25:34 lmtp(20890): Info: Connect

Since some modules (`getopt', for example) may copy files into the build directory, `top_builddir/lib' is needed as well as `top_srcdir/lib'. -- GNU Gnulib manual, section 2.2 Initial import --- capitests/Makefile.am | 1 + daemon/Makefile.am | 2 +- src/Makefile.am | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/capitests/Makefile.am

OK. Digging into this... sendmail.m4 has the lines: define(`FAX_MAILER_PATH',`/usr/bin/faxmail')dnl define(`FAX_MAILER_ARGS',`faxmail -d -n -p 12pt $u@$h $f')dnl MAILER(`fax')dnl proto.m4 has: `R$+ < @ $+ .FAX. > $#fax $@ $2 $: $1 user at host.FAX', `ifdef(`FAX_RELAY', `R$*<@$+.FAX.>$* $:

m4/as-compiler-flag.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) New commits: commit 59003aea7d25c962c3332db28222b4241f68fdda Author: Benjamin Otte <otte at gnome.org> Date: Tue Oct 30 10:40:04 2007 +0100 make second and third arguments to AS_COMPILER_FLAG optional diff --git a/m4/as-compiler-flag.m4 b/m4/as-compiler-flag.m4 index f706196..76cf4cd 100644 ---

It looks like the change to m4/nut_check_libnetsnmp.m4 in r1968 broke the test on at least Solaris 10. Here is one possible fix. ---------------------------- --- m4/nut_check_libnetsnmp.m4.old 2009-12-15 09:30:48.000000000 -0800 +++ m4/nut_check_libnetsnmp.m4 2009-12-15 11:12:15.291295000 -0800 @@ -9,7 +9,8 @@ if test -z "${nut_have_libnetsnmp_seen}"; then

https://bugzilla.samba.org/show_bug.cgi?id=11813 Bug ID: 11813 Summary: m4/socklen_t.m4 uses obsolete AC_TRY_COMPILE macro Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: core Assignee: wayned at samba.org

Hi, I've (just now) been playing with a buildbot, building ogg, vorbis, speex, and theora, using a non-standard prefix on a pretty bare debian image. I noticed that vorbis was failing during configure while theora wasn't. I tracked it down to the location of ogg.m4. There is a copy of ogg.m4 in theora/m4, but there is not one in vorbis/m4. This means that if you have libogg installed

Since some modules (`getopt', for example) may copy files into the build directory, `top_builddir/lib' is needed as well as `top_srcdir/lib'. -- GNU Gnulib manual, section 2.2 Initial import This fixes an in-tree build failure on a Debian/sid system (see below). hivexml could be built out-of-tree, but it turned out that due to a missing include path, in this case the

Greetings everyone. I have 2 quick questions about ao/ao.m4, ogg/ogg.m4, and vorbis/vorbis.m4. 1. Is there any reason that the macros are named AM_PATH_AO, AM_PATH_OGG, and AM_PATH_VORBIS? Can we change them to something else? I ran into a problem when trying to add support for ogg/vorbis into a package today: Automake assumes that anything beginning with AM_ belongs to automake -- these two

Hi, new to llvm/clang so forgive any errors on my part. For Debian 8 (Jessie), though all other packages have installed successfully, for clang modernize I get - nick at macbookpro-debian:~$ sudo apt-get install clang-modernize-3.8 [sudo] password for nick: Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package clang-modernize-3.8 E:

The docs are in a good shape in this regard: http://clang.llvm.org/extra/clang-modernize.html http://llvm.org/releases/3.8.0/tools/clang/tools/extra/docs/clang-modernize.html Apparently, it doesn't make the fact more discoverable though. On Tue, Apr 26, 2016 at 11:27 AM, Benjamin Kramer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > clang-modernize was folded into clang-tidy

Op 20100702 om 11:21 schreef syslinux-bot for H. Peter Anvin: > > lua: Modernize the Makefile <bigsnip/> > -liblua.a: $(LIBLUA_OBJS) > +$(LIBLUA) : $(LIBLUA_OBJS) > + rm -f $@ > $(AR) cq $@ $^ > $(RANLIB) $@ FWIW: Today I also found that missing `rm -f $@` Cheers Geert Stappers

Adding Sylvestre, who should know how to fix that. On Tue, Apr 26, 2016 at 10:39 PM, Nick Wiggill <nick.wiggill at gmail.com> wrote: > Thanks for your replies, gentlemen. I'm in good standing with my install, > then. > > On the apt page <http://llvm.org/apt/>, it should not be suggested then > to "apt-get install [..etc..] clang-modernize-3.8 [..etc..]"