I'm having a problem with both autoconf 2.13 and 2.50.
AC_OUTPUT(myfile-dnl.sh)
barfs because m4 interprets
the dnl as a command. Neither
AC_OUTPUT([myfile-dnl.sh]) nor
AC_OUTPUT(myfile-d[]nl.sh)
seem to fix it. However,
AC_OUTPUT(myfile-d""nl.sh)
seems to do the trick. Anyone else run int
Tim Van Holder wrote:
>
> > This is all you get:
> >
> > > $ autoheader
> > > /usr/bin/m4: ERROR: EOF in string
> > > autoconf: tracing failed
> >
> > Any hints about what to do?
>
> That is a very annoying message indeed.
> One thing you should check for is unbalanced
> brackets. That often se
Kevin Ryde wrote:
>if grep "IP Filter: v3\.4\." /usr/include/netinet/ipl.h >/dev/null;
>then
> AC_DEFINE(IPF_4_3, 1, [Define for IP Filter v3.4.x])
>fi
>
> (Though whether it's particularly robust to be grepping particular
> include files is another matter.)
You can't assume the inc
It looks like a lot of AC_FUNC_* macros are not
cross-compile-friendly, as they use AC_RUN_IFELSE.
Is an appropriate way to deal with these to
set environment variables before running config,
to tell it what it can't figure out itself?
e.g.
ac_cv_func_mmap_fixed_mapped=yes ./configure
? That s
Currently, netkit
(ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/netkit-combo-0.17.tar.gz)
uses a configure script (good!) but it's not autoconf-generated.
This is a problem when cross-compiling; it aborts if you
specify a cross-compiler, and does a bunch of feature tests
by running compiled
I've been using autoconf 2.5x for some time. Today I suddenly got the
error
configure.in:212: error: m4_popdef: undefined macro: AC_Dest
when running autoconf.
Heh. Got bit by the ol' you-can't-use-filenames-containing-dnl
issue again!
The problem was triggered by adding a line to configure.
Guido Draheim wrote:
>
> overkill.
Agreed. I'm tempted to say:
Death to XML, long live *plain* text!
- Dan
Ralf Corsepius wrote:
> On the opposite side, all automake+autoconf based packages applying
> mixed case package names have the potential to be be affected. Those
> which additionally apply gettext would almost for sure be affected.
>
> A rough estimate from grep-ing the package names of the >200
I've been using the corbaconf macros at http://corbaconf.kiev.ua/
They look potentially very useful, and I've already gotten some
benefit from them.
However...
It seems wrong that they update universal variables like LIBS.
This gets in the way of non-corba programs in the same package.
It also se
Henrique de Moraes Holschuh wrote:
>It also means Debian will need to fork config.guess
>permanently so as to force autoconf stuff to build using
>the correct host arch (since there seems to be no way to
>sepecify a build architecture without entering
>cross-compiling mode or risking weird side
I need to cross-compile glib, and that's easier to
do with autoconf2.52 than with the old autoconf2.13.
However, glib's configure.in,
http://cvs.gnome.org/lxr/source/glib/configure.in#18
uses the macro AC_DIVERT_PUSH which is not a documented
part of autoconf, and which no longer works the same w
I just figured out how to make life easy for
cross-compiling. configure should have an option,
--emit-try-run, which would generate and compile a C program
which, when compiled and run, would output environment
settings which could be used in future configure
runs to suppress AC_TRY_RUN's. To us
Paul Eggert wrote:
>
> > From: Dan Kegel <[EMAIL PROTECTED]>
> > Date: Sun, 03 Mar 2002 10:02:14 -0800
> >
> > configure should have an option,
> > --emit-try-run, which would generate and compile a C program
> > which, when compiled and run, would o
Paul Eggert wrote:
>
> > Date: Mon, 04 Mar 2002 10:38:00 -0800
> > From: Dan Kegel <[EMAIL PROTECTED]>
>
> > Maybe configure would take a '--host-run-cmd' option which
> > would tell it how to run executables during TRY_RUN for
> > cross-comp
I'm cross-developing. I want to build a package
that has both static libraries and binaries.
The binaries should go to the target system;
the libraries should stay on the build system.
What do I pass to configure and to make?
If I do
configure --build=pentium-unknown-linux --host=@IXIA_K_ARCH@-u
e may need to split
--libdir into --libdir and --buildlibdir, or something
awful like that?
Thinking about libtool and cross-compiling is giving me
serious heartburn.
- Dan
Guido Draheim wrote:
>
> --bindir vs. --libdir ?
>
> Es schrieb Dan Kegel:
> >
> > I'm cross
here but a subdirectory of /foo.
And you can't cheat and pass DESTDIR as a prefix on
--prefix, because then libtool will get all confused
on the target system; it will expect executables to
be in /foo/bin, but on the target, they'll be in /bin.
It's pretty confusing stuff.
- Dan
Da
e.)
I don't think this does the trick, though. I can't see
how it lets you install binaries and shared libs to a staging
area for transfer to the target, and everything else to
their final location on the build system, while making
sure that libtool is told the proper final location
of s
On Thu, May 30, 2013 at 10:30 PM, Kip Warner wrote:
> The ones for certain I know I should be able to statically link against are
> at least libzzip and libpng.
You have
> PKG_CHECK_MODULES([libzzip], [zziplib], [have_zzip=yes], [have_zzip=no])
Have you seen
https://bugs.freedesktop.org/show_bug.
On Sat, Jun 1, 2013 at 4:42 PM, Kip Warner wrote:
> $ pkg-config --libs zziplib
> -Wl,-Bsymbolic-functions -Wl,-z,relro -lzzip -lz
>
> $ pkg-config --static --libs zziplib
> -Wl,-Bsymbolic-functions -Wl,-z,relro -lzzip -lz
Aw, foo. I was under the misapprehention
Nice writeup!
Next step might be to set up continuous integration for Autotools,
with automated testing on the core list of supported platforms, and
use that to do a nearly-no-change release that just fixes any bugs
that show up by the time it's working.
I have no time and cannot plausibly volunt
(Removing automake as the original message said "Followup discussion
should go to the Autoconf mailing list.")
I agree that consolidating support for the current architecture and
use cases is the place to start.
The number one screaming priority would seem to be adding continuous
integration.
htt
Meson is a candidate for such a next-gen config system. It is in python,
which does not quite qualify as usable during early uplift/bootstrap, but
there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/
In the meantime, I agree that find is more portable than cards ;-)
- Dan
Daniel
15, 2022 at 7:52 PM Mike Frysinger wrote:
>
> On 15 Feb 2022 20:25, Jacob Bachmeyer wrote:
> > Dan Kegel wrote:
> > > Meson is a candidate for such a next-gen config system. It is in python,
> > > which does not quite qualify as usable during early uplift/bootstrap,
Guido Draheim wrote:
> > ...
> > I don't think this does the trick, though. I can't see
> > how it lets you install binaries and shared libs to a staging
> > area for transfer to the target, and everything else to
> > their final location on the build system, while making
> > sure that libtool is
ly what I want. (Haven't checked.)
Maybe all I need is something like 'make install-LTLIBRARIES' but
without installing static libraries, even if they are enabled.
- Dan
> Dan Kegel wrote:
> >
> > I'm cross-developing. I want to build a package
> > that h
Lars Clausen wrote:
> >> Earlier we used hand-built macros to check for Freetype, but since
> >> we have to check the version, we now use the AC_CHECK_FT2 macro.
> >
> > AC_CHECK_FT2 is not part of Autoconf, so possibly this is a problem
> > with your definition of this macro, not with Autoconf it
Dumb question: what do I put in configure.in to
make sure nobody accidentally uses autoconf2.13 on it?
I think there's a way to specify minimum version of autoconf
required, but I'm too dumb to find it...
Thanks,
Dan
Guido Draheim wrote:
> ... See - the libtool crossgcc support (to which I did
> contribute some of the time) can simply ask the cross-gcc
> for the local searchpath via `gcc -print-search-dirs` -
> this is needed for win32 compiles atleast, and I have a
> patch on my disk which generalizes the ide
Guido Draheim wrote:
> ... we do not
> need any automake support when a staging area (a
> chroot-like target host simulation-filetree) is
> being used, it would just be a different DESTDIR,
> and it would also provide the support for any
> other build support file, like includeheaders or
> some ot
I have three times now blown away scripts I've
written and started autoconfisticating by
forgetting to rename them .in before running configure.
If I wrote a patch for autoconf that refuses to delete
output files if the corresponding input file didn't exist,
think the maintainer would accept it
Dan Kegel wrote:
>
> I have three times now blown away scripts I've
> written and started autoconfisticating by
> forgetting to rename them .in before running configure.
And twice now by accidentally putting in the .in suffix
inside the AC_OUTPUT line. Autoconf ought to
be a
Somebody already implemented the AC_TRY_RUN fix
for cross-compiling. Has it been looked at by the
autoconf maintainers yet? Here's the link:
http://bugzilla.gnome.org/showattachment.cgi?attach_id=5941
http://bugzilla.gnome.org/show_bug.cgi?id=58786
- Dan
David Thompson wrote:
>
> > AC_CHECK_HEADERS( file.h file1.h ... file6.h \
> > file7.h file8.h ... file12.h \
> > file13.h)
> > > However, the code produced by the macro doesn't copy the '\' so it
> > sees the newline and obviously breaks. Is there anyway around this
> > other than to writ
Yep. Here's what I do to build my 'linux distribution'.
I have an outer autoconf configure that figures out the location
of compilers and flags needed to cross-compile; it configures
one little wrapper Makefile for each third-party package.
Here's the wrapper Makefile.in I use to build betaftpd (
Dan Kegel wrote:
> ACENV=CC=@IXIA_CROSS_TOOL@gcc CFLAGS="@IXIA_TARGET_CFLAGS@"
> ac_cv_func_mmap_fixed_mapped=yes
That should all have been one line; the ac_cv_func_mmap_fixed_mapped=yes
is supposed to be part of $(ACENV), so it overrides the
environment properly in the line
[EMAIL PROTECTED] wrote:
> When I cross compiled ORBit1 (now ORBit2) to LynxOS/PowerPC it was very
> usefull to see how the PPC side configured things. I did have the thought
> that it would be very usefull to have the configure tools recognize that
> you are doing a cross compile say to PPC and
Paul Eggert wrote:
> > [EMAIL PROTECTED] wrote:
> > > I did have the thought that it would be very usefull to have the
> > > configure tools recognize that you are doing a cross compile say
> > > to PPC and have it set up default "sizes" etc based on known PPC
> > > settings.
>
> The latest Autoc
Ossama Othman wrote:
>
> > > Now, now, it's OK to use AC_TRY_RUN if there's a reasonable fallback
> > > when not cross-compiling. (Please don't stick pins into my doll's
> > > head! :-)
> >
> > So YOU'RE the one! :-) I dare you to show me a reasonable use of
> > AC_TRY_RUN that is correct both
Ossama Othman wrote:
> > > I have to agree with Paul. Sometimes it's just not possible to rely
> > > on compile/link-time tests alone.
> >
> > That's ok if three things hold:
> > 1. configure.in authors avoid gratuitous use of AC_TRY_RUN.
>
> That should certainly be feasible unless there are so
Ossama Othman wrote:
> On Mon, Apr 01, 2002 at 09:02:12PM -0800, Dan Kegel wrote:
> > Ossama Othman wrote:
> > > That should certainly be feasible unless there are some bizarre
> > > platforms out there. In any case, this shouldn't be a problem if
> > &g
Ossama Othman wrote:
>
> Hi Dan,
>
> On Mon, Apr 01, 2002 at 10:31:33PM -0800, Dan Kegel wrote:
> > In theory, sure. However, I've never seen anyone do anything
> > fancy in the 'if-cross-compiling' case but pick a default.
>
> In practice,
Peter Eisentraut wrote:
>
> Akim Demaille writes:
>
> > In fact, I think all the tools should provide some --clean. For
> > instance, the hair we have to clean the Texinfo related files have
> > nothing to do in Automake. It should be provided by texi2dvi and the
> > like.
>
> But where does
Ollie Cook wrote:
> I have an application which links against librrd
> and I'd like my configure script to find where the
> rrd.h header and librrd.a library files are so
> that it can pass the paths to the compiler with -I and -L
>
> I'm currently doing it with ...
> --with-includes=LIST
> L
Thomas Dickey wrote:
>
> On Sun, Apr 07, 2002 at 08:08:30AM -0700, Adam J. Richter wrote:
> > autoconf-2.53 does not allow AC_DEFINE_UNQUOTED variables
> > that begin with "AS_", reserving that part of the name space for
> > autoconf m4sugar macros. I think autoconf should allow this and
>
I'm writing a build system that places one Make include file
in each directory, and includes them from a single master Makefile
recursively. It can handle builds for multiple architectures
all in the same run, without recursive invocations of Make.
Along the way, I got a strange craving for bein
n Wed, May 08, 2002 at 10:17:18AM -0700, Dan Kegel [DK] wrote:
DK> Another path we should pursue in parallel: for those cases where
DK> the host system is on the network and available to run code,
[...]
How about splitting up autoconf into two parts:
Part one creates some kind of "mac
Henrique de Moraes Holschuh wrote:
> Many of our porters hate libtool with vengeance (or worse)
I certainly do. As a guy who routinely cross-compiles
applications for embedded systems, I can testify that
libtool is a broken pain in the ass sometimes.
- Dan
Keve Müller wrote:
> I'm using autoconf-2.53 to configure a Makefile that builds a library.
> The makefile will work for both Linux and Windows environments.
>
> Now, I've experimented with cross-compiling on the Linux system to build
> the library for the Windows target. Interesting enough it w
Not sure supporting FAT16 is worth spending much time on...
- Dan
-Original Message-
From: Mat Hounsell
To: [EMAIL PROTECTED]
Sent: 03.06.2002 18:33
Subject: Autoconf : Build fails if the build and source directory are on
different file systems.
Hello,
While trying to build GCC 3.1 f
Alexandre Duret-Lutz wrote:
>>>Sam> this is a major inconvenience.
>>>Sam> adding a --remove-cache option
>>>
>>>To who? Automake + autoconf + autoheader + autoscan + autoreconf +
>>>autom4te + autoupdate ?
>
> This option is already supported by all these tools.
> It's spelled `; rm -rf autom4t
Akim Demaille wrote:
>>"Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>
>
> Paul> AIX and Interix use _ALL_SOURCE, Solaris uses __EXTENSIONS__,
> Paul> GNU uses _GNU_SOURCE, HP/UX uses _HPUX_SOURCE, and Minix uses
> Paul> _MINIX, _POSIX_SOURCE and _POSIX_1_SOURCE. Currently these
> Pa
Thomas Dickey wrote:
> On Mon, Jul 22, 2002 at 10:22:52AM -0700, Paul Eggert wrote:
>
>>>From: Dan Kegel <[EMAIL PROTECTED]>
>>>
>>>On Linux, it might be more standards-friendly to do
>>>#define _XOPEN_SOURCE 600
>>>instead of _GNU_SOUR
Ditch Interix and use Cygwin, perhaps?
Microsoft's support for Posix has always sucked,
and will always suck.
- Dan
-Original Message-
From: Santosh Kadam
To: [EMAIL PROTECTED]
Sent: 7/23/2002 5:36 AM
Subject: Pthread Support For Interix
Hi there,
I have a small query regarding the pt
ve my boss
approve it. I don't have a huge business reason to use it;
I just prefer bash sometimes. Gets me that nice tab
completion feature missing in win2k.
- Dan
-Original Message-
From: Philip Willoughby
To: Dan Kegel
Cc: 'Santosh Kadam '; '[EMAIL PROTECTED] '
Alexandre Duret-Lutz wrote:
>>>>"Dan" == Dan Kegel <[EMAIL PROTECTED]> writes:
>>>
>
> Dan> The name, autom4te.cache, is quite cryptic.
>
> This directory is a cache for autom4te
... a tool which most autoconf users have never heard of,
[EMAIL PROTECTED] wrote:
> On Mon, Jul 29, 2002 at 11:13:14AM -0700, Dan Kegel wrote:
>
>>Alexandre Duret-Lutz wrote:
>>
>>>>>>"Dan" == Dan Kegel <[EMAIL PROTECTED]> writes:
>>>>>
>>>Dan> The name, autom4te.cache,
David A. Holland wrote on 1 Aug 2002:
> Dan Kegel wrote on 18 Dec 2001:
> > Currently, netkit
> > (ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/netkit-combo-0.17.tar.gz)
> > uses a configure script (good!) but it's not autoconf-generated.
>
> Correct
David A. Holland wrote:
> > Here's what I ended up doing to cross-compile netkit-base and netkit-telnet:
> >
> > I untar the netkit source tarball into a separate directory for
> > each target processor type (bleh!).
> >
> > I then use my own autoconf system to produce a custom MCONFIG,
>
Bruce Korb wrote:
> Dan Kegel wrote:
>>It's a shame autoconf's configure scripts are so gross. If they were
>>more human-friendly, maybe more programmers would be willing to use it.
>>
>>Maybe once Posix mandates Python :-)
>
> Since autoconf avoids sh
Paul Eggert wrote:
>>From: "David A. Holland" <[EMAIL PROTECTED]>
>>Date: Mon, 12 Aug 2002 01:28:51 +0100 (BST)
>>
>>(1) it's a canonical example of the principle that software is almost
>>inevitably written using tools that are just not quite adequate for
>>the job. autoconf is written in m4. Thi
[repost -- mail system problems]
Building cross gcc's on cygwin fails because autoconf 2.13's AC_TRY_COMPILER
test assumes that it's ok to try to run possibly cross-compiled binaries,
and that if they run, the compiler must not be a cross-compiler.
This assumption fails on Cygwin; see
http://w
e point of configure scripts is to be portable, so
it makes a fair bit of sense for gcc to ship with configure scripts
that are portable even to systems like cygwin.
- Dan
Earnie Boyd wrote:
> I suggest that this issue be dealt with within the Cygwin distribution of
>autoconf-2.13.
>
>
tenance of 2.13 is dead for Autoconf proper.
There have been three
or four releases since then. If the developers who use Cygwin want to
continue to support
2.13 that's a different matter and those developers, someone like Dan
Kegel, can create the
patch there. However, I see that any deve
Alexandre Duret-Lutz wrote:
> I've stopped hard-coding absolute paths in my package because it
> hinders relocation of binary packages.
>
> Instead, at configure-time (not everybody will like this) I turn
> each pathname into a path relative to $(prefix), and guess
> $(prefix) at run-time.
>
> S
Paolo Bonzini wrote:
> Here is an idea for writing a multiprocessor-friendly autoconf.
> Basically, the idea is to change the configure phase into a Makefile
> target, and use caching as a way to split it into various sub-targets that
> can be executed in parallel. The shell script might run the
I've noticed lately that I need to specify --build when configuring
software for cross-compilation. This is a big burden, because
I write portable build scripts that invoke configure, make, etc.
It seems somewhat absurd, but the best way I can figure to find out
what to pass to --build is to run
Akim Demaille wrote:
> You are supposed to run this as:
>
> ./configure --prefix=/ --host=ppc_405 CFLAGS="-mcpu=403 -D__PPC405__"
>
> You are to tell the configure that you are cross-compiling. It cannot
> guess it, so it is entitled to fail. Please, read the documentation.
I must have
or errors, and without hard-coding info about the build
machine into my build scripts?
- Dan
-Original Message-----
From: Akim Demaille
To: Guido Draheim
Cc: Dan Kegel; '[EMAIL PROTECTED]'
Sent: 01.10.2002 23:02
Subject: Re: When crosscompiling, does configure really need --build?
>&
Standard practice is probably to always write
#if HAVE_SYS_TYPES_H
#include
#endif
#if HAVE_SYS_SOCKET_H
#include
#endif
I have a feeling autoconf gives you those preprocessor
definitions for free.
The more interesting question is how you get the link libraries right.
I do explicit checks for
Thien-Thi Nguyen wrote:
sounds about right -- finding the appropriate mux point to pinch is indeed the
first step towards sanity. if you get funding, give me a buzz. otherwise, i
will continue to work w/ (old) librx and approach the problem from the guile
perspective. (e.g., below is lex.test w
Paul Eggert wrote:
From: "Eric Lemings" <[EMAIL PROTECTED]>
Date: Thu, 7 Nov 2002 14:23:28 -0700
After reading through Section 11.4 of the Automake Manual, I was just =
curious about how well future releases of Automake (and Autoconf) are =
going to support distributions with Java source code. J
Y'all might want to pop in to the binutils mailing list;
they're getting serious about updating to the new
autotools, and are discussing what parts they'll have
to rewrite themselves to do it...
- Dan
John Poltorak wrote:
If I have prefix defined in config.site and use a diferent value on the
command line, which should take precedence?
I never use config.site, but I imagine the commandline should always
have the last word...
Warren Young wrote:
Dirk wrote:
how can i make autoconf probe for a parallel port?
Any particular OS, or "all of them"? :)
On a Linux box, I'd probably dig around in /proc to find a way to list
parallel ports and then write the shell code necessary to make sure the
/proc entry exists and
Paul Eggert wrote:
Date: Fri, 20 Dec 2002 07:25:54 -0500 (EST)
From: Jeff Squyres
We *don't* have multiple installations of autoconf
That is your problem.
FWIW, while Debian supports multiple installations of autoconf,
it doesn't yet support multiple installations of automake.
- Dan
I found the following in kaffe's configure.in:
AC_CHECK_FUNCS([dnl
strerror hstrerror dnl
fcntl ioctl dnl
alarm setitimer dnl
sigprocmask sigsetmask sigemptyset sigaddset signal sigaction dnl
sbrk valloc memalign mallopt dnl
mprotect madvise dnl
waitpid kill fork execve execvp dnl
sync fsync dnl
a
I discovered to my chagrin that I cannot update
kaffe from autoconf2.13 to autoconf2.53.
In detail, the problem is that converting kaffe to use autoconf2.5x
and then running configure causes the following error:
configure: configuring in libltdl
configure: running /bin/sh '../../kaffe-1.0.7/liblt
Markus wrote:
> Now in my Makefile.am I want to ...
> test_linalg_SOURCES = $(DIET)/demos/linalg/TestLinalg.C
I usually use autoconf variables for that, e.g.
foo = @DIET@/demos/linalg/TestLinalg.C
though I'm not sure automake will be happy with that.
en wanting autoconf to do for some time:
they support the equivalent of AC_TRY_RUN when cross-compiling.
(I suspect it'll be too much of a pain for me to use, though...)
The doc's at http://www.research.att.com/~gsf/man/man1/iffe.html
It's an interesting window onto an alternate univers
Paul Eggert wrote:
Dan Kegel <[EMAIL PROTECTED]> writes:
What about 3.2.2? Is it higher quality in your opinion?
3.2.2 still miscompiles Samba on sparc with -O2, so I'm still leery
I'm afraid.
... I'd trust it to compile "cat", say
Now there's a vote
Bob Lockie wrote:
>>>1. Can anybody point me to a tutorial on shell programming?
>>
>> Personally, I think the advanced Bash scripting guide is pretty good.
>> You can find it at: http://www.tldp.org/LDP/abs/html/
>
>I'll check it out.
I like "Portable Shell Programming" by Blinn.
See http://keg
Jens Petersen wrote:
[Dan Kegel wrote:
why is there no /usr/bin/autoconf-2.57 in Red Hat 8.1beta?]
The main reason for doing this was that autoconf-2.53 was
appearing in spec files and this breaks of course everytime
the Autoconf version is up'ed. So the thinking is: use
"/usr/bin/aut
Jonathan J. Vargas wrote:
ive had several problems with some packages sources, cause they dunt get
updated to the new autoconf versions, and therefore some macros and
other things aren't found and i cant build that package. what i used to
do is rebuild old autoconf versions each time i am gonna ins
Maurice Turcotte wrote:
I am configuring NET-SNMP to cross-compile for another
linux plaform using the uclibc toolchains. When I run
configure, it picks up the correct compiler, but it then
seems to be looking at the header files for the host
system rather than the cross-compiler.
For example, it l
I usually do this by editing configure and inserting a
set -x
just above the part of interest.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
daunting, but worth learning how to do.
Focus in on just the section in question,
and compare it with the configure.in script
to get a higher-level view of what's going on.
'set -x' is also very helpful, but you have to
know where to put it.
- Dan
--
Dan Kegel
http://www.kege
Mike Castle wrote:
Autoconf people, it would be very helpful if autoconf
instituted versioning support, i.e. a way for build
scripts and the like to specify which version of autoconf
to use. ...
I'm not sure I understand why this is such an issue.
When building from source, one rarely changes need
[EMAIL PROTECTED] wrote:
> But, outside of originally broken packaging like that, what other type
of
> local patches would cause similar rerunning all of the autotools? And
> couldn't that be addressed by appropriate use of touch after patch?
I often need to rerun autoconf after applying a patch
.2003 16:45
Subject: Re: please bring back program suffix for autoconf bin files
In article <[EMAIL PROTECTED]>,
Dan Kegel <[EMAIL PROTECTED]> wrote:
>Sure, I could, and maybe I will. But all I need is access to
>a recent autoconf side by side with the old autoconf-2.13.
>All
-2.13 is a must.
- Dan
-Original Message-
From: Ben Pfaff
To: Dan Kegel
Cc: [EMAIL PROTECTED]
Sent: 03.03.2003 16:57
Subject: Re: please bring back program suffix for autoconf bin files
Dan Kegel <[EMAIL PROTECTED]> writes:
> Sure, I could, and maybe I will. But all I need is
lic
link was all I really needed.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Ben Pfaff wrote:
Dan Kegel <[EMAIL PROTECTED]> writes:
That's a nice feature of Debian, but unfortunately,
it does not help in the case of somebody trying to
write a shell script that must invoke autoconf-2.13
no matter what distro (Debian, Cygwin, or Red Hat)
it runs on. For s
Philip Willoughby wrote:
I've been thinking (shock!), and it seems to me that it wouldn't break
anything majorly if we did expand all the $prefix-dependant variables. The
reason being, practically everyone uses automake these days, and automake
defines all installation paths to be prefixed by $DES
In cross-compiling the latest nmap, which uses a recent autoconf,
I noticed that it uses CC both for target stuff and for build-time-only
stuff. Looking around via google, I was surprised to see that autoconf
doesn't seem to have a standard macro to set BUILD_CC!
A proposal was posted four years a
Paul Eggert wrote:
[EMAIL PROTECTED] Invalid names (@sc{lfn})
+Some @acronym{DOS} file names are reserved, and cause problems if you
+try to use files with those names. These names include @file{CON},
[EMAIL PROTECTED], @file{COM1}, @file{COM2}, @file{COM3}, @file{COM4},
[EMAIL PROTECTED], @file{L
Kevin wrote:
First, I just tried doing what the ebuild script would do:
# rm -f configure config.h.in
# sh SMakefile
The SMakefile step fails with:
===
sh-2.05b# sh SMakefile
aclocal -I cmulocal
autoheader
Can't locate object method "path" via package "Request"
at /usr/share/autoconf/A
Andreas Schwab wrote:
Can't locate object method "path" via package "Request" at
/usr/share/autoconf/Autom4te/C4che.pm line 69, line 111.
autoheader-2.58: /usr/bin/autom4te failed with exit status: 1
autoconf
Can't locate object method "path" via package "Request" at
/usr/share/autoconf/Autom4te/C
Russell Shaw wrote:
Hal Snyder wrote:
Ralf Corsepius <[EMAIL PROTECTED]> writes:
BTW: Having to pass "/usr/local" almost always indicates a massively
mis-configured toolchain or configure script.
Sorry if this is an F.A.Q. I see various ways of doing it but wonder,
what is best practice?
What are
Murray Cumming wrote:
I think one needs a separate copy of pkg-config for each toolchain
you want to build things with. (Or at least its data files)...
No, that makes no sense.
Nevertheless, even after reviewing "man pkg-config", I think it's true.
Take a look at the output of "strings /usr/bin/p
1 - 100 of 104 matches
Mail list logo
