Giter Club home page Giter Club logo

Comments (21)

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
[deleted comment]

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 28 Mar 2011 at 1:14

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 28 Mar 2011 at 1:38

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
It sounds like you're missing pkg-config. Where do your autotools come from?

Original comment by [email protected] on 28 Mar 2011 at 9:00

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024

Original comment by [email protected] on 28 Mar 2011 at 12:52

  • Changed title: autogen.sh fails on OS X

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
Any solution for this?
I'm having the same issue.

cheers

Original comment by [email protected] on 4 Apr 2011 at 6:35

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
I'm still waiting for replies to my questions: Do you have pkg-config 
installed? Where do your autotools come from?

Original comment by [email protected] on 4 Apr 2011 at 6:39

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Apr 2011 at 8:04

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
Well, if you don't have pkg-config installed, you cannot run autogen.sh. You're 
simply missing a dependency.

Original comment by [email protected] on 4 Apr 2011 at 8:06

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Apr 2011 at 8:07

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Apr 2011 at 8:11

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Apr 2011 at 8:15

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Apr 2011 at 8:17

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Apr 2011 at 11:40

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Apr 2011 at 11:46

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 5 Apr 2011 at 12:00

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 5 Apr 2011 at 7:51

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 5 Apr 2011 at 11:12

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 11 Apr 2011 at 10:09

  • Changed state: WontFix

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 28 Apr 2011 at 9:04

from snappy.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 20, 2024
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 [email protected] on 4 Jul 2011 at 2:13

from snappy.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.