Jam clean fails

[jscipione]

On hrev46175, run jam clean, lots of .o files listed then:

...failed Clean clean ...

BUILD FAILURE:
...failed updating 1 target(s)...

[anevilyak]

Not reproducible here.

[jscipione]

hmmm, could be an OS X problem or just something on my machine, jam is Jam 2.5-haiku-20111222. OS=MACOSX. Copyright 1993-2002 Christopher Seiwald.

Any ideas on how to troubleshoot?

[bonefish]

The reason is the recently increased ​MAXLINE constant in Jam. It defines the maximum length of command lines jam produces. If it is greater than what your system (shell/libc/kernel) actually supports, jam may produce a command line that cannot be executed (correctly).

[jscipione]

sysctl kern.argmax kern.argmax: 262144

so looks like it is 256k, which from what I've read is standard for BSD systems. Could this be the problem?

[bonefish]

Since the jam version string hasn't been updated consequently upon changes in jam, I don't know what jam version you're actually using. I believe MAXLINE has never been > 262144, so your kernel setting should suffice. You could just reduce MAXLINE and see, if that improves the situation.

[jscipione]

I was hoping the changes in hrev46194 would fix this problem but unfortunately jam clean still fails for me in the same way. Reducing MAXLINE didn't seem to help either.

[jscipione]

jam clean works now on OS X 10.9 Mavericks

[kallisti5]

This is actually still an issue. (one I see quite often)

The issue is due to the lack of a libroot_build.so and the usage of rm_attrs to erase files on clean. There is a situation that can exist where libroot_build.so is missing, thus rm_attrs fails to execute...

Clean clean 
Clean clean 
/home/kallisti5/Code/haiku/generated.arm/objects/linux/x86_64/release/tools/rm_attrs: error while loading shared libraries: libroot_build.so: cannot open shared object file: No such file or directory

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/kallisti5/Code/haiku/generated.arm/objects/linux/lib ;
/home/kallisti5/Code/haiku/build/scripts/rm_attrs /home/kallisti5/Code/haiku/generated.arm/objects/linux/x86_64/release/tools/rm_attrs -f "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/bzero.o" "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/ffs.o" "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/memccpy.o" "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/memchr.o"...

I think the solution is to check for the existence of generated.arm/objects/linux/lib/libroot_build.so before attempting to use rm_attrs. Maybe if libroot_build.so is missing, the clean will attempt to build it.. or just fall back to rm vs rm_attrs.

The change needs to occur in build/jam/BuildSetup ~line 530.

We know the directory where libroot_build.so *should* be (HOST_BUILD_COMPATIBILITY_LIB_DIR), before setting RM to rm_attrs... we should check for libroot_build.so first, and fall back to rm if needed.

[bonefish]

An interesting question is how libroot_build.so can be missing while rm_attr -- which depends on the former -- exists.

Anyway, I would recommend adjusting build/scripts/rm_attrs to simply fall back to using rm when invoking rm_attrs fails. I probably won't have time/motivation anytime soon, so whoever feels inclined to do that, please go ahead.

[pulkomandy]

An interesting question is how libroot_build.so can be missing while rm_attr -- which depends on the former -- exists.

That's not surprising during a "jam clean", however, since the goal is to remove all generated things, including tools that run on the host.

Can we make "jam clean" just delete generated/objects instead of what it is doing now? That would be simpler and more reliable. As we do out-of-tree builds, there is no need to individually track each generated file.

[bipolar]

Just linking it for reference...

Proposed fix by Dominic: ​https://review.haiku-os.org/c/haiku/+/5313