[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#776965: llvm-toolchain-3.6: FTBFS on hurd-i386



Source: llvm-toolchain-3.6
Version: 1:3.6~+rc2-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

Currently llvmtoolchain-3.6 (~+rc1-1 and ~+rc2-1) fails to build from
source due to usage of a reserved identifier in C/C++11/POSIX.1, see
e.g.:

http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
Other restrictions might apply. For example, the POSIX standard reserves
a lot of identifiers that are likely to show up in normal code:
*Names beginning with a capital 'E' followed a digit or uppercase letter
  *may be used for additional error code names.

http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
Some additional classes of identifier names are reserved for future
extensions to the C language or the POSIX.1 environment. While using
these names for your own purposes right now might not cause a problem,
they do raise the possibility of conflict with future versions of the C
or POSIX standards, so you should avoid these names.
...
Names beginning with a capital ‘E’ followed a digit or uppercase letter
may be used for additional error code names. See Error Reporting.

http://docs.oracle.com/cd/E19205-01/819-5265/bjaky/index.html
Sun Studio 12: C User's Guide
6.8.3 Names Reserved for Expansion
In addition to all the names explicitly reserved, the 1990 ISO/IEC C
standard also reserves (for implementations and future standards) names
matching certain patterns:
Table 6–3 Names Reserved for Expansion
errno.h E[0-9A-Z].*

ISO/IEC 9899:TC3 Committee Draft — September 7, 2007 WG14/N1256
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
page 166: 7.1.3 Reseved Identifiers

The attached patch hurd.diff fixes that by renaming EIOIO to E_IOIO. 
The already included patch: hurd-EIEIO-undef.diff is non-functional and
should be removed. Since this is a standard violation, this patch should
be submitted upstream.

Test summary from the build is:
  Expected Passes    : 7892
  Expected Failures  : 14
  Unsupported Tests  : 23
  Unexpected Failures: 16

Additionally the patch debian_rules.diff adds an option to help2man:
--no-discard-stderr to get output even if --help is written to stderr.
This changes is made unconditionally, but could be modified of course if
it causes problems for other architectures.

Thanks!
Index: llvm-toolchain-3.6-3.6~+rc1/lib/Target/PowerPC/PPCInstrInfo.td
===================================================================
--- llvm-toolchain-3.6-3.6~+rc1.orig/lib/Target/PowerPC/PPCInstrInfo.td
+++ llvm-toolchain-3.6-3.6~+rc1/lib/Target/PowerPC/PPCInstrInfo.td
@@ -3134,7 +3134,7 @@ def ISYNC : XLForm_2_ext<19, 150, 0, 0,
 def ICBI : XForm_1a<31, 982, (outs), (ins memrr:$src),
                     "icbi $src", IIC_LdStICBI, []>;
 
-def EIEIO : XForm_24_eieio<31, 854, (outs), (ins),
+def E_IEIO : XForm_24_eieio<31, 854, (outs), (ins),
                            "eieio", IIC_LdStLoad, []>;
 
 def WAIT : XForm_24_sync<31, 62, (outs), (ins i32imm:$L),
--- a/debian/rules.orig	2015-01-14 19:45:58.000000000 +0100
+++ b/debian/rules	2015-02-02 03:15:49.000000000 +0100
@@ -256,7 +256,7 @@
 	CMDS="llvm-dwarfdump llvm-mc llvm-mcmarkup llvm-objdump llvm-rtdyld llvm-size llvm-tblgen llvm-ranlib macho-dump lldb clang-format clang-modernize clang clang-tblgen clang-check clang-tidy clang-apply-replacements pp-trace"; \
 	for f in $$CMDS; do \
 		echo "Generating manpage of $$f"; \
-		LD_LIBRARY_PATH=$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ help2man --version-string=$(LLVM_VERSION) $(TARGET_BUILD)/Release/bin/$$f > debian/man/$$f-$(LLVM_VERSION).1; \
+		LD_LIBRARY_PATH=$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ help2man --no-discard-stderr --version-string=$(LLVM_VERSION) $(TARGET_BUILD)/Release/bin/$$f > debian/man/$$f-$(LLVM_VERSION).1; \
 	done
 
 override_dh_auto_install:

Reply to: