ol that it extracts from xmkmf to see if it is already
defined in confdefs.h. This should probably be done anyhow.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+ 408 261-6630 | g g d
AC_PREREQ(2.14.1)
from textutils-2.0/m4/jm-macros.m4, but I thought I should point
this out so that you can resolve it in the your releases,
presumably either with a new release of textutils that does not
require autoconf 2.14.1 or with a release of autoconf 2.14.1 or
newer.
Adam J. Richter
" defined to be the empty string.
In jade's case, that causes the compilation to bomb out, so the only
effect of AC_C_CONST. I have attached a suggested patch for jade below.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
n autoconf-2.50 bug, so
I am cc'ing this to [EMAIL PROTECTED] for their information.
Even if this is an autoconf bug, I believe that applying the
following patch to CommonC++ should be harmless, so I recommend that
you do it anyhow, to work with the existing autoconf-2.50 release in
and the main configure.in script, would still start with
AC_INIT(configure.in).
Am I duplicating someone else's effort? If not, does this
look good? Should I develop a patch?
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
ompatability. A second best solution, which would not maintain
backward compatability, would be to make a public interface
AC_CHECK_TYPE_OLD.
Anyhow, I don't mean to start a flame war about this. I just
want to to report my experiences with autoconf-2.5x, which you
e many of your macros generate warnings or even abort if
they are called more than once and many user macros may have undesired
side effects and, of course, will result in slower ./configure run
time if they are called more than once, making use of autoconf less
desirable in comparison to
efore all of the code that has this problem is found and fixed.
If you want to change the semantics of AC_CHECK_TYPE, can't you at
least provide the old semantics by some public function?
Anyhow, I appreciate your reply. If somebody does have time
to document the actual underlying te
necessarily an autoconf/m4sugar macro.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "
in gcc cvs.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
Sorry, I forgot to attach the actual patch to my previous
email.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
d a
macro by that name is *not* defined (not even locally in aclocal.m4).
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of Ameri
if you do not work
around the problem. The workaround is not only very simple; it's also
an improvement. ASM_xxx is more mnemonic than AS_x and more
consistent with other flags related to assember issues in gcc. So, I
would still recommend that you apply my patch.
Adam J. Richter
or,
but I'm not quite clear on what change to make to effect that.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax
14 matches
Mail list logo
