On 1/2/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > Looks pretty good. I'm pretty sure you'll find perl, vim and nscd are > different due to timestamps embedded into the binaries. You can easily > confirm this by using `strings' and `diff' eg: > > strings cmp/iter1/*/nscd > 1 > strings cmp/iter2/*/nscd > 2 > diff 1 2
I'll check these guys out sometime in the next few days. > On the other hand, bison is a problem which must be explained. I don't see > bison differences in the DIY build. This is where keeping the build and/or > src dirs is valuable in finding the root cause. I've got a pretty good inkling what the issue is here. DIY builds bison and flex in temptools. LFS doesn't. I moved up flex before bison because bison will use flex if it's there, but I think there's some circular dependency stuff that's only gonna be solved if at lease bison is added to /tools. For evidence, here's a diff of the build logs between iter1 and iter2 for bison: --- iter1/bison-2.1.log 2005-12-29 11:50:40.000000000 -0800 +++ iter2/bison-2.1.log 2005-12-29 13:28:54.000000000 -0800 @@ -79,8 +79,7 @@ checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes -checking for bison... no -checking for byacc... no +checking for bison... bison -y checking for ranlib... ranlib checking for gm4... no checking for gnum4... no > One last thing, forget about .gch differences. The nature of PCH where it > tries to map a data file into a suitable memory region within the OS's VM > will always end up random. Thanks for the info. I was basically ignoring all the stdc++ and gch stuff under the guess that there was some random phenomena involved. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
