bugGNU Core Utilities - Bugs: bug #17794, error: possibly undefined macro:...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #17794: error: possibly undefined macro: gl_LOCK_EARLY

Submitter:  Andreas Schwab <schwab>
Submitted:  Mon 18 Sep 2006 03:29:19 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Jump to the original submission

Wed 20 Sep 2006 09:31:11 PM UTC, comment #10: 

OK, I installed the attached patch to add a --force option
to bootstrap along the lines you suggested.

Paul Eggert <eggert>
Group administrator
Wed 20 Sep 2006 05:25:16 PM UTC, comment #9: 

My concern is that running "bootstrap" not be done lightly.
If you don't want to disable it entirely, when run from a non-version-controlled directory, a compromise would be to
require a --force option in that case.

Otherwise, we may well end up getting problem reports that claim
to be using coreutils-6.3, when in fact they're using newer files
that a post-release ./bootstrap pulled from gnulib.

Jim Meyering <meyering>
Group administrator
Wed 20 Sep 2006 05:05:05 PM UTC, comment #8: 

"bootstrap" already should "just work" even when it's run in a directory that has already been bootstrapped, or a directory that came from a tarball.  I don't offhand see why we'd want to disable that capability.

Paul Eggert <eggert>
Group administrator
Wed 20 Sep 2006 01:38:58 PM UTC, comment #7: 

Including bootstrap in the tarball sounds like a good idea, but
perhaps with a new snippet of code to make it fail when it's run
from a directory that appears to have been untarred, rather than
checked out from some version control system.  Then, upon failure,
it could provide instructions and/or justification.

Jim Meyering <meyering>
Group administrator
Mon 18 Sep 2006 11:43:43 PM UTC, comment #6: 

If it serves as any reference point, M4 1.4.6 includes its bootstrap in its tarball.  Someone using the tarball is expected to neither run bootstrap nor to run autoreconf (a fact that automake checks during 'make distcheck'), but the files are still shipped should they choose to rather than forcing them to check m4 out from CVS, similar to how configure.ac or Makefile.am is included in the tarball.  On the other hand, running bootstrap implies that you have checked out gnulib from CVS, so omitting bootstrap from the tarball isn't too severe because by the time a user has grabbed gnulib from CVS, they can go all the way grab the bootstrap script and rest of the package from CVS as well.

As to the original report, running autoreconf on a package without first checking whether it works without modifications is risky.  The fact that it triggered a failure here should not come as a surprise, because it is not recommended practice; indeed, coreutils 6.2 depends on files that are newer than what gettext 0.15 provides, but gettext 0.15.1 has not yet been released, so autoreconf alone is helpless to do the job correctly.  But maybe there is a bug report against gettext here, for the fact that autopoint blindly replaces macros to older versions rather than trusting that a newer version of the macro does not need to be downgraded to what that macro used to be at the time of the gettext release.

Eric Blake <ericb>
Group administrator
Mon 18 Sep 2006 10:51:56 PM UTC, comment #5: 

You can get bootstrap from

http://cvs.savannah.gnu.org/viewcvs/coreutils/bootstrap?rev=1.15&root=coreutils&view=log

I'm not sure whether it should be included as part of the tarball.  It isn't intended for ordinary builder use, but on the other hand the maintainers use it a lot.  Perhaps Jim has an opinion.  In the meantime I'll reopen the bug.

Paul Eggert <eggert>
Group administrator
Mon 18 Sep 2006 07:58:17 PM UTC, comment #4: 

There is no bootstrap.

Andreas Schwab <schwab>
Mon 18 Sep 2006 07:12:10 PM UTC, comment #3: 

Ah, sorry, I misread the example.  I guess the right answer is
that coreutils isn't set up to use autoreconf.  You can use
"bootstrap" instead; it gets the pieces that autoreconf would
get, but omits stuff like the "lock" module that autoreconf
mistakenly would include.

Paul Eggert <eggert>
Group administrator
Mon 18 Sep 2006 05:45:07 PM UTC, comment #2: 

There is no gnulib involved.

Andreas Schwab <schwab>
Mon 18 Sep 2006 05:42:12 PM UTC, comment #1: 

I think that was a gnulib-tool bug, fixed by my recent change
to gnulib-tool (revision 1.167, dated 2006-09-18 10:03:47 -0700).
Please upgrade gnulib and try again.

Paul Eggert <eggert>
Group administrator
Mon 18 Sep 2006 03:29:19 PM UTC, original submission:  

$ cd coreutils-6.2
$ autoreconf -fi
Copying file m4/codeset.m4
Copying file m4/gettext.m4
Copying file m4/glibc2.m4
Copying file m4/glibc21.m4
Copying file m4/iconv.m4
Copying file m4/intdiv0.m4
Copying file m4/intmax.m4
Copying file m4/inttypes-h.m4
Copying file m4/inttypes-pri.m4
Copying file m4/inttypes_h.m4
Copying file m4/lcmessage.m4
Copying file m4/lib-ld.m4
Copying file m4/lib-link.m4
Copying file m4/lib-prefix.m4
Copying file m4/lock.m4
Copying file m4/longdouble.m4
Copying file m4/longlong.m4
Copying file m4/nls.m4
Copying file m4/po.m4
Copying file m4/printf-posix.m4
Copying file m4/progtest.m4
Copying file m4/signed.m4
Copying file m4/size_max.m4
Copying file m4/stdint_h.m4
Copying file m4/uintmax_t.m4
Copying file m4/ulonglong.m4
Copying file m4/visibility.m4
Copying file m4/wchar_t.m4
Copying file m4/wint_t.m4
Copying file m4/xsize.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
configure.ac:38: warning: gl_LOCK_EARLY is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:30: gl_EARLY is expanded from...
configure.ac:38: the top level
configure.ac:38: warning: gl_LOCK_EARLY is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:30: gl_EARLY is expanded from...
configure.ac:38: the top level
configure.ac:38: warning: gl_LOCK_EARLY is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:30: gl_EARLY is expanded from...
configure.ac:38: the top level
configure:5353: error: possibly undefined macro: gl_LOCK_EARLY
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

Andreas Schwab <schwab>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #10815:  diff added by eggert (2KiB - application/octet-stream - coreutils patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 7 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-09-20 eggert Open/ClosedOpen Closed
2006-09-20 eggert StatusIn Progress Fixed
    Attached File- Added diff, #10815
2006-09-18 eggert StatusFixed In Progress
    Open/ClosedClosed Open
2006-09-18 eggert StatusNone Fixed
    Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code