Use `ln -sf` rather than `rm -f && ln -s`

odd ... git-send-email ate the explanatory text ...
---
The -f option to ln should give the same behavior as the -f option to the rm command. It is better to do this in one shot so as to avoid race conditions when building in parallel. I build on a quad G5 and without this change, it isn't uncommon for the build to fail when using -j8 due to this small window where the files don't actually exist.

Quoted 7 lines · In message <[email protected]> you wrote:

odd ... git-send-email ate the explanatory text ...
---
The -f option to ln should give the same behavior as the -f option to the rm command. It is better to do this in one shot so as to avoid race conditions when building in parallel. I build on a quad G5 and without this change, it isn't uncommon for the build to fail when using -j8 due to this small window where the files don't actually exist.

Note that "ln -s -f" will come down to two separate system calls as well:

	...
	unlink();
	symlink();
	...

So you don't avoid the race condition; you're just making it a little less likely at the cost of reduced portability.

Quoted 13 lines · Wolfgang Denk

Quoted 8 lines · In message <[email protected]> you wrote:

odd ... git-send-email ate the explanatory text ...
---
The -f option to ln should give the same behavior as the -f option to the rm command. It is better to do this in one shot so as to avoid race conditions when building in parallel. I build on a quad G5 and without this change, it isn't uncommon for the build to fail when using -j8 due to this small window where the files don't actually exist.

Note that "ln -s -f" will come down to two separate system calls as well:

Quoted 8 lines

	...
	unlink();
	symlink();
	...

So you don't avoid the race condition; you're just making it a little less likely at the cost of reduced portability.

yes, i know it's much less likely, but that difference on my system has been from 1-in-20 build failures to 1-in-none-so-far-out-of-hundreds. the real fix is to overhaul the u-boot build system, but that'll take quite a bit of time and this change is for all practical purposes, Good Enough. i dont know what portability issues you refer to considering the -f flag is in POSIX and has been supported on all Linux systems since before that (pre-2000). -mike

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------------------------------------------------

_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

The -f option to ln should give the same behavior as the -f option to the rm command. It is better to do this in one shot so as to avoid race conditions when building in parallel. I build on a quad G5 and without this change, it isn't uncommon for the build to fail when using -j8 due to this small window where the files don't actually exist.

Quoted 5 lines · Mike Frysinger

The -f option to ln should give the same behavior as the -f option to the rm command. It is better to do this in one shot so as to avoid race conditions when building in parallel. I build on a quad G5 and without this change, it isn't uncommon for the build to fail when using -j8 due to this small window where the files don't actually exist.

Since there is a clear dependency of environment.o on environment.c there is no way for make to run the rm/ln and $(CC) commands in parallel, so there should be no race condition.
For illustrative purposes: you should be able to put a sleep between the rm and the ln -s, and it should still build.

It seems the real problem is one level above, the commands were run twice in parallel, once for "depend" and once for the SUBDIRS "all". Please test the patch below.

Quoted 5 lines · Mike Frysinger

The -f option to ln should give the same behavior as the -f option to the rm command. It is better to do this in one shot so as to avoid race conditions when building in parallel. I build on a quad G5 and without this change, it isn't uncommon for the build to fail when using -j8 due to this small window where the files don't actually exist.

Since there is a clear dependency of environment.o on environment.c there is no way for make to run the rm/ln and $(CC) commands in parallel, so there should be no race condition.
For illustrative purposes: you should be able to put a sleep between the rm and the ln -s, and it should still build.

It seems the real problem is one level above, the commands were run twice in parallel, once for "depend" and once for the SUBDIRS "all". Please test the patch below.

The

  $(obj)u-boot:		depend $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT)

line tells make it can run commands to update each dependency in parallel, unless there are further dependencies which restrict this.

Thanks,
Johannes

---
Add dependencies to avoid race conditions with parallel make.

Signed-off-by Johannes Stezenbach <[email protected]>

Signed-off-by Mike Frysinger <[email protected]>

---
 tools/Makefile |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

tools/Makefile +0 -0

index af0de47..22d9dae 100644

Quoted 12 lines · In message <[email protected]> you wrote:

Signed-off-by Mike Frysinger <[email protected]>

---
 tools/Makefile |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

tools/Makefile +0 -0

index af0de47..22d9dae 100644
@@ -203,19 +203,16 @@ else
 endif
 

tools/Makefile else · line 206

Quoted 4 lines

tools/Makefile +1 -2

 $(obj)environment.c:
-		@rm -f $(obj)environment.c
-		ln -s $(src)../common/environment.c $(obj)environment.c
+		ln -s -f $(src)../common/environment.c $(obj)environment.c

Be careful here. Are you 100% sure that all systems in the field will behave exactly as your's is doing?

What is the exact problem you are trying to solve? If it's not a bug, I recomment to leave the code as is.

Quoted 7 lines

tools/Makefile else · line 206

Quoted 4 lines

tools/Makefile +1 -2

-		@rm -f $(obj)environment.c
-		ln -s $(src)../common/environment.c $(obj)environment.c
+		ln -s -f $(src)../common/environment.c $(obj)environment.c

Be careful here. Are you 100% sure that all systems in the field will behave exactly as your's is doing?

i really dont understand what you mean. any POSIX compliant system will behave exactly as it's supposed to: if the destination exists already, unlink it just before creating the link.