bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by


From: Jeff Sheen
Subject: Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te'
Date: Thu, 26 Jun 2014 15:54:10 +0100

Eric,

I know what is causing the issue.

I tried a fresh Mavericks install with just XCode 5.1.1 and Macports installed, 
and encountered the exact same problem.

I then realised that the only remaining difference between my environment and a 
vanilla environment, is that my development directories are on a FAT32 disk.

Indeed, the Autotools configuration worked as expected with a copy of the 
source tree stored on an HFS disk.

Is it expected behaviour that GNU Autotools are incompatible with some file 
systems natively supported by the OS?

Cheers,

Jeff.

> On 21 Jun 2014, at 11:17, Jeffrey Sheen <address@hidden> wrote:
> 
> Hi Eric,
> 
> `printenv' yields:
> 
>> TERM_PROGRAM=Apple_Terminal
>> TERM=xterm-256color
>> SHELL=/bin/bash
>> TMPDIR=/var/folders/qy/t7gq5bws7zjd95y5p5x_sw0w0000gn/T/
>> Apple_PubSub_Socket_Render=/tmp/launch-lfrgeG/Render
>> TERM_PROGRAM_VERSION=326
>> TERM_SESSION_ID=2B7B0578-7BAD-4F67-BE94-158A86ED6F89
>> USER=jeff
>> SSH_AUTH_SOCK=/tmp/launch-7NOuJW/Listeners
>> __CF_USER_TEXT_ENCODING=0x1F5:0:2
>> __CHECKFIX1436934=1
>> PATH=/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
>> PWD=/Volumes/DATA/filestore/development/c/libs/freetype2/git/freetype2
>> DBUS_LAUNCHD_SESSION_BUS_SOCKET=/tmp/launch-d00lFv/unix_domain_listener
>> LANG=en_GB.UTF-8
>> address@hidden
>> HOME=/Users/jeff
>> SHLVL=1
>> LOGNAME=jeff
>> DISPLAY=/tmp/launch-jyxUVQ/org.macosforge.xquartz:0
>> _=/usr/bin/printenv
> 
>  There is nothing Autotools specific that I can see there.
> 
> Also, there is no `./share/config.site' under the prefix directory of `/tmp/'.
> 
> If there is no other way that the `autom4te' command is being manually told 
> to output `m4trace' messages, then what else could be causing it? Could the 
> binary be being configured incorrectly when it is built?
> 
> Cheers,
> 
> Jeff.
> 
> 
>> On 20 June 2014 20:10, Jeffrey Sheen <address@hidden> wrote:
>> Thanks Eric.
>> 
>> I'll check the man pages for 'autom4te' to see which environment variables 
>> can set its execution mode.
>> 
>> Cheers,
>> 
>> Jeff
>> 
>> On 20 Jun 2014, at 17:42, Eric Blake <address@hidden> wrote:
>> 
>> > On 06/20/2014 09:54 AM, Jeffrey Sheen wrote:
>> >> Dear lists,
>> >>
>> >> I have run `testsuite' with the latest tar of Autoconf, and have many
>> >> failures reported.
>> >
>> > You definitely have a broken setup, but I'm not sure what's causing it.
>> >
>> >> Please find the output logs attached for `make check' and `make
>> >> installcheck'. The errors in both are the same according to `diff'.
>> >>
>> >> If you could find the time to take a look, it'd be much appreciated.
>> >
>> > From your other mail:
>> >
>> >> #                             -*- compilation -*-
>> >> 5. tools.at:145: testing autom4te and whitespace in file names ...
>> >> ./tools.at:163: mkdir "$dir" "$cachedir" "$TMPDIR" && touch "$file" || 
>> >> exit 77
>> >> ./tools.at:174: autom4te -C "$cachedir" -B "$dir" --language=m4sugar -o 
>> >> "$outfile" "$file"
>> >> ./tools.at:175: cat "$outfile"
>> >> --- -    2014-06-20 15:46:02.000000000 +0100
>> >> +++ 
>> >> /Volumes/DATA/filestore/development/gnu/autoconf/extract/autoconf-2.69/tests/testsuite.dir/at-groups/5/stdout
>> >>     2014-06-20 15:46:02.000000000 +0100
>> >> @@ -1,2 +1,5 @@
>> >> +m4trace: file with  funny ' $x & #! name:1: -1- 
>> >> m4_pattern_forbid([^_?m4_])
>> >> +m4trace: file with  funny ' $x & #! name:1: -1- 
>> >> m4_pattern_forbid([^dnl$])
>> >> +m4trace: file with  funny ' $x & #! name:1: -1- m4_include([foo.m4])
>> >> bar
>> >
>> > We need to figure out what is causing those spurious 'm4trace: ' lines
>> > to be output at the beginning of every run of autom4te.  Do you have any
>> > environment variables or config.site that might be interfering with
>> > normal operation of the tools, by causing autom4te to behave as if it
>> > were being requested to trace macros instead of do its normal job?
>> >
>> > --
>> > Eric Blake   eblake redhat com    +1-919-301-3266
>> > Libvirt virtualization library http://libvirt.org
>> >
> 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]