[SR-1412] Cannot compile Foundation on ARM Created: 4 May 2016  Updated: 23 Jan 2018

Status: Open
Project: Swift
Component/s: Foundation

Type: Bug Priority: Medium
Reporter: Ryan Lovelett Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: arm, armv7
Environment:

OS: Ubuntu 16.04 xenial
Kernel: armv7l Linux 4.4.0-1009-raspi2
CPU: ARMv7 rev 5 (v7l) @ 900MHz


Attachments: File 0001-A-proposed-fix.patch     File stdarg.h     File stdio.h    

 Description   

While compiling CFString on ARM (Raspberry Pi 2) I am running into a perplexing issue. It appears that the va_list typedef is being defined multiple times.

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CoreFoundation.h:58:10: note: in file included from /home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CoreFoundation.h:58:
#include <CoreFoundation/CFCalendar.h>
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFCalendar.h:21:10: note: in file included from /home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFCalendar.h:21:
#include <CoreFoundation/CFTimeZone.h>
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFTimeZone.h:23:10: note: in file included from /home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFTimeZone.h:23:
#include <CoreFoundation/CFString.h>
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFString.h:265:123: error: reference to 'va_list' is ambiguous
CFStringRef CFStringCreateWithFormatAndArguments(CFAllocatorRef alloc, CFDictionaryRef formatOptions, CFStringRef format, va_list arguments) CF_FORMAT_FUNCTION(3,0);
                                                                                                                          ^
/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/clang/include/stdarg.h:30:27: note: candidate found by name lookup is 'va_list'
typedef __builtin_va_list va_list;
                          ^
/usr/include/stdio.h:79:20: note: candidate found by name lookup is 'va_list'
typedef _G_va_list va_list;

It would seem that va_list is being defined by multiple things in the include path.



 Comments   
Comment by Jordan Rose [ 4 May 2016 ]

<stdio.h> really shouldn't be defining va_list itself. Is it just failing to include the proper header?

Comment by Ryan Lovelett [ 4 May 2016 ]

I thought the same thing until I opened up /usr/include/stdio.h. Relevant exerpt:

#if defined __USE_XOPEN || defined __USE_XOPEN2K8
# ifdef __GNUC__
#  ifndef _VA_LIST_DEFINED
typedef _G_va_list va_list;
#   define _VA_LIST_DEFINED
#  endif
# else
#  include <stdarg.h>
# endif
#endif

(It is the exact same on my x86_64 machine)

Not sure what you mean about the proper header though. I assume the proper header is []/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/clang/include/stdarg.h which does, at least appear, to be included properly.

Comment by Jordan Rose [ 4 May 2016 ]

…no, it's not. They assume that any __GNUC__ compiler will use _G_va_list as the va_list type. But Clang bills itself as a __GNUC__ compiler. (And honestly, that still seems shortsighted. What if GCC wants to redo va_lists at some point?)

Maybe you should just disable __USE_XOPEN for now.

Comment by Ryan Lovelett [ 4 May 2016 ]

Doh. You are right it is not. I thought I was not SSH-ed on the Pi when I looked. Sorry for the confusion.

Comment by Ryan Lovelett [ 4 May 2016 ]

It also seems unfortunate that the clang header <stdarg.h> defines _VA_LIST when defining the va_list macro and <stdio.h> checks _VA_LIST_DEFINED. Yet another near miss.

Comment by Jordan Rose [ 4 May 2016 ]

Ah, yeah, that might be a better way around this. Just unconditionally defined _VA_LIST_DEFINED for now, and hope the order of includes is correct.

Comment by Ryan Lovelett [ 4 May 2016 ]

Sadly that did not do the trick. Now it is stranger. I added -Xcc -D_VA_LIST_DEFINED to the compiler command.

