This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]