When I use:
AC_CHECK_FUNC(gettimeofday, , AC_MSG_ERROR(Missing mandatory function))
autoconf tests it exists with:
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char gettimeofday();
On all platforms, everyth
On Wednesday 24 January 2001, at 13 h 40, the keyboard of Alexandre Oliva
<[EMAIL PROTECTED]> wrote:
> > Because -L was put too late.
>
> It should probably be in LDFLAGS, not LIBS.
You're right and it works fine that way. Thanks.
| Akim,
| I installed that version of autoconf and put your script in a file
| called "foo":
|
| stenn@porkypine> sh foo
| configure: loading cache /dev/null
| configure: creating ./config.status
| config.status: creating file
| config.status: creating header.h
| BAR
| /* header.h. Generated au
Revision 1.62 to autoreconf.sh seems to make sure it only searches for
configure.ac and not configure.in. Please apply the patch below:
/assar
Index: autoreconf.sh
===
RCS file: /cvs/autoconf/autoreconf.sh,v
retrieving revision 1.6
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> Why can't I use AS_* macros from configure.in? Derek
??? I guess you are using a new autoconf with old lib files. Either
use an *installed* CVS Autoconf, or be usre to point to the location
of the lib files (typically autoconf.m
| Hi,
Salut Nicolas!
| I just tried CVS autoconf on Tru64 unix v5.1 computer and noticed a
| failure of AC_CACHE_CHECK if an autoconf site file exists in default
| prefix location `/usr/local'. without this `config.site' defaults file
| all tests are successful.
|
| njoly@medusa [~]> cat /usr/
> Revision 1.62 to autoreconf.sh seems to make sure it only searches
> for configure.ac and not configure.in. Please apply the patch
> below:
Pfff! Of course! Thanks!
> Should we (i) make sure not to use config.site in the test suite, or
> (ii) have this test grep out this message?
>
> It sounds good to have the test suite protected from the user, but
> OTOH, it sounds good to have a means to check configures using the end
> user's config.site.
I'd vote for (
I want to check for the existence of a library not just a function of the
library as AC_CHECK_HEADERS does. Is there a way to do it?
Stephen
--
Buyer's Guide for a Operating System:
Don't care to know: Mac
Don't mind knowing but not too much: Windows
Hit me! I can take it!: Linux
I'm looking for some advice on how to check for ld.
Currently the configure script for Pilot-Link has a negative
result when searching for ld on OS/2 even though it exists on
the path.
The check is done using:-
ac_prog=`($CC -print-prog-name=ld)
which returns:-
C:\EMX\BIN\ld.exe
but is then
Hello, Akim!
> Running autoscan on (configured) CVS Automake gives:
>
> warning: missing AC_CHECK_HEADERS([malloc.h]) wanted by: ansi2knr.c:157
> warning: missing AC_CHECK_HEADERS([stdlib.h]) wanted by: ansi2knr.c:150
> warning: missing AC_CHECK_HEADERS([string.h]) wanted by: ansi2knr.c:128
>ans
On Jan 25, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Should we (i) make sure not to use config.site in the test suite, or
> (ii) have this test grep out this message?
(ii)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer ao
On Jan 25, 2001, Stephen Torri <[EMAIL PROTECTED]> wrote:
> I want to check for the existence of a library not just a function of the
> library as AC_CHECK_HEADERS does. Is there a way to do it?
How about AC_CHECK_LIB or AC_HAVE_LIBRARY?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.u
Akim,
stenn@porkypine> sh foo
configure: loading cache /dev/null
configure: creating ./config.status
config.status: creating file1
config.status: creating file2
BAR
BAR
stenn@porkypine>
Harlan
Alexandre Oliva wrote:
>
> On Jan 21, 2001, Matthew Schalit <[EMAIL PROTECTED]> wrote:
>
> > Is this because I have no CXX or F77 at this point?
>
> Quite likely. Would you give CVS autoconf a spin and see how it goes?
> It should probably handle the lack of these programs more gracefully.
>
On Jan 26, 2001, Matt Schalit <[EMAIL PROTECTED]> wrote:
> I'm concerned that the CVS version will have more bugs in it.
> If it's not stable, then I thought it's not stable.
Maybe using yesterday's candidate release, just taken out of the CVS
tree, would make you feel better? We'd rather hash
Akim Demaille wrote:
>
> Should we (i) make sure not to use config.site in the test suite, or
> (ii) have this test grep out this message?
I vote for not using an installed config.site, because the test
suite should be self-contained and a config.site test within the
testsuite should be based on
Alexandre Oliva wrote:
>
> On Jan 26, 2001, Matt Schalit <[EMAIL PROTECTED]> wrote:
>
> > I'm concerned that the CVS version will have more bugs in it.
> > If it's not stable, then I thought it's not stable.
>
> Maybe using yesterday's candidate release, just taken out of the CVS
> tree, would
18 matches
Mail list logo