Opened 7 years ago

Last modified 2 years ago

#10065 reopened bug

Jam clean fails

Reported by: jscipione Owned by: bonefish
Priority: normal Milestone: Unscheduled
Component: Build System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


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

...failed Clean clean ...

...failed updating 1 target(s)...

Change History (10)

comment:1 by anevilyak, 7 years ago

Not reproducible here.

comment:2 by jscipione, 7 years ago

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?

comment:3 by bonefish, 7 years ago

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).

comment:4 by jscipione, 7 years ago

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?

comment:5 by bonefish, 7 years ago

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.

comment:6 by jscipione, 7 years ago

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.

comment:7 by jscipione, 7 years ago

Resolution: no change required
Status: newclosed

jam clean works now on OS X 10.9 Mavericks

comment:8 by kallisti5, 7 years ago

Resolution: no change required
Status: closedreopened
Version: R1/alpha4.1R1/Development

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

The issue is due to the lack of a and the usage of rm_attrs to erase files on clean. There is a situation that can exist where 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: 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/ before attempting to use rm_attrs. Maybe if 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 *should* be (HOST_BUILD_COMPATIBILITY_LIB_DIR), before setting RM to rm_attrs... we should check for first, and fall back to rm if needed.

comment:9 by bonefish, 7 years ago

An interesting question is how 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.

comment:10 by waddlesplash, 2 years ago

Milestone: R1Unscheduled
Note: See TracTickets for help on using tickets.