Hi there, currently running through a build of LFS-6.5 with a view to adopting a "username-per-package" Package Management approach, as is my want every now and again.
Whilst watching the output of the Temporary System build of patch, I noticed that the build process is hard-coding the path to an 'ed' program for each compilation unit, vis: $ make gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. -g -O2 addext.c gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. -g -O2 argmatch.c ... gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. -g -O2 pch.c ... gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"/bin/ed\" -I. -I. -g -O2 xmalloc.c gcc -o patch -g -O2 addext.o argmatch.o backupfile.o basename.o dirname.o \ getopt.o getopt1.o inp.o maketime.o partime.o patch.o pch.o quote.o quotearg.o \ quotesys.o util.o version.o xmalloc.o patch.o: In function `make_temp': /lfs/patch-2.5.9/patch.c:1327: warning: the use of `mktemp' is dangerous, better use `mkstemp' [I have wrapped a few lines in that output, without compromising infomation] It is interesting (to me anyway) that the patch that gets applied to the build in LFS-6.5: patch-2.5.9-fixes-1.patch actually changes just the one file that the "define" of ed_PROGRAM appears in, namely, pch.c I am aware that LFS long since binned something as simple as 'ed' and moved it into BLFS, in which case, surely you should be removing all traces of it from the LFS build so that those builders who pay attention to the build output, as part of the learning process, do not start wondering what this 'ed' program is? I would also imagine that, at the point in the build that I noticed it, if mention of it is to be left lying around, things should probably be patched to refer to a non-existent '/tools/bin/ed' anyway and not something in /bin on the host system ? Kevin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
