Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure fails with syntax error #2862

Closed
jamadden opened this issue May 20, 2020 · 5 comments · Fixed by #2885
Closed

configure fails with syntax error #2862

jamadden opened this issue May 20, 2020 · 5 comments · Fixed by #2885
Labels
build not-stale Issues that should never be marked stale

Comments

@jamadden
Copy link
Contributor

  • Version: 1.38.0, upgrading from 1.36.0
  • Platform: Travis CI, Ubuntu 16.04.6

Building gevent runs the command pushd deps/libuv && ./autogen.sh && ./configure -C --disable-static --prefix=$BUILD_LIBS on Travis CI. When I try to upgrade to 1.38, this fails:

checking whether make supports nested variables... (cached) yes
./configure: line 12686: syntax error near unexpected token `newline'
./configure: line 12686: `AX_PTHREAD('

This happens even if I use bash explicitly to run configure.

I don't reproduce this locally on macOS.

I didn't see anything about changes to the build system in the release notes. Could I have done something wrong?

@bnoordhuis
Copy link
Member

It's caused by #2823 but if it's breaking the build for you with no workaround, then I'll revert it.

I'm unclear on why it's failing for you though. Are you using old versions of autoconf/automake? What does configure around line 12686 look like on the affected system?

@jamadden
Copy link
Contributor Author

Are you using old versions of autoconf/automake?

I don't know. I'm using whatever comes with Travis CI's Ubuntu 16.04 image (which is the default for all Travis builds right now). That is, unfortunately, one thing they don't specify. I can find out, though.

What does configure around line 12686 look like on the affected system?

I can try to find out.

jamadden added a commit to gevent/gevent that referenced this issue May 21, 2020
@jamadden
Copy link
Contributor Author

Autoconf is version 2.69 (which matches what I have locally). Automake is 1.15 (locally I have 1.16.2).

The ten lines around 12686 are:

  AM_V=$AM_DEFAULT_VERBOSITY
  AM_DEFAULT_V=$AM_DEFAULT_VERBOSITY
fi
AM_BACKSLASH='\'


AX_PTHREAD(
    LIBS="$LIBS $PTHREAD_LIBS"
    CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
)
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlopen in -ldl" >&5

I can see what happens if I force Travis to use Ubuntu Bionic (18.04), but that will take some time.

@jamadden
Copy link
Contributor Author

Ah-ha. I think I figured it out. The libuv tarball includes m4/.gitignore which ignores all .m4 files in that directory:

*.m4

But #2823 explicitly added ax_pthread.m4 to that directory (without excluding it from being ignored). When I updated the libuv source and committed it to git, because of the .gitignore, that new file didn't get included — and because of the .gitignore, none of the tooling reported a suspicious extra file. Naturally it worked locally for me because that's where I unpacked the tarball, but a clean checkout didn't include that macro.

Perhaps that file should be listed in m4/.gitignore?

clrpackages pushed a commit to clearlinux-pkgs/gevent that referenced this issue Jun 8, 2020
…0.5.2

Jason Madden (58):
      Back to development: 20.5.1
      Avoid closing the same libuv watcher object twice.
      Add faulthandler.
      Fix compilation with Cython 3.
      Go back to pinning Cython < 3.
      Add link to Cython issue cython/cython#3578
      Working on an improved loop exit protocol.
      Clean hub resources in a compatible way.
      Calling debug() on a destroyed libuv loop would raise TypeError
      More safely handle getting a callback from libuv once we're destroyed.
      More safely handle getting a callback from libuv once we're destroyed.
      Properly clean up native resources in gevent.signal_handler() when cancel is called.
      Update to PyPy 7.3.1 on Travis.
      Fixes for PyPy 7.3.1
      Make waiters on Events that arrive while the event is ready and notifying greenlets that had to block run after they do.
      Testrunner: Ignore warnings from dns.zone
      Fix calling gevent.wait() twice on a set Event.
      fixup
      Missed trailing colon.
      Add postrelease hook to stop zest.releaser from modifying CHANGES.rst in its last step.
      Tweak documentation for baseserver.max_accept. [skip ci]
      Rename C accelerator modules to avoid clashes.
      Tweak a URL in the docs. [skip ci]
      Add failing test for #1437
      Progress on cross-thread locks.
      Missing import.
      Adjust when and how Semaphore captures the hub.
      Cleanup to pass leak tests.
      More fixes for leakchecks.
      test__threading_native_before_monkey was depending on a side-effect.
      Fix benchmark, and make AsyncResult use the provided API.
      Update to Cython 3.0a5. Fixes #1599
      Make zope.interface/event and setuptools required dependencies.
      Update to libuv 1.38
      Try configuring with bash.
      win/udp.c is incompatible with Visual Studio 9
      Debugging output for libuv/libuv#2862
      Also automake version.
      Update from Ubuntu 16.04 to 18.04
      Try one line?
      m4/ax_pthread.m4 was being ignored by m4/.gitignore.
      Revert update to bionic.
      Bump c-ares to 1.16.1. Fixes #1624.
      whitespace
      manpage patch
      Restore config.guess/config.sub to c-ares.
      Use latest xcode
      Add libresolv to the libraries needed to link c-ares on macOS.
      distutils cflags may be None, e.g., on Win
      Tweak links in readme. [skip ci]
      Preparing release 20.5.1
      Back to development: 20.5.2
      Try to only upload gevent wheels on appveyor.
      Catch greenlet.error when destroying a hub from another thread.
      Attempt better warnings handling.
      default action should be first.
      Don't get a warning about ResourceWarning on Py2.
      Preparing release 20.5.2
@stale stale bot added the stale label Jun 11, 2020
@libuv libuv deleted a comment from stale bot Jun 12, 2020
@stale stale bot removed the stale label Jun 12, 2020
@bnoordhuis bnoordhuis added the not-stale Issues that should never be marked stale label Jun 12, 2020
bnoordhuis added a commit to bnoordhuis/libuv that referenced this issue Jun 12, 2020
It was reported that the addition of that file without adding an
exception to m4/.gitignore breaks the tarball autotools build because
the file isn't distributed.

Fixes: libuv#2862
@jamadden
Copy link
Contributor Author

Thanks!

JeffroMF pushed a commit to JeffroMF/libuv that referenced this issue May 16, 2022
It was reported that the addition of that file without adding an
exception to m4/.gitignore breaks the tarball autotools build because
the file isn't distributed.

Fixes: libuv#2862
PR-URL: libuv#2885
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build not-stale Issues that should never be marked stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants