similar to: alloca + configure.in

Are there any dependencies that I need, but don't have? I've got doxygen, libogg, automake, autoconf, libtool, valgrind, docbook, nasm, yasm, libiconv. the Autogen.sh script fails with: "Updating build configuration files for FLAC, please wait.... configure.ac:308: warning: macro 'AM_ICONV' not found in library configure.ac:309: warning: macro 'AM_LANGINFO_CODESET'

Hi As shown below, the .\configure script found a version of alloca(): --------------------- configure:20831: checking for working alloca.h configure:20853: gcc -o conftest -g -O2 conftest.c -ldl >&5 configure:20856: $? = 0 configure:20859: test -s conftest configure:20862: $? = 0 configure:20873: result: yes configure:20883: checking for alloca configure:20925: gcc -o conftest -g -O2

Josh, I'm trying to build CVS flac-1.1.1 in order to make sure flac123 will work with it. I'm having a hard time getting autogen.sh's aclocal to work with configure.in. I'm using autoconf-2.59 (from source) on Redhat 9.0. I have found automake-1.7.8 and automake-1.8.5 yield similar results: $ ./autogen.sh aclocal: configure.in: 142: macro `AM_PROG_LIBTOOL' not found in

I got the following compile error in R-1.9.0 on NetBSD 1.5: <-- snip --> ... gcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -O2 -mcpu=v8 -c main.c -o main.o main.c: In function `setup_Rmainloop': main.c:463: `CODESET' undeclared (first use in this function)

Hi John, In my setup OBJDIR is SRCDIR. I'm looking at the config.h and not config.h.in. Yes, defining HAVE_ALLOCA_H to 1 fixed the compilation. Moreover, I also defined HAVE_ALLOCA to 1 in the config.h: -------------------- /* Define to 1 if you have `alloca', as a function or macro. */ /* #undef HAVE_ALLOCA */ #define HAVE_ALLOCA 1 /*Henrik:*/ /* Define to 1 if you have

Jake wrote: >$ ./autogen.sh >aclocal: configure.in: 142: macro `AM_PROG_LIBTOOL' not found in library >aclocal: configure.in: 255: macro `AM_ICONV' not found in library >aclocal: configure.in: 256: macro `AM_LANGINFO_CODESET' not found in >library I can compile now that I've installed libtool-1.5.6 and gettext-0.14.1. :-) I did need to tweak autogen.sh to use

On Fri, 2004-11-12 at 12:32, Chris Lattner wrote: > Perhaps the right way to handle this particular problem is to add the > appropriate autoconf check to the llvm-test configure, then have the > programs that need alloca use the detected value? Its already in the llvm configure which is inherited by llvm-test. If you want to define this in the makefiles, add the following to

I am still chasing this down, but in doing the build for OpenVMS, I have discovered that one of the popt modules is using HAVE_ALLOCA_H to determine if the alloca function is on a platform. That is not a good assumption. Compaq C does have an alloca() built in (slightly different symbol name, I assume because of symbol naming rules in the C standard.) Because alloca is a non-standard

i have been playing around trying to get ice2 to work now for quite some time and frankly i am a bit frustrated by now... the anoying thing is how early in the whole proccess my problems actually start! running ./autogen.sh in the newest cvs version of ice2 results in <p>idoru:/usr/src/ices# ./autogen.sh I am going to run ./configure with no arguments - if you wish to pass any to it,

Brian R. Gaeke wrote: > Hi, > > My recent refactoring of the (machine-dependent) use of <alloca.h> > does not attempt to change CWriter's behavior of emitting a #include > for <alloca.h>. FreeBSD does not have <alloca.h>, so this would cause > trouble. > > We could change it to emit an #ifndef __FreeBSD__...#endif around > #include

Hi, My recent refactoring of the (machine-dependent) use of <alloca.h> does not attempt to change CWriter's behavior of emitting a #include for <alloca.h>. FreeBSD does not have <alloca.h>, so this would cause trouble. We could change it to emit an #ifndef __FreeBSD__...#endif around #include <alloca.h>. I suggest this because, I'm guessing, whether or not the

_WIN32 is always defined by the compiler automatically when targeting that platform, while WIN32 only is defined automatically in some configurations, and e.g. in MSVC only ever is defined in project files (if at all). Some other checks in the codebase already check for both WIN32 and _WIN32; those are left untouched. --- include/speex/speex.h | 2 +- libspeex/stack_alloc.h | 2 +-

Here's a propsed heavy-duty solution for your UTF-8 problems. I'm including a patch in this message, but I'll put the new files on my web site at http://rano.org/tmp/xiph_files.tar.gz I've tested this by running vorbiscomment with and without -DHAVE_ICONV=1 in vorbis-tools/share/Makefile. It seems to work. Changed files: acinclude.m4: Add a test for nl_langinfo(CODESET). This

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AFAIK, alloca.h is not POSIX. Here's a patch that includes alloca.h only when it's really there. It also includes malloc.h, which is where mingw-w64 defines the alloca() macro, mapping it to gcc __builtin_alloca() or to msvcrt _alloca(). - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version:

when i build dovecot in my computer, something has occured like below: root at 2030c8624e88:/dovecot-2.3.9# ./autogen.sh --2019-12-04 10:49:53-- https://www.dovecot.org/tmp/wiki2-export.tar.gz Resolving www.dovecot.org (www.dovecot.org)... 94.237.12.234, 2a04:3545:1000:720:acc1:5bff:fe5e:4e9 Connecting to www.dovecot.org (www.dovecot.org)|94.237.12.234|:443... connected. HTTP request sent,

On Thu, 11 Nov 2004, Reid Spencer wrote: > This kind of thing is one of the many reasons we broke llvm-test out to > a separate project. It has multiple purposes. Its a correctness test on > LLVM, its what we base our compiler benchmarks on, and its also where a > lot of the research gets done. You've been bitten by the latt(n)er. :) > > At some point I'd like to see us

The autoreconf tool is provided by autoconf to do what custom autogen.sh scripts in many projects used to do. Only it is more robust and widely tested. It has been available for several years, too. No reason to rely on custom code for this. Signed-off-by: Max Horn <max at quendi.de> --- Makefile.am | 2 - autogen.sh | 168

The following popt files need patches in order to compile using Compaq C on OpenVMS. These patches should also be needed on a Tru64 or LINUX on ALPHA using Compaq C. Except for the alloca issue, these should work on any ANSI compliant compiler. Operating System: OpenVMS ALPHA V7.3 Compiler: Compaq C T6.5 Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE) SYSTEM.H is doing tests on

I have in my working directory the trivial header changes necessary to allow FLAC library functions to be used in C++ programs. Is it OK to commit this? -- - mdz -------------- next part -------------- ? Makefile ? Makefile.in ? ordinals.h Index: file_decoder.h =================================================================== RCS file: /cvsroot/flac/flac/include/FLAC/file_decoder.h,v

These days, sshd.c has: static void grace_alarm_handler(int sig) { ... if (getpgid(0) == getpid()) { signal(SIGTERM, SIG_IGN); killpg(0, SIGTERM); } sigdie(...); } however (really) old BSDs do not have getpgid(). They do have getpgrp(), which does what we want here. The question is what to do if we have neither: return the pid (and thus