Andrew,
> OK, so this is a glibc thing... It seems that glibc on the host thinks > it can own creation *AND* deletion of symlinks via ldconfig. If > ldconfig finds a symlink that doesn't actually go anywhere, it assumes > it's a dead link left over from some libs that aren't installed anymore > and will delete it for you. That's annoying. That's what ldconfig do and this is why I was testing this specific command search why after section 4.9 the file was deleted. > > For now, it seems the simple thing to do is to touch /lib/libc.so or > else build and install musl again after gcc-final in order to assure > that the target has a proper configuration of musl. This isn't horrible > but it is annoying given the way the embedded book is written since the > same set of libs that are used for building are also used for the target > and since musl's DESTDIR install will create a symlink that goes nowhere. > > I'm not sure the best approach to this... Any recommendations? So you are saying to do a musl 4.8 then gcc final 4.9 and then redo a 4.8 ? So my first question will be do we have other problem with the current manual except that symlink? if not add this at the end of section 4.9. But right now I cannot guarantee that there is not other symlink issue? I will try this approach and see if I'm able to boot up. I know that you are on musl-libc mailing or maybe gcc mailing list also? list you should ask them and see what will be there recommendation? thx -KA _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