/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-armv7/bin/swift -frontend -c Foundation/NSObject.swift Foundation/NSAffineTransform.swift Foundation/NSArray.swift Foundation/NSAttributedString.swift Foundation/NSBundle.swift Foundation/NSByteCountFormatter.swift Foundation/NSCache.swift Foundation/NSCalendar.swift Foundation/NSCFArray.swift Foundation/NSCFDictionary.swift Foundation/NSCFSet.swift Foundation/NSCFString.swift Foundation/NSCharacterSet.swift Foundation/NSCoder.swift Foundation/NSComparisonPredicate.swift Foundation/NSCompoundPredicate.swift Foundation/NSConcreteValue.swift Foundation/NSData.swift Foundation/NSDate.swift Foundation/NSDateComponentsFormatter.swift Foundation/NSDateFormatter.swift Foundation/NSDateIntervalFormatter.swift Foundation/NSDecimal.swift Foundation/NSDecimalNumber.swift Foundation/NSDictionary.swift Foundation/NSEnergyFormatter.swift Foundation/NSEnumerator.swift Foundation/NSError.swift Foundation/NSExpression.swift Foundation/NSFileHandle.swift Foundation/NSFileManager.swift Foundation/NSFormatter.swift Foundation/NSGeometry.swift Foundation/NSHost.swift Foundation/NSHTTPCookie.swift Foundation/NSHTTPCookieStorage.swift Foundation/NSIndexPath.swift Foundation/NSIndexSet.swift Foundation/NSJSONSerialization.swift Foundation/NSKeyedCoderOldStyleArray.swift Foundation/NSKeyedArchiver.swift Foundation/NSKeyedUnarchiver.swift Foundation/NSLengthFormatter.swift Foundation/NSLocale.swift Foundation/NSLock.swift Foundation/NSLog.swift Foundation/NSMassFormatter.swift Foundation/NSNotification.swift Foundation/NSNotificationQueue.swift Foundation/NSNull.swift Foundation/NSNumber.swift Foundation/NSNumberFormatter.swift Foundation/NSObjCRuntime.swift Foundation/NSOperation.swift Foundation/NSOrderedSet.swift Foundation/NSPathUtilities.swift Foundation/NSPersonNameComponents.swift Foundation/NSPersonNameComponentsFormatter.swift Foundation/NSPort.swift Foundation/NSPortMessage.swift Foundation/NSPredicate.swift Foundation/NSProcessInfo.swift Foundation/NSProgress.swift Foundation/NSPropertyList.swift Foundation/NSRange.swift Foundation/NSRegularExpression.swift Foundation/NSRunLoop.swift Foundation/NSScanner.swift Foundation/NSSet.swift Foundation/NSSortDescriptor.swift Foundation/NSSpecialValue.swift Foundation/NSStream.swift Foundation/NSString.swift Foundation/String.swift Foundation/NSSwiftRuntime.swift Foundation/NSTask.swift Foundation/NSTextCheckingResult.swift Foundation/NSThread.swift Foundation/NSTimer.swift Foundation/NSTimeZone.swift Foundation/NSURL.swift Foundation/NSURLAuthenticationChallenge.swift Foundation/NSURLCache.swift Foundation/NSURLCredential.swift Foundation/NSURLCredentialStorage.swift Foundation/NSURLError.swift Foundation/NSURLProtectionSpace.swift Foundation/NSURLProtocol.swift Foundation/NSURLRequest.swift Foundation/NSURLResponse.swift Foundation/NSURLSession.swift Foundation/NSUserDefaults.swift Foundation/NSUUID.swift Foundation/NSValue.swift Foundation/NSXMLDocument.swift Foundation/NSXMLDTD.swift Foundation/NSXMLDTDNode.swift -primary-file Foundation/NSXMLElement.swift Foundation/NSXMLNode.swift Foundation/NSXMLNodeOptions.swift Foundation/NSXMLParser.swift Foundation/FoundationErrors.swift -Xcc -D_VA_LIST_DEFINED -I/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/linux -Xcc -fblocks -target armv7-unknown-linux-gnueabihf   -Ibootstrap/common/usr/include -Ibootstrap/common/usr/local/include   -Ibootstrap/armv7-linux-gnueabihf/usr/include -Ibootstrap/armv7-linux-gnueabihf/usr/local/include -O  -I../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation -I../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift -I../build/Ninja-ReleaseAssert/foundation-linux-armv7 -I../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift -I/usr/include/libxml2 -I/home/ryan/Source/build/Ninja-ReleaseAssert/xctest-linux-armv7 -L/home/ryan/Source/build/Ninja-ReleaseAssert/xctest-linux-armv7 -I/usr/include/libxml2 -module-name Foundation -module-link-name Foundation -o ../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/Foundation/NSXMLElement.swift.o -emit-module-path ../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/Foundation/NSXMLElement.swift.o.~partial.swiftmodule -emit-module-doc-path ../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/Foundation/NSXMLElement.swift.o.~partial.swiftdoc -emit-dependencies-path ../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/Foundation/NSXMLElement.swift.o.d -emit-reference-dependencies-path ../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/Foundation/NSXMLElement.swift.o.swiftdeps -module-cache-path ../build/Ninja-ReleaseAssert/foundation-linux-armv7

