Menu
▾
▴
naviserver-devel
|
From: Zoran V. <zv...@ar...> - 2007-07-03 19:04:02
|
zvpb:~/sf/naviserver zoran$ sh autogen.sh --enable-symbols
Running aclocal -I m4
Running autoheader
Running autoconf
configure.in:172: error: possibly undefined macro: AC_TYPE_INT8_T
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.in:173: error: possibly undefined macro: AC_TYPE_INT16_T
configure.in:174: error: possibly undefined macro: AC_TYPE_INT32_T
configure.in:175: error: possibly undefined macro: AC_TYPE_INT64_T
configure.in:177: error: possibly undefined macro: AC_TYPE_UINT8_T
configure.in:178: error: possibly undefined macro: AC_TYPE_UINT16_T
configure.in:179: error: possibly undefined macro: AC_TYPE_UINT32_T
configure.in:180: error: possibly undefined macro: AC_TYPE_UINT64_T
configure.in:182: error: possibly undefined macro: AC_TYPE_INTMAX_T
configure.in:183: error: possibly undefined macro: AC_TYPE_UINTMAX_T
configure.in:185: error: possibly undefined macro: AC_TYPE_INTPTR_T
configure.in:186: error: possibly undefined macro: AC_TYPE_UINTPTR_T
zvpb:~/sf/naviserver zoran$ autoconf -V
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
zvpb:~/dev/tcl_macbinary/unix zoran$ uname -a
Darwin zvpb.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22
20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh
powerpc
zvpb:~/sf/naviserver zoran$
Any ideas why is this so and where are those defined?
Cheers,
Zoran
|
|
From: Stephen D. <sd...@gm...> - 2007-07-03 20:03:20
|
On 7/3/07, Zoran Vasiljevic <zv...@ar...> wrote: > zvpb:~/sf/naviserver zoran$ sh autogen.sh --enable-symbols > Running aclocal -I m4 > Running autoheader > Running autoconf > configure.in:172: error: possibly undefined macro: AC_TYPE_INT8_T > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.in:173: error: possibly undefined macro: AC_TYPE_INT16_T > configure.in:174: error: possibly undefined macro: AC_TYPE_INT32_T > configure.in:175: error: possibly undefined macro: AC_TYPE_INT64_T > configure.in:177: error: possibly undefined macro: AC_TYPE_UINT8_T > configure.in:178: error: possibly undefined macro: AC_TYPE_UINT16_T > configure.in:179: error: possibly undefined macro: AC_TYPE_UINT32_T > configure.in:180: error: possibly undefined macro: AC_TYPE_UINT64_T > configure.in:182: error: possibly undefined macro: AC_TYPE_INTMAX_T > configure.in:183: error: possibly undefined macro: AC_TYPE_UINTMAX_T > configure.in:185: error: possibly undefined macro: AC_TYPE_INTPTR_T > configure.in:186: error: possibly undefined macro: AC_TYPE_UINTPTR_T > zvpb:~/sf/naviserver zoran$ autoconf -V > autoconf (GNU Autoconf) 2.59 > Written by David J. MacKenzie and Akim Demaille. > > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > zvpb:~/dev/tcl_macbinary/unix zoran$ uname -a > Darwin zvpb.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 > 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh > powerpc > zvpb:~/sf/naviserver zoran$ > > Any ideas why is this so and where are those defined? Oh. Looks like these were first added to autoconf 2.59c, released 15 months ago. I added these to try and discourage Vlad from defining ns_int16 etc. redundantly :-) I think even that is a bad idea as nowhere in the code are they actually used. Some external modules make use of them, but that is a crazy dependency! |
|
From: Zoran V. <zv...@ar...> - 2007-07-03 20:41:19
|
On 03.07.2007, at 22:03, Stephen Deasey wrote: > I think even that is a bad idea as nowhere in the code are they > actually used. Some external modules make use of them, but that is a > crazy dependency! Hm... if you get them out, nothing will break? Only modules? Which modules? |
|
From: Vlad S. <vl...@cr...> - 2007-07-03 20:45:01
|
I will update modules if that is the conclusion Zoran Vasiljevic wrote: > On 03.07.2007, at 22:03, Stephen Deasey wrote: > >> I think even that is a bad idea as nowhere in the code are they >> actually used. Some external modules make use of them, but that is a >> crazy dependency! > > Hm... if you get them out, nothing will break? > Only modules? > Which modules? > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Stephen D. <sd...@gm...> - 2007-07-03 21:01:18
|
On 7/3/07, Vlad Seryakov <vl...@cr...> wrote: > I will update modules if that is the conclusion The problem with ns_int8 etc. is that there already is a perfectly good name for it. If int8_t does not exist, then the best strategy is to just define that, not some other name. It's basically equivalent. The advantage is that our code becomes more standard and readable. We doe have some ns_whatever code, but that tends to be a more or less functionally identical wrapper which is either thread safe or performs some error handling. Another reason no to overload the ns_* C name space. The AC_TYPE_INT8_T macros handle this -- they check and define their own versions if not present. We need to move towards each module having it's own configure script... |
|
From: Stephen D. <sd...@gm...> - 2007-07-03 21:07:08
|
On 7/3/07, Zoran Vasiljevic <zv...@ar...> wrote: > > On 03.07.2007, at 22:03, Stephen Deasey wrote: > > > I think even that is a bad idea as nowhere in the code are they > > actually used. Some external modules make use of them, but that is a > > crazy dependency! > > Hm... if you get them out, nothing will break? > Only modules? > Which modules? You're also going to have trouble with AC_TYPE_INTPTR_T and AC_TYPE_UINTPTR_T. Is autoconf-2.60 too painful? Does a platform we support not have intptr_t and unintptr_t? |
|
From: Zoran V. <zv...@ar...> - 2007-07-03 21:14:18
|
On 03.07.2007, at 23:07, Stephen Deasey wrote: > > Is autoconf-2.60 too painful? Did you try to compile Tcl with that (2.60)? I do not know about Darwin and 2.60 autoconf. I maybe needing to test that. At the moment I can live with commenting those out (just did and it passed). Cheers Zoran |
|
From: Stephen D. <sd...@gm...> - 2007-07-03 21:29:04
|
On 7/3/07, Zoran Vasiljevic <zv...@ar...> wrote: > > On 03.07.2007, at 23:07, Stephen Deasey wrote: > > > > > Is autoconf-2.60 too painful? > > > Did you try to compile Tcl with that (2.60)? > I do not know about Darwin and 2.60 autoconf. > I maybe needing to test that. Only applies if you build Tcl from CVS, right? You can usually install multiple versions of autoconf at the same time. Fedora has autoconf (2.61) and autoconf213 (2.13) available by default. > At the moment I can live with commenting > those out (just did and it passed). So they're at least present on OSX. If they're available on everything we care about there's no point testing... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X