search

exported / snappy

Automatically exported from code.google.com/p/snappy
Other
0 stars 0 forks source link

autogen.sh fails on OS X #24

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. svn checkout on an intel mac running snow leopard
2. run ./autogen.sh 

What is the expected output? What do you see instead?
autogen fails, even after I change libtoolize to glibtoolize

What version of the product are you using? On what operating system?
rev. 21, mac os snow leopard

Please provide any additional information below.

Original issue reported on code.google.com by t...@lightcorner.com on 28 Mar 2011 at 1:07

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi,

Could you please provide a log of the output?

Does it build if you download the tarball and run configure? The title of the 
bug says that the _build_ fails, but it sounds more like _autogen_ fails.

Original comment by se...@google.com on 28 Mar 2011 at 1:14

GoogleCodeExporter commented 9 years ago 
Classification: it's autogen that fails, downloading the tarball and  
"./configure; make" works

Here's the errors I see when running ./autogen.sh from svn checkout:

./autogen.sh: line 6: libtoolize: command not found

And when I change libtoolize to glibtoolize, I got:

configure.ac:40: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:42: error: possibly undefined macro: AC_MSG_FAILURE

Original comment by t...@lightcorner.com on 28 Mar 2011 at 1:38

GoogleCodeExporter commented 9 years ago 
It sounds like you're missing pkg-config. Where do your autotools come from?

Original comment by se...@google.com on 28 Mar 2011 at 9:00

GoogleCodeExporter commented 9 years ago

Original comment by se...@google.com on 28 Mar 2011 at 12:52

GoogleCodeExporter commented 9 years ago 
Any solution for this?
I'm having the same issue.

cheers

Original comment by fdman...@gmail.com on 4 Apr 2011 at 6:35

GoogleCodeExporter commented 9 years ago 
I'm still waiting for replies to my questions: Do you have pkg-config 
installed? Where do your autotools come from?

Original comment by se...@google.com on 4 Apr 2011 at 6:39

GoogleCodeExporter commented 9 years ago 
Same issue here with Apple supplied autotools. I don't see pkg-config as part 
of that. It doesn't help that autogen.sh resets PATH :)

Original comment by JanLehna...@googlemail.com on 4 Apr 2011 at 8:04

GoogleCodeExporter commented 9 years ago 
Well, if you don't have pkg-config installed, you cannot run autogen.sh. You're 
simply missing a dependency.

Original comment by se...@google.com on 4 Apr 2011 at 8:06

GoogleCodeExporter commented 9 years ago 
That is a fair point, but it also would be nice if the package would compile 
out of the box on mainstream operating systems :) — I'll dig some more, here.

Original comment by JanLehna...@googlemail.com on 4 Apr 2011 at 8:07

GoogleCodeExporter commented 9 years ago 
In addition I do have pkg-config installed via homebrew:

> brew info pkg-config
pkg-config 0.25
http://pkg-config.freedesktop.org
/Users/jan/.local/Cellar/pkg-config/0.23 (7 files, 220K)
/Users/jan/.local/Cellar/pkg-config/0.25 (8 files, 248K) *
http://github.com/mxcl/homebrew/commits/master/Library/Formula/pkg-config.rb

> pkg-config --version
0.25

I adjusted PATH in line 2 to also include $PATH so pkg-config can get picked 
up, but I am still getting:

> ./autogen.sh 
configure.ac:40: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:42: error: possibly undefined macro: AC_MSG_FAILURE

Original comment by JanLehna...@googlemail.com on 4 Apr 2011 at 8:11

GoogleCodeExporter commented 9 years ago 
Well, you're not alone; it's not installable out of the box on Windows, or on 
most Linux distributions. :-)

You'll need pkg-config integrated with your automake, AFAIK; the m4 files need 
to reside in the right directory. (The pkg-config binary itself is not relevant 
for autogen.sh.)

The PATH resetting is unfortunate, and at some point I'll be able to get rid of 
it. Unfortunately, we need it internally currently.

Original comment by se...@google.com on 4 Apr 2011 at 8:15

GoogleCodeExporter commented 9 years ago 
Oh, and I'd just like to point out that autogen.sh is only intended for people 
to intend to work on Snappy -- you won't need it if you download a tarball.

Original comment by se...@google.com on 4 Apr 2011 at 8:17

GoogleCodeExporter commented 9 years ago 
I got it solved, I think.

