Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-1923] Building Foundation with lib dispatch support fails with a glibc module error #740

Closed
phausler opened this issue Jun 28, 2016 · 25 comments
Closed

[SR-1923] Building Foundation with lib dispatch support fails with a glibc module error #740

phausler opened this issue Jun 28, 2016 · 25 comments
Labels
bug libdispatch

Comments

@phausler
Copy link
Member

Previous ID SR-1923
Radar None
Original Reporter @phausler
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 1
Component/s libdispatch
Labels Bug
Assignee None
Priority Medium

md5: f5f4c29f9470e2d6aab03501b79a0183

Issue Description:

On Ubuntu 15 with the build command of ./swift/utils/build-script -r --foundation --libdispatch
Swift fails to compile modular components for dispatch:

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
         ^
/home/phausler/Documents/Public/swift-corelibs-libdispatch/dispatch/dispatch.h:60:10: note: in file included from /home/phausler/Documents/Public/swift-corelibs-libdispatch/dispatch/dispatch.h:60:
#include <dispatch/io.h>
         ^
/home/phausler/Documents/Public/swift-corelibs-libdispatch/dispatch/io.h:359:2: error: declaration of 'off_t' must be imported from module 'SwiftGlibc.C.stdio' before it is required
        off_t offset,
        ^
/usr/include/stdio.h:90:17: note: previous declaration is here
typedef __off_t off_t;
                ^
@belkadan
Copy link

cc dgrove-oss (JIRA User), das (JIRA User). I remember this issue came up a while ago, and I see c7f1293 and a535573 as attempts to work around it. (IIRC the issue is that some headers in glibc define off_t themselves rather than importing <sys/types.h>.)

@phausler
Copy link
Member Author

Actually I think this was due to an old checkout that didn't get updated correctly with the update-checkout script; verifying now

@swift-ci
Copy link

Comment by David Grove (JIRA)

@belkadan is correct; those commits are a workaround that should allow master to build. experimental/foundation should also build fine (but with a different workaround).

@phausler
Copy link
Member Author

After updating to the latest everything:

/home/phausler/Documents/Public/swift-corelibs-libdispatch/src/shims.h:248:2: error: unsupported compiler
#error unsupported compiler
 ^

@swift-ci
Copy link

Comment by David Grove (JIRA)

dispatch now requires a fairly recent clang to build. Tony Parker merged apple/swift#2951 about a week ago to compensate for this. Maybe you don't have that change yet?

@phausler
Copy link
Member Author

Looks like my run of update-checkout totally did not do what I was expecting. Re-running manually to update all sources seems to alleviate the problem.

@phausler
Copy link
Member Author

Full clean checkout of the entire project still has build failures; it is choking on a cmake failure now.

CMake Error at cmake/modules/SwiftSharedCMakeConfig.cmake:134 (include):
  include could not find load file:

    ClangTargets
Call Stack (most recent call first):
  cmake/modules/SwiftSharedCMakeConfig.cmake:186 (swift_common_standalone_build_config_clang)
  CMakeLists.txt:362 (swift_common_standalone_build_config)


CMake Error at CMakeLists.txt:368 (message):
  Clang is missing from llvm/tools subdirectory.


-- Configuring incomplete, errors occurred!
See also "/home/phausler/Documents/Public/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/CMakeFiles/CMakeOutput.log".

I have verified that all sob-modules are updated and all repositories are pointed at the public repo urls (not any private forks etc). They are all at the ToT.

@phausler
Copy link
Member Author

Should llvm actually contain clang? It seems like the clone command is broken.

@phausler
Copy link
Member Author

Verified that this is occurring with a 100% clean build:

git clone https://github.com/apple/swift.git
./swift/utils/update-checkout --clone
./swift/utils/build-script -r --foundation --libdispatch

CMake Error at cmake/modules/SwiftSharedCMakeConfig.cmake:134 (include):
  include could not find load file:

    ClangTargets
Call Stack (most recent call first):
  cmake/modules/SwiftSharedCMakeConfig.cmake:186 (swift_common_standalone_build_config_clang)
  CMakeLists.txt:362 (swift_common_standalone_build_config)


CMake Error at CMakeLists.txt:368 (message):
  Clang is missing from llvm/tools subdirectory.


-- Configuring incomplete, errors occurred!

@phausler
Copy link
Member Author 

   ls -al ./llvm/tools/ | grep clang
lrwxrwxrwx  1 phausler phausler   11 Jun 28 15:40 clang -> ../../clang
ls -al ./llvm/tools/../../ | grep clang
drwxrwxr-x 16 phausler phausler 4096 Jun 28 15:36 clang
cd ./llvm/tools/../../clang
git remote -v
origin  https://github.com/apple/swift-clang.git (fetch)
origin  https://github.com/apple/swift-clang.git (push)
git show
commit 67d031edfc77608240bb81b1afccf46c373448fd
Merge: 3d69fdc e010408
Author: swift-ci <swift-ci@users.noreply.github.com>
Date:   Tue Jun 28 13:45:12 2016 -0700

    Merge remote-tracking branch 'origin/swift-3.0-branch' into stable

    * origin/swift-3.0-branch:
      [CMake] Back-port cfe-trunk r274045 and r274056

@belkadan
Copy link

cc @gottesmm

@gottesmm
Copy link
Member

