bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems building coreutils HEAD against gnulib HEAD


From: Jim Meyering
Subject: Re: Problems building coreutils HEAD against gnulib HEAD
Date: Wed, 20 Feb 2008 22:18:17 +0100

Eric Blake <address@hidden> wrote:

> According to Andreas Schwab on 2/19/2008 2:32 PM:
> |> Under the influence of -L, does -xtype l work like -lname '*' in
> |> detecting just the broken symlinks?
> |
> | You don't use -L of course (it isn't supported by find 4.1 anyway).
> | Note that with -L you would risk walking out of the base directory.
>
> POSIX requires "find -L . -type l" to print all broken symlinks, but has
> the drawback, as you mention, of following symlinks into other
> directories, as well as the drawback that not all finds are
> POSIX-compliant (Solaris 8 find, for example, does not understand -L).
> POSIX also requires "-exec ... {} +" to work, but not all finds support
> that (and since you seem to be stuck on the ancient GNU find 4.1, that is
> one of the programs that lacks it).  Without "-exec ... {} +", you run the
> risk of a poorly named symlink containing metacharacters which won't work
> nicely with xargs, or you suffer a slowdown of "-exec ... {} \;", or you
> fall back to extensions like -print0.
>
> Everything else mentioned in this thread (-xtype, -delete, -lname,
> -print0) is a GNU extension; and while BSD find has some of the same
> extensions, it does not have them all.  And Solaris find is just too poor
> in features to find broken symlinks in the first place.  So once you
> assume GNU find, you might as well assume it in multiple aspects.  I'll
> leave it up to Jim what to put in the bootstrap script.

I like the idea of avoiding -L, even if the penalty for using it -- escaping
the tree to delete other dangling symlinks -- might be a *good* thing :-)

Here's what I've added to coreutils' bootstrap script:

  # Remove dangling symlinks in gnulib-populated directories, since
  # a dangling m4/*.m4 symlink would cause aclocal to fail.
  # This depends on GNU find, and a relatively recent version at that.
  # Ignore any failure for now, since it's only to avoid the relatively
  # unusual case in which a symlinked-to file in gnulib/ or gl/ is removed.
  find m4 lib build-aux -depth -type l -xtype l -delete > /dev/null 2>&1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]