Bug 11700

Robert, can you take this.  tcl makes me so crazy. :)

The paths in the files are now pointing into the recipe sysroot so all the paths are breaking.  Note that there's a patch on the list against this recipe to clean up some of the low hanging fruit I found before deciding I didn't want to learn enough to fix this confidently.

(In reply to comment #0)
> When building tcl_8.6.6 we generate the file
> /usr/bin/crossscripts/tclConfig.sh.
> Two separate builds can generate two different files. One file can contain:
> 
> TCL_BUILD_LIB_SPEC='-​L/​usr/​lib/​recipe-​sysroot/​usr/​lib·​-​ltcl8.​6'
> 
> and the second one:
> 
> TCL_BUILD_LIB_SPEC='-​L/​usr/​lib·​-​ltcl8.​6'
> 
> This file is patched in "do_install":
> 
> sed -i "s;-L${B};-L${STAGING_LIBDIR};g" tclConfig.sh
> 
> 
> Consulting the corresponding run.do_install logs did not show anything
> obviously wrong ( when expanding the variables ${B} an ${STAGING_LIBDIR}). 
> FWIW, I use "rm_work", not that it should matter.
> I observed this discrepancy at least twice in the last week.

There are a few /usr/bin/crossscripts/tclConfig.sh, I guess that you've looked at different ones ?

sysroot-destdir/usr/bin/crossscripts/tclConfig.sh
image/usr/bin/crossscripts/tclConfig.sh
package/usr/bin/crossscripts/tclConfig.sh
packages-split/tcl/usr/bin/crossscripts/tclConfig.sh
recipe-sysroot-native/usr/bin/crossscripts/tclConfig.sh

I assumed that you had looked at image/usr/bin/crossscripts/tclConfig.sh, but it's content is different from yours:

TCL_BUILD_LIB_SPEC='-L/buildarea/lyang1/test_q/tmp/work/i586-poky-linux/tcl/8.6.7-r0/recipe-sysroot/usr/lib/recipe-sysroot/usr/lib -ltcl8.6'

And it will be handled meta/classes/binconfig.bbclass, so the ones in other dirs are OK.

I will close the bug, please reopen it if you see it again.

Created attachment 4081 [details]
diffoscope output that corroborates the claim.

(In reply to comment #2)

Well, I forgot to attach the diffoscope output to better describe the problem.  (I will do it now).
Anyway, I don't recall seeing this lately. I strongly suspect it has something to do with comparing two builds: one built with TMPDIR pointing to ramdisk (please see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12221 ) and one using the default TMPDIR location.

I will try to reproduce it again (I stopped using ramdisk as I kept runing out of RAM).

Created attachment 4082 [details]
diffoscope output demonstrating the bug, Oct 11

I ran into the problem again, diffoscope output attached. Contrary to my previous statement, this has nothing to do with ramdisk. Also, it uses the latest recipes.
The diffoscope output shows build host leakage, but that is not the issue here.

The issue is the inconsistent TCL_BUILD_LIB_SPEC, which should be the same for both builds.

The recipe tcl_8.6.7.bb  uses "sed" in do_install() to modify the file tclConfig.sh.
There are two back-to-back sed commands working on the same file tclConfig.sh:

	sed -i "s;-L${B};-L${STAGING_LIBDIR};g" tclConfig.sh
	sed -i "s;'${WORKDIR};'${STAGING_INCDIR};g" tclConfig.sh

While it **should** be OK, as "sed" works on a renamed copy of the original file, however, there seems to be an occasional race.
I will merge those two individual file operations into one, something like:

	sed  \
	  -e "s;-L${B};-L${STAGING_LIBDIR};g" \
	  -e "s;'${WORKDIR};'${STAGING_INCDIR};g" \
	  -i tclConfig.sh

It is more efficient this way anyway, (and I also hope this will fix the problem). I will try a few builds to see if I can still reproduce the problem, may need to create some kind of stress test.

Other possible explanation would be a problem with expanding variables.
But looking at run.do_install I can see all variables were expanded correctly.
Then there is SSTATE_SCAN_FILES that also modifies tclConfig.sh

Argh, no dice. Problem still there.

Looking at :
https://patchwork.openembedded.org/patch/144821/

The patch above seems to be the correct fix. I'll run few more tests over the next few days and hopefully close this bug.

After the patch was merged, the problem was not observed anymore for several weeks. I am closing this as RESOLVED/FIXED. Should I run into the problem again, I will re-open the bug.