Are you using a new enough cmake? Can you try upgrading to 3.4.3?

@phausler
Copy link
Member Author

Unfortunately I don't think the server I am using can be upgraded to that version

@gottesmm
Copy link
Member

I talked with Phil offline and helped him get an up to date cmake.

@phausler
Copy link
Member Author

I was able to update cmake to be locally installed and that got past that build failure. However more failures abound!

/bin/bash ../libtool    --mode=compile clang++ -DHAVE_CONFIG_H -I. -I/home/phausler/Documents/Public/swift-corelibs-libdispatch/src -I../config  -I.. -I/home/phausler/Documents/Public/swift-corelibs-libdispatch -I/home/phausler/Documents/Public/swift-corelibs-libdispatch/private -DDISPATCH_USE_DTRACE=0 -Wall -fvisibility=hidden -momit-leaf-frame-pointer  -I/usr/include/kqueue   -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -fblocks -g -O2 -c -o swift/Dispatch.lo /home/phausler/Documents/Public/swift-corelibs-libdispatch/src/swift/Dispatch.mm
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
make[2]: *** [swift/Dispatch.lo] Error 1
make[2]: Leaving directory `/home/phausler/Documents/Public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/phausler/Documents/Public/build/Ninja-RelWithDebInfoAssert/libdispatch-linux-x86_64/src'
make: *** [all-recursive] Error 1
./swift/utils/build-script: fatal error: command terminated with a non-zero exit status 2, aborting

@phausler
Copy link
Member Author

So it is attempting to compile objective-c? Are we building against the apple objc runtime or the gnu? Or is this file somehow not supposed to be built on linux?

@belkadan
Copy link

Yeah, a file named dispatch.mm seems like it's asking for trouble.

@phausler
Copy link
Member Author

Pshaw on the name; the code is the issue -

#include <objc/runtime.h>
#include <stdio.h>

#define DISPATCH_RUNTIME_STDLIB_INTERFACE __attribute__((__visibility__("default")))

@protocol OS_dispatch_source;
@protocol OS_dispatch_source_mach_send;
@protocol OS_dispatch_source_mach_recv;
@protocol OS_dispatch_source_memorypressure;
@protocol OS_dispatch_source_proc;
@protocol OS_dispatch_source_read;
@protocol OS_dispatch_source_signal;
@protocol OS_dispatch_source_timer;
@protocol OS_dispatch_source_data_add;
@protocol OS_dispatch_source_data_or;
@protocol OS_dispatch_source_vnode;
@protocol OS_dispatch_source_write;

// #include <dispatch/private.h>
__attribute__((constructor))
static void _dispatch_overlay_constructor() {
  Class source = objc_lookUpClass("OS_dispatch_source");
  if (source) {
    class_addProtocol(source, @protocol(OS_dispatch_source));
    class_addProtocol(source, @protocol(OS_dispatch_source_mach_send));
    class_addProtocol(source, @protocol(OS_dispatch_source_mach_recv));
    class_addProtocol(source, @protocol(OS_dispatch_source_memorypressure));
    class_addProtocol(source, @protocol(OS_dispatch_source_proc));
    class_addProtocol(source, @protocol(OS_dispatch_source_read));
    class_addProtocol(source, @protocol(OS_dispatch_source_signal));
    class_addProtocol(source, @protocol(OS_dispatch_source_timer));
    class_addProtocol(source, @protocol(OS_dispatch_source_data_add));
    class_addProtocol(source, @protocol(OS_dispatch_source_data_or));
    class_addProtocol(source, @protocol(OS_dispatch_source_vnode));
    class_addProtocol(source, @protocol(OS_dispatch_source_write));
  }
}

@belkadan
Copy link

Hm. All of that is only so that casting works on Darwin platforms with Swift < 3.0, so we shouldn't need it. (I'm working on casting in Swift 3 on Darwin platforms.)

That said, I now have no idea how the Dispatch folks are planning to have their types still import as Swift-compatible classes. Is the plan to just write wrappers by hand?

@phausler
Copy link
Member Author

Makefile.in has

@HAVE_SWIFT_TRUE@am__append_5 = swift/Dispatch.mm

Should that section have a guard for USE_OBJC? And why is it objcxx? The other .m files compile just fine (objcxx always has cross platform build issues from my experience)

@swift-ci
Copy link

Comment by David Grove (JIRA)

Hi. Sorry, I should have mentioned this yesterday. Kind of forgot I was working on a branch of dispatch myself.

das (JIRA User) merged in the Swift3 overlay to libdispatch last week on the master branch. We knew it wouldn't build. I've gotten them building (including dealing with dispatch.mm) and submitted a pull request #94 Until that gets merged, the master branch of dispatch isn't going to build via swift/utils/build-script (because that enables the Swift overlay being built).

@phausler
Copy link
Member Author

Which part of casting? DispatchData to NSData to Data? Or dispatch_data_t to DispatchData?

@belkadan
Copy link

AnyObject to DispatchQueue.

@swift-ci
Copy link

Comment by Reza Hussain (JIRA)

Does anybody have instructions to get this to build on a ubuntu 15.10 fresh install ?

@swift-ci
Copy link

Comment by David Grove (JIRA)

building dispatch + foundation together is now part of the normal build process on linux.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug libdispatch
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@phausler @gottesmm @belkadan @swift-ci