Re: Strange Build Problem.

[James Henstridge <james daa com au>]

Assuming you have set ACLOCAL_FLAGS correctly, unfound macros usually
means you have duplicate macro files on aclocal's search path.  In this
case, aclocal will abort, not writing aclocal.m4.  This causes problems in
configure.in.

Try running "find / -name '*.m4'", and see if you have any duplicate
macros in the search path you gave aclocal.

James Henstridge.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/


On Thu, 17 Dec 1998, Gleef wrote:

> 
> On Tue, 15 Dec 1998, Craig Main wrote:
> > Hi all,
> 
> Hi there.
> 
>  
> > Here is my output from ./autogen.sh --prefix=/opt/gnome
> > I have tried with --with-no-package, and various other options I could see,
> > still have not been able to get anywhere.
> > This happens with every build from glib (this output is from glib) to
> > audiofile to gtk+. The output is almost identical for each one.
> > 
> > I am using RedHat 5.2, and the latest libtool / gettext.
> > 
> > aclocal: couldn't open directory `/opt/gnome/aclocal': No such file or directory 
> 
> This is very suspicious.  There should be no /opt/gnome/aclocal directory
> and aclocal shouldn't be looking anywhere close to there.  First, where is
> aclocal from?  Try typing:
>    $ rpm -qf `which aclocal`
>    automake-1.3-2
> 
> Note that those are backquotes.  You might have a more recent version than
> me.  If you get something like "file /usr/local/bin/aclocal is not owned
> by any package", then you should delete the hand installed version and use
> the RPM.  Some of the GNU tools are hard to get all the pieces in the
> right place by hand, aclocal and gettext are probably the two most
> notoriously troublesome ones.
> 
> If that checked out ok, then we check to make sure aclocal is acting sane.
> Try typing:
>    $ aclocal --print-ac-dir
>    /usr/share/aclocal
> 
>    $ set |grep ACLOCAL_FLAGS
>    $
>    (Yes, there should be a blank response, this command may be
>     different in shells other than sh or bash)
> 
> Now when aclocal runs on its own, it just checks in
> /usr/share/aclocal.  When autogen.sh runs it, it checks in anything
> specified in the ACLOCAL_FLAGS and in ./macros (where . is the source
> directory of the package you are building).
> 
> 
> 
> > configure.in:137: warning: AC_TRY_RUN called without default to allow cross compiling
> 
> These warnings can be safely ignored.
> 
> 
> > loading cache ./config.cache
> > ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE($PACKAGE,'
> > ./configure: ./configure: line 566: `AM_INIT_AUTOMAKE($PACKAGE, $VERSION,
> > no-define)'
> 
> This is another sign that your aclocal installation might be messed
> up.  The AM_INIT_AUTOMAKE function should be defined in
> /usr/share/aclocal/init.m4.
> 
> Now, some people deliberately change their aclocal configuration
> because the GNOME make install commands put their aclocal m4 files in
> $prefix/share/aclocal (in your case /opt/gnome/share/aclocal), leading
> aclocal to not find them.  If you do the following:
>    $ cd /opt/gnome/share
>    $ cp -f aclocal/* /usr/share/aclocal
>    $ rm -rf aclocal
>    $ ln -s /usr/share/aclocal aclocal
> Then you will have a lasting configuration where GNOME's make install
> will automatically put updated m4 files in the proper directory.
> 
> Best of Luck,
> -Gleef
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>