I just found a bug whereby autoconf does not modify ${prefix}/info/dir
the way it ought to. I believe that the correct fix for this is to
call -install-info. The following patch should correct this problem,
if I understand it correctly:
tibbetts@hikari-no-ken:~/dev/aui/third/autoconf> autoconf --
If xemacs-21.2.34/configure.in thinks it is on a Linux box, it
defines _XOPEN_SOURCE to 500. Later, it extracts the symbols that xmkmf
defines, which includes defining _XOPEN_SOURCE. The redefinition of
_XOPEN_SOURCE in confdefs.h causes output to standard error in of the
test programs t
> "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 run the
>> compiler without the -g flag to make sure that it created a
>> conftest.o file, and then run with th
Thanks, Autoconf is now using Automake, and therefore is no longer
susceptible to be buggy in this area. Which does not mean that
Automake cannot :)
Akim
| c:/djgpp/tmp/au7944/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open
| [c:/djgpp/tmp/au7944/m4.m4]: No such file or directory (ENOENT)
| c:/djgpp/tmp/au7944/input.m4:44: c:/djgpp/bin/m4.exe: Cannot open [../libm4.m4]: No
| such file or directory (ENOENT)
|
| and a preserved input.m4:
|
| diver
> "Adam" == Adam J Richter <[EMAIL PROTECTED]> writes:
Adam> However, I think the correct fix would be for autoconf to have a
Adam> "grep -v warning:" in its test of output on standard error when
Adam> that is used as the test for compile failure in AC_CHECK_HEADER.
Yes, we have a serious pr
Mo DeJong <[EMAIL PROTECTED]> writes:
> Perhaps this is a silly idea, but why don't you just run the compiler
> without the -g flag to make sure that it created a conftest.o file,
> and then run with the -g flag but check that the produced conftest.o
> is larger than the first one.
Yes, but if we
> So my guess is that you don't run GNU sed. I don't know too well what
> to do wrt this issue.
Every DOS utility I have is GNU, including sed.
> Have autoupdate use Perl?
Sorry, I don't understand the question.
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 run the
> >> compiler without the -g flag to make sure that it cr
> > So my guess is that you don't run GNU sed. I don't know too well what
> > to do wrt this issue.
>
> Every DOS utility I have is GNU, including sed.
Ahh, I found the problem, but I don't as yet have a solution:
bash-2.04$ echo "one too three four" | sed "s|\btoo\b|two"
one too three four
b
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`
od will suppress rows that contain only 0's, making the size look
different.
> +if tes
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`
>
> od will suppress rows that
On Jun 16, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> This is kind of wacky because the only way I could figure
> out how to get the length of a binary file was to use
> od and then measure the string length of that.
How about using the same strategy GCC bootstrap's `compare' target
uses:
> "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
Mo> easy way to figure out the size of a binary file in bytes?
Autoconf 2.13 says:
ac_lines=`grep -c
> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes:
Assar> Mo DeJong <[EMAIL PROTECTED]> writes:
>> Perhaps this is a silly idea, but why don't you just run the
>> compiler without the -g flag to make sure that it created a
>> conftest.o file, and then run with the -g flag but check tha
On Fri, 16 Jun 2000, Mo DeJong wrote:
> On Fri, 16 Jun 2000, Thomas E. Dickey wrote:
>
> Because earlier in the test ac_cv_prog_cc_g_bigger is set to the
> length of the output of od.
so you aren't planning to use this on machines whose shell breaks for
variables longer than 4k (or 1k ;-).
>
GCC and Sourceware src (== Cygnus)'s top-level configure always passes
--build, --host and --target down to sub-directories. Therefore, we
must not assume that, just because --host is given, we're cross
compiling.
Comparing build with host and deciding for cross compilation if they
differ might
On 16 Jun 2000, Akim Demaille wrote:
> > "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
> so I guess this means you can rely on grep -c. But really, don't fear
> using wc -c, just write your test in such a way that it is pessimistic
> is wc fails.
this doesn't fit well with the proposal to
On Jun 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes:
Assar> Can't we just run `cc -g' and see if it produces an object
Assar> file?
> Agreed. This is my own opinion too.
The current code is trying to save poor developers from
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
> Mo> easy way to figure out the size of a binary file in b
On 16 Jun 2000, Alexandre Oliva wrote:
> GCC and Sourceware src (== Cygnus)'s top-level configure always passes
> --build, --host and --target down to sub-directories. Therefore, we
> must not assume that, just because --host is given, we're cross
> compiling.
>
> Comparing build with host and
On 16 Jun 2000, Alexandre Oliva wrote:
> On Jun 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> >> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes:
>
> Assar> Can't we just run `cc -g' and see if it produces an object
> Assar> file?
>
> > Agreed. This is my own opinion too.
I just updated and got this change to the AC_CHECK_TOOLS macro:
2000-06-09 Akim Demaille <[EMAIL PROTECTED]>
* acgeneral.m4 (AC_CHECK_TOOLS): Rewrite.
While the rewrite is not really "wrong", it is also not
as "right" as the old macro. Here is what is printed
when I run the new macro.
23 matches
Mail list logo
