This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
include/bits/stamp-bits is a one-file symlink loop
- From: Simon Baldwin <simonb at google dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Fri, 4 Feb 2011 00:17:34 +0100
- Subject: include/bits/stamp-bits is a one-file symlink loop
I've encountered a problem copying a built gcc 4.6 trunk with cpio -L
because of a file generated by libstdc++:
cpio: build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stamp-bits:
Cannot stat: Too many levels of symbolic links
The problem occurs because bits/stamp-bits is a symlink that loops
back to itself. It's being generated by
libstdc++-v3/include/Makefile.am:
924 stamp-bits: ${bits_headers}
925 @-mkdir -p ${bits_builddir}
926 @-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
927 @$(STAMP) stamp-bits
928
929 stamp-bits-sup: stamp-bits ${bits_sup_headers}
930 @-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
931 @$(STAMP) stamp-bits-sup
At 930, stamp-bits is part of $?, giving 'ln -s stamp-bits
<other-stuff> .'. I'm a bit vague on what this stamp-bits file does,
though, so I'm unsure of the best fix. Replacing $? with
${bits_sup_headers} on 930 resulted in something that didn't build
correctly, so presumably not that. Adding a line after 930 to replace
the symlink with a regular timestamp file seems to work okay, though:
@-cd ${bits_builddir} && rm -f stamp-bits && $(STAMP) stamp-bits
Seem like a decent fix? If not, what might be the alternatives? Thanks.
--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902