[Gllug] continuing the autoconf saga... AC_FUNC_MALLOC

[Nix]

On Mon, 1 Jul 2002, Stig Brautaset uttered the following:
> * Nix <nix at esperi.demon.co.uk> spake thus:
>> On Sat, 29 Jun 2002, Stig Brautaset said:
>> > Although sometimes it claims to be 2.13 (debian will not let me install
>> > 2.5X without installing 2.13 as well). I imagine it is due to some
>> > "clever" wrapper that tries to figure out what you need or something.
>> 
>> Yes, it is. Call `autoconf-2.53' directly if you want to force it,
>> although if your configure.ac is called, um, configure.ac, or you have a
>> suitable AC_PREREQ, it should determine the right autoconf version for
>> you.
> 
> Should I use `configure.ac' instead of `configure.in'? "info autoconf"
> just says to use one or the other, AFAICS it does not say why. Is `.ac'
> the new preference?

Yes. The node `Writing configure.ac' says:

,----
|    Previous versions of Autoconf promoted the name `configure.in',
| which is somewhat ambiguous (the tool needed to produce this file is not
| described by its extension), and introduces a slight confusion with
| `config.h.in' and so on (for which `.in' means "to be processed by
| `configure'").  Using `configure.ac' is now preferred.
`----

so it's a clarity thing (I imagine at least slightly to reduce the
confusion with Cygnus configure, which has a `configure' and a
`configure.in' which are both handwritten).

>> >> It works for me with autoconf-2.53, given a configure.ac like this:
>> >> AC_INIT(foo,0.01)
>> >> AC_CONFIG_HEADERS(config.h)
>> >> AC_PROG_CC
>> >> AC_PROG_CC_STDC
>> >> AC_FUNC_MALLOC
>> >> AC_OUTPUT
>> > 
>> > This works for me too. But, it wouldn't work with my configure.in --
>> > after a bit of trial and error it turns out the AC_FUNC_MALLOC macro
>> > does not like to be used after the AC_CHECK_LIB macro.. 
>> 
>> *boggle* What are you AC_CHECK_LIBbing?
> 
> Eh... yalll :) 

An interesting name. :)

It sounds like whatever that library was it broke all links carried out
after it, or something.

> I wrote `yet another linked-list library' as an exercise, but it turned
> up to be so bug-ridden that I scratched it and started over again.

Been there :) (well, except for the scratching part).

So we have here a linked list library that broke linking. ;}

> (There's probably a myriad of linked-list libraries around, but I wanted

Dozens. glib, Qt, libiberty, the Standard C++ library and virtually any
other library you throw a stick at will have one :)

> to code my own for the experience. Also, it is a suitable project to
> teach me a bit about how libtool works in conjunction with
> autoconf/automake.)

There is that.

> Since I only need a malloc that will behave correctly with malloc(n),
> where n > 0,

(the common case!)

>              would it be bad of me to axe this test altogether? Surely
> *an* incarnation of malloc will be present on any system that defines
> STDC_HEADERS? :)

I'd hope so :) if you were a total paranoid you could AC_CHECK_FUNC
for malloc...

-- 
`What happened?'
                 `Nick shipped buggy code!'
                                             `Oh, no dinner for him...'


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug