27;s the deal? is this a bug in autoheader or what? The autoconf
docs do not seem to say anything about this.
Mo Dejong
Red Hat Inc.
++ onto that? Why
will autoconf not check for the cross given in the
--target argument?
Mo Dejong
Red Hat Inc.
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 20, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > But when I try to run ./configure with a target argument, it does not
> > use the right compiler.
>
> --target is used only for compilers, linkers, etc, to spe
athname_style.html
This test will break if you use a cross compiler with cygwin.
So who is at fault here? Should autoconf know about the host
it is running under and the cross "host" info?
Mo Dejong
Red Hat Inc.
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong &
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > There are a couple of problems with this approach. It compares the
> > result of running config.guess to what the user passed in with
> > --host, but I am not sure
The bug was in acgeneral.m4. I replaced a "host" with $1 and
switched the order of the tests so that config.guess gets
run when checking host or build types of THINGS.
2000-04-20 Mo DeJong <[EMAIL PROTECTED]>
* acgeneral.m4 (AC_CANONICAL_THING):
Fi
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > The documentation seems to indicate that the only macro I
> > would need was AC_CANONICAL_HOST? Are the docs wrong about that?
>
> You'd seldom need inform
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > So if it should have been "internal" then why do I need to add the
> > AC_CANONICAL_BUILD macro to my configure.in file to get cross
> > compiling to
On 21 Apr 2000, Alexandre Oliva wrote:
> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > On 21 Apr 2000, Alexandre Oliva wrote:
> >> On Apr 21, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> >>
> >> > So if it sho
ndor
> | $1_os=$ac_cv_$1_os
> | ...
> | ])# _AC_CANONICAL_THING
If the build test was always done then the result of that could
be used when figuring out the host. The host would not need to
do another config.guess in that case.
I hope that helps
Mo DeJong
Red Hat Inc.
> Also, how do we
instead
of the current approach which is to silently fail unless the
BUILD, TARGET, or HOST macro had been run.
Mo Dejong
Red Hat Inc.
> This is why I would like to reiterate a proposal I made: get rid of
> AC_CANONICAL_{BUILD, TARGET, HOST}, and provide only
> AC_CANONICAL_SYSTEM.
>
>
On Fri, 21 Apr 2000, Earnie Boyd wrote:
> --- Pavel Roskin <[EMAIL PROTECTED]> wrote:
> -8<-
> > Well, this thread began with a message from Mo DeJong <[EMAIL PROTECTED]>
> > (Cygnus dot Com !!!) who tried to use --target where is should have been
> > --h
d make it a lot
easier to debug this sort of problem because the rld errors would
show up in the log file.
thanks
Mo DeJong
Red Hat Inc.
sistent in this definition. Tests that require compiled
> programs to be executed are not run as long as a trivial program fails to
> run.
>
> Regards,
> Pavel Roskin
Mo DeJong
Red Hat Inc.
Perhaps this is a stupid question, but did you remember to add the
following to the top of your configure.in file? I made a simmilar
mistake when writing my configure.in.
AC_CONFIG_HEADER(config.h)
Mo Dejong
Red Hat Inc.
On Tue, 25 Apr 2000, Lars Hecking wrote:
>
> $ autoheader --v
conf that
$host != $build and is therefore a cross compile.
Why don't we just merge the AC_CANONICAL_BUILD macro
into the AC_CANONICAL_HOST macro and not print out
the --build option. The --host option would still
be used to give the cross triple and the --target
option would not showup in the output unless
AC_CANONICAL_TARGET was used in configure.in.
Mo Dejong
Red Hat Inc.
On Tue, 25 Apr 2000, Pavel Roskin wrote:
> Hello!
>
> On Tue, 25 Apr 2000, Mo DeJong wrote:
>
> > I am still confused about what situation would actually
> > call for AC_CANONICAL_BUILD without also calling
> > AC_CANONICAL_HOST? Also, wouldn't I always need
f I pass --host=CROSS-TRIPLE that should tell the system
that the host is different than the build so it is a cross compile, right?
> - remove the support of HOST on the command line, because it is
> incorrect to map this HOST to a virtual --host=HOST
>
> Akim
Mo Dejong
Red Hat Inc.
bigendian... configure: error: cannot
run test program while cross compiling
It seems clear that the AC_TRY_RUN does not have an argument for
the cross compile case. Can we at least get agreement that this
AC_C_BIGENDIAN macro is in fact broken?
Mo Dejong
Red Hat Inc.
(u.c[sizeof (long) - 1] == 1);
-}], ac_cv_c_bigendian=no, ac_cv_c_bigendian=yes)
+}], ac_cv_c_bigendian=no, ac_cv_c_bigendian=yes,
ac_cv_c_bigendian=unknown)
fi])
if test $ac_cv_c_bigendian = yes; then
AC_DEFINE(WORDS_BIGENDIAN, 1,
Mo Dejong
Red Hat Inc.
e: *** [all-recursive] Error 1
I have nothing against this help2man program but it either needs to
be included in the CVS and built if not found or just not required
during the install step.
How should we fix this problem?
Mo Dejong
Red Hat Inc.
On 27 Apr 2000, Akim Demaille wrote:
> >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> Why does autoconf require another program to install?
>
> Because you're referring to the CVS tarball, hence you shall be ready
> to b
finding
i386-mingw32msvc-strip given "strip" as the tool name.
Mo Dejong
Red Hat Inc.
On 26 Apr 2000, Akim Demaille wrote:
> >>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>
> Akim> It is Ian who suggested twice that in thes
n't
we put these info a config.compare script that can be improved over time?
Mo Dejong
Red Hat Inc.
> 1) build != host -- That won't work because firstly config.sub isn't quite
> that smart to guarantee lexical equalness in all cases, the problem often
> being the vendor part be
l just `touch' the output file.
Are you saying that this "missing" script is actually part of
the automake dist? So I would need to find it and submit
patches to that project?
Mo DeJong
Red Hat Inc.
> If you want to give it a try, you probably should do that with the
> `missing' which is in CVS Automake. Autoconf will import it then.
>
> Akim
Why not just include it in the CVS? It is really small. Anything that
will make autoconf 2.14 easier to install is a good thing.
help2man-1.020.tar.gz 32 k
Mo Dejong
Red Hat Inc.
On Mon, 1 May 2000, Pavel Roskin wrote:
> Hello!
>
> Shouldn't Autoconf sources mention som
system, fixme])
That worked, but I never got around to patching autoheader to fix
the real problem.
Mo Dejong
Red Hat Inc.
On Fri, 5 May 2000, R Leigh wrote:
> Dear all,
> I apologise in advance if this message is sent to the wrong forum.
>
> I have been using the autoconf/make
o $foo_cmd
])
FOO
Any ideas?
Mo Dejong
Red Hat Inc.
undefined macros:
configure.in:5:foo_cmd="$JAVAC $JAVAC_FLAGS Test.java"
Any ideas?
Mo Dejong
Red Hat Inc.
l/kaffe
--enable-jacl --with-jikes=/home/mo/project/build/jikes/src/jikes"
debug=false
me=`echo "$0" | sed -e 's,.*/,,'`
SHELL=${CONFIG_SHELL-/bin/sh}
Mo Dejong
Red Hat Inc.
find JDK info for many platforms as well
as Kaffe. This would also be an idea place to add support
for gcj as a standard Java target.
Mo Dejong
Red Hat Inc.
. It is
also a waste of my time to put these macros on the macro archive.
The macro archive is not the place for language support in autoconf!
If you want to get folks using and improving Java macros, you need to
make them part of the "standard" install.
Mo Dejong
Red Hat Inc.
ro def for AC_CHECK_TOOL_PREFIX
in case older versions of tools use it?
thanks
Mo Dejong
Red Hat Inc.
On 30 May 2000, Alexandre Oliva wrote:
> On May 29, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > How much interest would there be in adding Java to the
> > autoconf supported languages?
>
> It'd certainly be appreciated. But we have to be careful, sinc
formation we can get in that file, the better off we are.
>
> Thanks, as always, for a great tool.
>
> Regards,
> --keith
Keith makes a good point. I ended up creating my own AC_MSG_LOG
macro that would write a message to the console and the log file
because of this exact problem. I don't see any reason the config.log
should not contain all the output instead of just "checking yes|no".
Mo Dejong
Red Hat Inc.
e src/Makefile"
...
# Files that config.status was made for.
config_files="\
$PROCESS_FILES"
...
# Handling of arguments.
'$PROCESS_FILES' ) CONFIG_FILES="$CONFIG_FILES $PROCESS_FILES" ;;
How can this be fixed?
Mo DeJong
Red Hat Inc
be Cygnus
configure.
AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
])# AC_CONFIG_AUX_DIRS
I am stumped. Is something wrong with the
AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT]) such
that is no longer includes the text from
AC_CONFIG_AUX_DIR_DEFAULT?
Mo DeJong
Red Hat Inc
On 6 Jun 2000, Akim Demaille wrote:
> >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> I am stumped. Is something wrong with the
> Mo> AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT]) such that is no longer
> Mo> includes the text from A
$(CXXLINK) $(jikes_LDFLAGS) $(jikes_OBJECTS) $(jikes_LDADD) $(LIBS)
.cpp.o:
$(CXXCOMPILE) -c $<
Is this a problem that needs to be fixed in automake or am
I just missing something?
Mo Dejong
Red Hat Inc.
for float.h... /home/mo/project/jikes/configure: Can't reopen
pipe to command substitution (fd 4): No child processes
yes
checking for iconv.h... no
checking for windows.h... yes
It my box hosed or what?
Mo Dejong
Red Hat Inc.
est.o
is larger than the first one. If -g adds debug info to conftest.o
then it is going to get bigger. If -g is not known to the compiler,
it should produce a .o file that is exactly the same size. That
way you could avoid all the stdio+stderr junk.
Mo DeJong
Red Hat Inc.
On 16 Jun 2000, Akim Demaille wrote:
> >>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> Alexandre> On Jun 14, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> >> Perhaps this is a silly idea, but why don't you just
On Fri, 16 Jun 2000, Thomas E. Dickey wrote:
> On Fri, 16 Jun 2000, Mo DeJong wrote:
> > Well, something like the following patch would work.
> ...something like (there are two places the look like problems):
>
> > +ac_cv_prog_cc_g_smaller=`od conftest_smaller.o`
>
>
On 16 Jun 2000, Akim Demaille wrote:
> >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> That might not be a bad idea. I don't like to depend on od just to
> Mo> get the size of a file. Am I just missing something? Is there an
>
same. I have appended a patch to
fix that problem.
Mo DeJong
Red Hat Inc
Index: acgeneral.m4
===
RCS file: /cvs/autoconf/acgeneral.m4,v
retrieving revision 1.488
diff -u -r1.488 acgeneral.m4
--- acgeneral.m42000/06/16 17:40:44
hecking for KCC... (cached) g++
checking for RCC... (cached) g++
checking for xlC_r... (cached) g++
checking for xlC... (cached) g++
checking for g++... (cached) g++
checking whether we are cross compiling... no
checking whether the C++ compiler works... yes
That is really ugly!
Mo Dejong
Red Hat Inc.
On Sat, 17 Jun 2000, Peter Eisentraut wrote:
> Mo DeJong writes:
>
> > How about merging them into a more generic AC_PROG_COMPILER_G macro
> > that could test any compiler for the -g flag?
>
> That would be nice because then we can undefine it so that AC_PROG_CC et
&g
On 17 Jun 2000, Alexandre Oliva wrote:
> On Jun 16, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > I like that wc -c a lot better, we can just do this. Of course
> > this depends on the output format of wc, is it going to
> > be the same everywhere?
>
&g
On 18 Jun 2000, Alexandre Oliva wrote:
> On Jun 18, 2000, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>
> > On Jun 18, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> >> Ok, how about this patch? It uses cmp instead of wc.
>
> > Nope, you must use `tai
C_CONFIG_AUX_DIR_DEFAULT])dnl < RIGHT HERE
])# AC_CONFIG_AUX_DIRS
I could be off in left field here, but should this AC_PROVIDE be here?
Mo DeJong
Red Hat Inc
NICAL_HOST
AC_CANONICAL_BUILD
AC_PROG_LIBTOOL
Mo DeJong
Red Hat Inc
is a variable called cross_compiling that will be set to "yes" if
the user passed --host=... and "no" otherwise.
Please post a note to the list if there is anything that is still
confusing about this. It should be easy to understand as long as
we explain it properly.
Mo DeJong
Red Hat Inc
rror 1
make[1]: Leaving directory `/mnt/image/build_egcs/gcc'
make: *** [all-gcc] Error 2
A note about this macro in the ChangeLog states:
Removed their autoheader template. They are now documented with their
own AC_DEFINE.
Any idea how I should go about fixing this?
Mo DeJong
Red Hat Inc
What could be older than Ultrix?!! ;)}
changequote(,)dnl
# Character class describing NM global symbol codes.
...
It goes one like that and does not generate a working ./configure.
Mo DeJong
Red Hat Inc
ast be some sort of AC_DONT_USE_HOST_KLUDGE
macro that I could put into a new configure.in so that new
programs do not need to be burdened by this crufty old stuff?
Mo DeJong
Red Hat Inc
,
autotools releases only happen every year or
two. If we don't make this --host change now,
both automake and libtool will keep using the
old way for many years to come.
Mo DeJong
Red Hat Inc
o host.
I thought there was already a switch for cygnus behavior.
--cygnus assume program is part of Cygnus-style tree
Would it be possible to put this old style --host is really
--build stuff into the set of options activated when --cygnus
is passed in?
Mo DeJong
Red Hat Inc
ecking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
...
( Score! This next bit is what was failing )
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
...
% mak
On 26 Jun 2000, Alexandre Oliva wrote:
> On Jun 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > I thought there was already a switch for cygnus behavior.
>
> > --cygnus assume program is part of Cygnus-style tree
>
> I've never seen this opti
g
it on a machine other than the host it will
run on. Compilation packages accept a
configuration option `--build=hosttype' for
specifying the configuration on which you
will compile them, in case that is different
from the host.
See what I mean?
Mo DeJong
Red Hat Inc
)
configure:AC_LIBTOOL_CXXAM_DEPENDENCIES(CXX)
Any ideas?
Mo DeJong
Red Hat Inc
d you try "./configure --build=i386-linux" ?
That should do what you want.
Mo DeJong
Red Hat Inc
... (cached) g++
checking for cc++... (cached) g++
checking for cl... (cached) g++
checking for KCC... (cached) g++
checking for RCC... (cached) g++
checking for xlC_r... (cached) g++
checking for xlC... (cached) g++
checking for g++... (cached) g++
This is really ugly!
Mo DeJong
Red Hat Inc
build
> defaulting to host.
If you go back to the old way of doing it, then I doubt it
will ever get changed. Folks are going to trot out the
same old "It is just wrong to change it, we have been doing
it this way for years" argument and you are right back where
you started.
Mo DeJong
Red Hat Inc
havior in common with them. But
> I probably wouldn't fight for that in, say, two years' time.
I don't understand how you can make the claim that switching back is
"more important for developers in general than for Cygnus".
I can see how it is important to use, it means we will
not have to update any configure scripts for another 2 years.
Mo DeJong
Red Hat Inc
people be more willing
to pass --build instead of --host two years
from now? Do we just hope that they are
going to get sick of messages like:
"warning: You passed --host and we are going
to change what this argument does in
a couple of years. You will thank us
when we do because you will not have
to see this silly warning all the time".
Mo DeJong
Red Hat Inc
buy a TV to see that!
The other one I would like to see is:
(Old School) RMS
vs.
(Perl loving) T. Tromey
The showdown: Will automake be rewritten in guile?
Mo DeJong
Red Hat Inc
On 28 Jun 2000, Alexandre Oliva wrote:
> On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > But, there is nothing to update! We have already addressed the
> > issue of toplevel configure passing both --build and --host
> > down to sub-configures.
>
Boy, this is funny. While this whole --host flame was
raging, I came across this note on the mingw mailing
list. This is just further proof that new users do
not understand the old cross compile semantics and
that the docs don't help much.
Mo DeJong
Red Hat Inc
Hi All,
I noticed the othe
ve just to do a cross compile:
./configure --build=i686-pc-linux-gnu --host=i386-mingw32
Mo DeJong
Red Hat Inc
host system.
./configure --host=i386-mingw32
It is not as clean as the original solution
but it should maintain backward compatibility
and let people use both the old and new
semantics.
Mo DeJong
Red Hat Inc
On 28 Jun 2000, Alexandre Oliva wrote:
> On Jun 28, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > Why can't we just switch the value of $build over to the output of
> > config.guess for the build system when we try to detect a cross
> > compiler and the
Hi all.
I think the following seem a little off.
% ./config.status --recheck
...
creating ./config.status
% ./config.status
creating Makefile
creating tkConfig.sh
I think ./config.status --recheck should also regenerate the
Makefile from .in file. What do you think?
Mo DeJong
Red Hat Inc
Hi all.
I have noticed that there are a number of packages that
include extra code to test for and enable the -pipe
option to gcc. I think it might be a good idea to add
the -pipe option to the default CFLAGS if gcc is detected and
the -pipe option is supported. What do you think?
Mo DeJong
Red
echo "INSIDE FALSE gettimeofday TESTS!"
echo "configure:4005: checking for gettimeofday" >&5
It does not seem to make it into the true of false
branch for this if statement. I am really stumped here.
If I run autoconf 2.13 over this exact same configure.in
I get a configure sc
On Mon, 3 Jul 2000 [EMAIL PROTECTED] wrote:
> On Mon, 3 Jul 2000, Mo DeJong wrote:
>
> > Hi all.
>
> Hi.
>
> > I have noticed that there are a number of packages that
> > include extra code to test for and enable the -pipe
> > option to gcc. I think
checking for gettimeofday declaration... $ECHO_C" >&6
cat >conftest.$ac_ext <
EOF
if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
egrep "gettimeofday" >/dev/null 2>&1; then
echo "configure:4024: result: present" >&5
echo "${ECHO_T}present" >&6
else
echo "configure:4027: result: missing" >&5
echo "${ECHO_T}missing" >&6
cat >>confdefs.h <<\EOF
#define GETTOD_NOT_DECLARED 1
EOF
fi
rm -f conftest*
Mo DeJong
Red Hat Inc
On Mon, 3 Jul 2000 [EMAIL PROTECTED] wrote:
> On Mon, 3 Jul 2000, Mo DeJong wrote:
>
> > if test -n "$GCC"; then
> > AC_MSG_CHECKING([if the compiler understands -pipe])
> > OLDCC="$CC"
> > CC="$CC -pipe"
> >
On 3 Jul 2000, Alexandre Oliva wrote:
> On Jul 3, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > I think it might be a good idea to add the -pipe option to the
> > default CFLAGS if gcc is detected and the -pipe option is
> > supported. What do you think?
>
On 4 Jul 2000, Alexandre Oliva wrote:
> On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > If it makes the build go faster for 99% of the folks out there, we
> > should use it.
>
> Does it? I really don't know. Taking your argument further, why
1.712
+++ ChangeLog 2000/07/04 09:25:55
@@ -1,3 +1,12 @@
+2000-07-04 Mo DeJong <[EMAIL PROTECTED]>
+
+ * acgeneral.m4 (_AC_INIT_PARSE_ARGS, AC_CHECK_TOOLS): Change
+ warning message printed when only --host is given. Fix printing
+ of multiple compiler cache values, us
n't forget Tcl :)
The next release of Tcl is going to add OO support. Those python
folks are going to have to quit with the "but our tool has OO" stuff.
Mo DeJong
Red Hat Inc
On 4 Jul 2000, Alexandre Oliva wrote:
> On Jul 4, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> > configure: WARNING: For backwards compatibility, --build will be set to --host
> > if a cross compiler can not be found
>
> This is not true. Akim committed
to change to --build.
It also sort of "tosses out" whatever is passed as the
argument to --host if it is not used to detect a cross compiler.
Mo DeJong
Red Hat Inc
se of
--build=TRIPLE --host=X-TRIPLE when folks can just use
--host=X-TRIPLE by itself.
Mo DeJong
Red Hat Inc
(I also attached the patch file, in case that helps)
Index: ChangeLog
===
RCS file: /cvs/autoconf/ChangeLog,v
retrieving rev
for cross compiling is:
"To use a hosted cross compiler, just pass --host."
Mo DeJong
Red Hat Inc
-mingw32msvc --with-tcl=/home/mo/project/build/tcl_Xmingw
--with-tk=/home/mo/project/build/tk_Xmingw --prefix=/tmp/tkgs_Xmingw
--no-create --no-recursion
Also, if CFLAGS is not set to anything by the user, why should
it get passed into the ./configure on the command line?
Mo DeJong
Red Hat Inc
the compiler is a cross compiler. The way you know it is a cross
compiler is the same old "try to run it" test.
Mo DeJong
Red Hat Inc
compatibility stuff we put in, old time cross
compilers will already know it and we don't want to confuse
new users (trust me, it is confusing enough).
Mo DeJong
Red Hat Inc
new version of autoconf
and automake, and that don't work. Another approach is to
uninstall the old versions of autoconf, automake, and libtool
before you begin.
Mo DeJong
Red Hat Inc
the same --prefix, then it will just work like magic. But
then again, you could just code that into your own configure.in.
Mo DeJong
Red Hat Inc
. i386-pc-mingw32msvc
checking how to run the C preprocessor... i386-mingw32msvc-gcc -E
checking for i386-mingw32msvc-gcc... i386-mingw32msvc-gcc
checking whether the C compiler works... yes
...
My real question is, why do I need to do this? If autoconf
knows that it is cross compiling then it should kn
On 10 Jul 2000, Akim Demaille wrote:
> >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> I took a peek at the config.guess and found this.
>
> See http://sources.redhat.com/ml/autoconf/2000-04/msg00097.html and
> following :)
We
ed program was:" >&5
cat conftest.$ac_ext >&5
CXXCPP=/lib/cpp
fi
The tests fail for some reason and end up
setting CXXCPP=/lib/cpp. I have a /lib/cpp
file on my linux box, but there is no
such file under Cygwin.
% ls -la /lib/cpp
lrwxrwxrwx1 root root 53 A
a bug in autoconf/libtool
dnl We need to export CC and CC_FOR_BUILD so that libtool
dnl uses the compiler found by ./configure and we can cross.
export CC
if test "x$cross_compiling" = "xyes" ; then
AC_CHECK_PROG(CC_FOR_BUILD, gcc, gcc, cc)
export CC_FOR_BUILD
fi
Mo DeJong
Red Hat Inc
error.
Symbol `PATH_SEPARATOR' is not covered by /usr/share/autoconf/acconfig.h
Both of these errors seem wrong, I should be able to call
AC_DEFINE with 1, 2, or 3 arguments.
Mo DeJong
Red Hat Inc
/autoheader: NONE:0:: command not found
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
NONE:0: /usr/bin/m4: Cannot open /usr/local/share/autoconf/autoconf.m4f:
No
such file or directory
thanks
Mo DeJong
Red Hat Inc
0.5) lack the st_blksize field
# in struct stat. But we might be able to use fstatfs instead.
#
AC_STRUCT_ST_BLKSIZE
AC_CHECK_FUNC(fstatfs, , [AC_DEFINE(NO_FSTATFS)])
I am not sure how to fix this, and ideas?
thanks
Mo DeJong
Red Hat Inc
; Lars> This is *bad* news for me, but probably not for Autoconf
> Lars> development, as I'll have to work on fixing this...
>
> Mo, Lars, could you give a look at the patch 25-* and see if it works?
Forgive my ignorance, but where would I find "patch 25-*"?
Mo DeJong
Red Hat Inc
re required in my configure.in.
if test "${prefix}" = "NONE"; then
prefix=/usr/local
fi
if test "${exec_prefix}" = "NONE"; then
exec_prefix=$prefix
fi
thanks
Mo DeJong
Red Hat Inc
1 - 100 of 141 matches
Mail list logo