Now it fails after apparently importing <stdarg.h> twice. What?

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CoreFoundation.h:58:10: note: in file included from /home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CoreFoundation.h:58:
#include <CoreFoundation/CFCalendar.h>
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFCalendar.h:21:10: note: in file included from /home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFCalendar.h:21:
#include <CoreFoundation/CFTimeZone.h>
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFTimeZone.h:23:10: note: in file included from /home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFTimeZone.h:23:
#include <CoreFoundation/CFString.h>
         ^
/home/ryan/Source/swift-corelibs-foundation/../build/Ninja-ReleaseAssert/foundation-linux-armv7/Foundation/usr/lib/swift/CoreFoundation/CFString.h:265:123: error: reference to 'va_list' is ambiguous
CFStringRef CFStringCreateWithFormatAndArguments(CFAllocatorRef alloc, CFDictionaryRef formatOptions, CFStringRef format, va_list arguments) CF_FORMAT_FUNCTION(3,0);
                                                                                                                          ^
/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/clang/include/stdarg.h:30:27: note: candidate found by name lookup is 'va_list'
typedef __builtin_va_list va_list;
                          ^
/home/ryan/Source/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/clang/include/stdarg.h:30:27: note: candidate found by name lookup is 'va_list'
typedef __builtin_va_list va_list;
Comment by Ryan Lovelett [ 6 May 2016 ]

TARGET_SWIFTCFLAGS = -Xcc -D_VA_LIST works; though TARGET_SWIFTCFLAGS = -Xcc -D_VA_LIST_DEFINED does not.

I will not pretend I understand why that works.

(Added my stdarg.h and /usr/include/stdio.h incase it was of interest)

Comment by Karl [ 10 May 2016 ]

VA_LIST is a web of typedefs and if Clang can't trace all the threads and find out that they're the same (builtin) type, it fails.

I managed to resolve this by editing lib/swift/clang/include/stdarg.h

#ifndef __STDARG_H
#define __STDARG_H

#ifndef _VA_LIST
#include <_G_config.h>                // <---- This is the line. Must precede the typedef.
typedef __builtin_va_list va_list;
#define _VA_LIST
#endif

Also, you'll need to add an #include <cstdarg> with the other standard includes in CoreFoundation/Base.subProj/CoreFoundation.h

Comment by Robert F. Dickerson [ 12 May 2016 ]

I can confirm that you solution above works to eventually build Foundation. However as the compilation proceeds at the llbuild step, the following `memory corruption` error occurs:

Error in `/home/pi/swift_src/build/buildbot_linux/llbuild-linux-armv7/bin/swift-build-tool': malloc(): memory corruption: 0x76c6357e ***

Comment by Karl [ 31 May 2016 ]

Looks like we can just remove the stdio include. I'm not confident about it - it doesn't seem like it'd addressing the underlying issue (I think clang's being weird because this is in the CF module includes), but apparently we didn't need this include anyway so it's some kind of fix.

https://github.com/apple/swift-corelibs-foundation/pull/399

Generated at Mon Dec 10 22:31:17 CST 2018 using Jira 7.13.0#713000-sha1:fbf406879436de2f3fb1cfa09c7fa556fb79615a.