bug#6500: rm 8.1

[Jim Meyering]

Brad wrote:
> Hi Jim:
>
> After learning a little more about the debugger I was able to solve
> the problem.

Good.

> It is clear that the option test is not failing. However only one of
> three tests are being run because the code is linking to the new
> glibc. Therefore the program is calling the fts_open function defined

Think of this as a warning about your compiler and linker options.

> in glibc-2.11.2/io/fts.c rather than lib/fts.c (which does three
> options checks).
>
>       /* Options check. */
>       if (options & ~FTS_OPTIONMASK) {
>               __set_errno (EINVAL);
>               return (NULL);
>       }
>
>       /* Allocate/initialize the stream */
>       if ((sp = malloc((u_int)sizeof(FTS))) == NULL)
>               return (NULL);
>
> So the code is failing at the subsequent call to malloc. A
> segmentation fault is occurring because the glibc version of fts_open
> is incompatible with the new coreutils.
>
> I fixed this on my system by redefining fts_open() as
> _fts_open(). That way there is no pollution of the namespace.

Be careful.  That may well be insufficient,
in merely papering over the most apparent problem.

> Here are the diffs:
...
> I think that's it. It's probably not a good idea to redefine a
> function that's already defined in a linked library.

Actually, that's fine.

> The behavior is
> undefined in C because it depends upon the linkage order that is
> determined by the compiler.

This is the problem.
Don't link the C library (-lc) before a projects' own library
(lib/libcoreutils.a).

I'm marking this bug as resolved, but you're welcome
to reply if you have anything to add.