The root cause is not AC_DEFINE, but PKG_CHECK_MODULES (see 
http://blogs.sun.com/mandy/entry/autoconf_weirdness for more info). Having 
installed pkg-config is only half the answer. The accompanying pkg.m4 file must 
be in a location searched by aclocal.

I created a branch on GitHub with the following additions:

  * use a GOOGLE environment variable to block out code that is specific to Google infrastructure. Googlers, is this an acceptable way to special case your vs. our stuff?
  * detect Mac OS X / Darwin and call glibtoolize instead of libtoolize conditionally.
  * add an environment variable ACLFLAGS that allows the path to pkg.m4 (and potentially other macros)

https://github.com/janl/snappy-mirror/commits/mac-os-x

I'm happy to allow integration of any of these patches into the tree.

To build this on Mac OS X:

ACLFLAGS="-I /path/to/directory/containing/pkg.m4/" ./autogen.sh
./configure
make
sudo make install

Original comment by JanLehna...@googlemail.com on 4 Apr 2011 at 11:40

GoogleCodeExporter commented 9 years ago 
I'll have to take a look. I'm skeptical towards the kind of m4 hacks you're 
proposing, though; if you don't have a coherent autoconf setup (and that 
includes having pkg-config m4 files in the same m4 directory as all your other 
autoconf stuff) you're bound to get other subtle problems anyway. Most likely 
you'd then just want to just ignore the system's autoconf and get everything 
from the same source (at which point you'd also get a libtoolize has has not 
been renamed to something else).

Original comment by se...@google.com on 4 Apr 2011 at 11:46

GoogleCodeExporter commented 9 years ago 
I don't care much either way, I just want to make this easier for your users, 
preferably on a stock Mac OS X system. Given that snappy is a library that 
tends to get integrated into other projects with their own idiosyncratic build 
requirements, I'd rather not impose potentially different requirements for a 
library.

In a project I help maintaining (Apache CouchDB) we've had for a while that one 
dependency would require autoconf > 2.60 and another would require autoconf == 
2.13. That sure wasn't fun. Not saying this is gonna happen here, but I'd 
prefer to adjust snappy's build system to the point where it compiles on a 
stock installation of all major systems.

If there are other ways to get there, I'd be happy to see them. The proposed 
patches will get me through the week.

Original comment by JanLehna...@googlemail.com on 5 Apr 2011 at 12:00

GoogleCodeExporter commented 9 years ago 
Sure, and I appreciate your efforts. What I don't understand is why you need to 
run autogen.sh at all. If you download the tarball and run ./configure, does it 
not work? This is the expected mode of operation for anyone who doesn't want to 
hack on Snappy themselves (ie. just build it); it doesn't have any dependencies 
on autoconf or the likes.

Original comment by se...@google.com on 5 Apr 2011 at 7:51

GoogleCodeExporter commented 9 years ago 
My motivation is making it easier for projects using snappy as a dependency to 
build snappy as easy as possible.

You could argue that downstream projects should only use releases and hence 
should use the tarball, but in practice, being able to test upcoming versions 
or simple hotfixes is desireable.

Original comment by JanLehna...@googlemail.com on 5 Apr 2011 at 11:12

GoogleCodeExporter commented 9 years ago 
Hi,

I've thought a bit about this, and in the end I see this as simply an 
unsupported configuration.

If you want to run Snappy's autogen.sh, you will need a working autotools + 
libtool + pkg-config setup. OS X does not provide that by default. Neither does 
pulling in pkg-config from homebrew; at best, it works by accident, and it is 
not a stable configuration we want to support. However, if you pull in 
autotools and pkg-config from the same place, it should work.

What _is_ a valid issue, is that PATH is being overridden. I've opened a 
separate bug (#31) for that; feel free to follow it.

Original comment by se...@google.com on 11 Apr 2011 at 10:09

GoogleCodeExporter commented 9 years ago 
Hi,

I'm trying to build snappy on a 64-bit Linux machine. I see the same error:

 ./autogen.sh 
configure.ac:40: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:42: error: possibly undefined macro: AC_MSG_FAILURE

[rajachan@wci-login snappy-trunk]$ which pkg-config
/usr/bin/pkg-config
[rajachan@wci-login snappy-trunk]$ locate pkg.m4
/usr/share/aclocal/pkg.m4

I'm running the 2.6.18-164.11.1.el5 kernel..... I'm using the snappy source 
from trunk.. How do I get around this issue?

Thanks,

Raghu

Original comment by raghunat...@gmail.com on 28 Apr 2011 at 9:04

GoogleCodeExporter commented 9 years ago 
On OSX, you need to teach the system's aclocal where to find macros installed 
by homebrew.
This should do the trick:

eval `brew --config | grep HOMEBREW_PREFIX | sed 's/: /=/'`
sudo bash -c 'echo '$HOMEBREW_PREFIX/share/aclocal' >> `aclocal 
--print-ac-dir`/dirlist'

Original comment by and...@beekhof.net on 4 Jul 2011 at 2:13