On Mon, Mar 18, 2024 at 09:25:16AM +0100, Robert Pluim wrote:
> >>>>> On Sun, 17 Mar 2024 20:24:28 +0100, <tomas@tuxteam.de> said:

[...]

>     Tomas> It is GNU/Linux, yes, and this was my take too, since "my" libc
>     Tomas> does carry a chmodat.
> 
> That in itself doesnʼt mean gnulib wonʼt try to replace it: sometimes
> gnulib deems libc versions of functions buggy and wraps them. But I
> donʼt see that for chmodat on my GNU/Linux box.
> 
>     >> And in any case, this doesn't seem to have anything to do with
>     >> out-of-tree builds, does it?
> 
>     Tomas> Thing is, in-tree build (after a make bootstrap) succeeds right
>     Tomas> away. Out of tree builds (also after make bootstrap) failed for
>     Tomas> me as described above.
> 
> Did you build in-tree and then build out-of-tree? Maybe 'make
> bootstrap' in that situation is missing some cleanup.

AFAIR, I first built out-of-tree after a "git pull" (I didn't a "git
clean", so the src tree might have been dirty [1]), then copied that
chartab.o, then #undef'd. After a "make bootstrap" (still out-of-tree)
the first issue (chartab.o) returned.

That's when I resorted to in-tree build, first "make bootstrap" then
"make", which succeeded right away.

Take all of this with a grain of salt, though: I'll do a more systematic
rehearsal this weekend, hopefully.

>     Tomas> So I'll definitely have a look. Next week is a bit busy, so it
>     Tomas> might take me until weekend.
> 
>     Tomas> Thanks for confirming that (a) out-of-tree build is supposed to
>     Tomas> work and (b) there is interest in knowing when it doesn't.
> 
> Yes to both (and it works fine for me).

Thanks, Robert. I'm reporting back :)

Cheers

[1] Since I've been doing out-of-tree all the time, there's no reason
   for the src tree to be dirty (famous last...).

-- 
t