Bill Moseley wrote:
I don't really understand why libxml2 got linked in statically and not
libz. I assume that's an issue in my Makefile.am file or how we setup
libz and libxml2 in our configure script.
It's probably because libxml2 itself is installed using libtool (and
thus there is a libxml2.l
Roger Leigh wrote:
and these work well. What it doesn't do is let me use features such
as mixed declarations and code. These require you to use "gcc
-std=c99" or "c99" or similar, and I can't enable this portably. If
autoconf could find out how to put a given compiler into C99 mode,
that would b
Roger Leigh wrote:
I'd rather avoid this complexity. Isn't it easy enough to abort based
on the value of ac_cv_prog_cc_c89 (or whatever)?
Yes, but I didn't know if users were allowed access to those
internals. I've reverted this (but kept it for internal use).
From a plain-old-user's point of vi
Ralf Wildenhues wrote:
I don't know if there are compilers which actually error out on implicit
function declaration when in C99 mode (with no other options).
The risk would certainly be there for people who enable -Werror (or the
equivalent for non-gcc compilers) early in their configure script a
Paul Eggert wrote:
Can you test Autoconf with 'gcc -std=c99 -pedantic-errors -Werror'?
That might catch some of the problems we're worried about.
I don't currently use C99-isms in my projects, because I didn't have a
clean way to test for compatibility in my distributions. That's why I'm
glad to
Paul Eggert wrote:
Part of the motivation for keeping that stuff hidden is that we don't
want people to switch based on whether our macro "thinks" the compiler
is "C99" or "C89" or "not". They should switch based on the
particular feature that they need.
Hmm... I see your point, but wouldn't that
Paul Eggert wrote:
the project could suddenly stop building on systems it used to build on
because that compiler doesn't support all C99 features.
That's fine, for projects that want to assume C99. Or perhaps I'm
misunderstanding your scenario?
Nope, you've understood it properly. I have had more
Sam Steingold wrote:
I want it to be error because I cannot pass
void my_callback (const DB_ENV* dbe, const char *errpfx, const char *msg);
instead of
void my_callback (const char *errpfx, char *msg);
so: how do I turn the warning into a failed compilation?
(the result: above should be "no", no
Bob Friesenhahn wrote:
This approach only works with GCC and will cripple building most software.
I wasn't suggest adding it to the CFLAGS used to build the application,
only for running the test the OP asked about. But that's true, it would
be GCC specific.
__
Stepan Kasal wrote:
even though `--without-gcclib' might sound better to a newcomer, the
convention is that:
`--without-gcclib' means that gcclib is not installed on the host system
Or alternatively, it means 'act as though gcclib is not installed, even
if it is'.
___
I want to include a modified copy of one or two libtool-related macros
in my source package. I have copied the relevant macros from
/usr/share/aclocal/libtool.m4 into acinclude.m4, and made my changes.
However, aclocal puts the contents of acinclude.m4 into aclocal.m4
_before_ macros from its o
I have created an m4 directory in my source tree, and put some macros
downloaded from the autoconf macro archive in there. I also added
AC_CONFIG_MACRO_DIR([m4])
to configure.ac, and this causes autoreconf to (correctly) put
libtool.m4 and ltdl.m4 into the m4 directory.
However, aclocal does n
Dave Kirkby wrote:
Hi,
I want to allow a configure script to be told the number of CPUs
to build some software for. The manual says 'AC_ARG_ENABLE' can read an
agument, but I can't for the life of me see how to get it. I basically
want to have something AC_DEFINE CPUS to be an integer read whilst
Bob Friesenhahn wrote:
Using --with-foo=/path/to/foo is not Autoconf standard. It is a
popular scheme added by many packages since it seems more
user-friendly. However, the portability of this depends on how
sophisticated the implementation is. It may work on just a few
operating systems or wit
Albert Chin wrote:
That doesn't help during the ./configure run. Bruno Haible (gettext
maintainer) has a solution for what you want:
http://mail.gnu.org/archive/html/autoconf/2002-05/msg00124.html
Wow, I never saw that before, that would be very nice. I too have
struggled with trying to use lib
Anthony N. Frasso wrote:
base# make
Making all in bin
rm -f autom4te autom4te.tmp
Using $< in a non-suffix rule context is a GNUmake idiom (line 484 of
Makefile)
*** Error code 1
GNU software usually requires GNU make. If you don't already have gmake
on your system, you'll need to install make-3.
Bob Friesenhahn wrote:
On Tue, 2 Mar 2004, Kevin P. Fleming wrote:
GNU software usually requires GNU make. If you don't already have gmake
on your system, you'll need to install make-3.80 before proceeding.
This statement is not true. Proper GNU software does not normally
require G
17 matches
Mail list logo
