For RedHat/CentOS (not sure about Fedora) there is better way to install Swift with all dependencies in non-conflicting way than alternatives. It's called Software Collection (official guide).
SCL is separate 'namespace' which can be activated on demand for single command or whole shell. It's designed to allow coexistence of different versions of same software like multiple versions of Python, PHP or - in this case - Swift.
Example structure:
In SCL convention, metapackage would be named 'swift', i.e. 'swift41' and depend on 'swift41-swift', 'swift41-lldb', etc.
Normally, swift would be unavailable and installed default LLDB would be available. After 'scl enable swift41 bash', in current bash session Swift 4.1 would be available with LLDB from 'swift41-lldb' package while original LLDB would be unavailable.
Until we get to the point where any swift lldb can debug output from any swift compiler, I'm not sure installing swift & lldb in some common directory (/usr/bin or wherever) is the best way to do this. Swift is slowing down somewhat, but people often need to support some older swift project which they don't want to have to update to the latest Swift syntax, while also wanting to play around with a newer swift compiler. To do that you at present you need to segregate the different toolchains and allow user to switch among them. Just changing the name of the swift binaries doesn't address this problem.
I concur that I'd like to just have the entire Swift toolchain in its own directory; I personally have it under /usr/local/swift- with a /usr/local/swift symlink to it, makes for very easy going back-and-forth between 3 and 4 and 4.1-dev. From a packaging perspective, official Fedora package guidelines do not allow for installation under /usr/local; not sure what the Debian/Ubuntu policies.
Maybe we should wait for official packaging until Swift 5?
I did some digging and Fedora explicitly forbids this. But outside of official Fedora packaging it looks really cool; I'm going to read up and see if an unofficial version could be made (though there's already existing flavors of doing that).
Looking through the reference filesystem specs I wonder if it'd be simpler to just have the swift binary look for lldb and accompanying files in /usr/libexec/swift-lang; this way there doesn't need to be 'grand renaming' of anything.
I'm going to go down this particular road for the time being to see if it leads anywhere.
Hey, success! I modified lib/Driver/ToolChains.cpp in the ToolChain::constructInvocation method I found the spot where it's looking up lldb relative to the swift binary; it appears that the very last line in the method is actually returning the file to execute, so I modified it from return {"lldb", Arguments}; to return {"/usr/libexec/swift/lldb", Arguments};. Then I explicitly copied the lldb binaries to that directory, placed the $BUILD/usr/lib files under /usr/lib64/swift, explicitly added that to $LD_LIBRARY_PATH, and fired up the Swift REPL from the /usr/bin directory.
Since this all this is just for packaging, I can patch the Toolchains.cpp file as described above during the package build, set up the package layout, and we should be in business.
Now on creating the patch and adding it to my spec file and we'll see how it goes...
I was able to resolve all the known outstanding issues, and have a test RPM available:
I tried out the latest build for Fedora 27 this evening. When I tried interacting with the REPL specifically import Foundation it would error.
Welcome to Swift version 4.1-dev. Type :help for assistance.
1> import Foundation
/usr/lib/swift-lldb/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /usr/lib/swift-lldb/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
^
<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "///usr/include/utmp.h"
^
///usr/include/utmp.h:23:10: note: in file included from ///usr/include/utmp.h:23:
#include <sys/types.h>
^
error: /usr/include/sys/types.h:145:10: error: 'stddef.h' file not found
#include <stddef.h>
^
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
^
error: /usr/lib/swift-lldb/swift/CoreFoundation/CoreFoundation.h:25:10: error: could not build module 'SwiftGlibc'
#include <sys/types.h>
^
/usr/lib/swift-lldb/swift/CoreFoundation/CFStream.h:20:10: note: while building module 'CDispatch' imported from /usr/lib/swift-lldb/swift/CoreFoundation/CFStream.h:20:
#include <dispatch/dispatch.h>
^
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
^
/usr/lib/swift-lldb/swift/dispatch/dispatch.h:30:10: note: in file included from /usr/lib/swift-lldb/swift/dispatch/dispatch.h:30:
#include <os/generic_unix_base.h>
^
/usr/lib/swift-lldb/swift/os/generic_unix_base.h:17:10: note: in file included from /usr/lib/swift-lldb/swift/os/generic_unix_base.h:17:
#include <sys/sysmacros.h>
^
error: /usr/include/sys/sysmacros.h:39:10: error: could not build module 'SwiftGlibc'
#include <features.h>
^
error: could not build C module 'CoreFoundation'
Perhaps this is unrelated to your change. I just thought I'd pass it along.
@Ron_Olson sounds like you may want to test your installation against the integration test suite. We use it to catch issues like @rlovelett ran into (just a friendly suggestion).
Yes, that seems to have been an issue for awhile. The workaround is to invoke it like:
[rolson@tachotest1 ~]$ swift -I /usr/lib/swift-lldb/swift/clang/include/
Welcome to Swift version 4.1-dev. Type :help for assistance.
1> import Foundation
2> import Glibc
3> import Dispatch
4> print("hello world (6*7)")
hello world 42
5>
I found out about this via https://bugs.swift.org/browse/SR-3648. I tried setting rw on CoreFoundation as one of the other messages suggests, but that didn’t work.
Also if running in a container, don’t forget to include --privileged when starting it.
February 16I tried out the latest build for Fedora 27 this evening. When I tried interacting with the REPL specifically
import Foundationit would error.
> Welcome to Swift version 4.1-dev. Type :help for assistance.
> 1> import Foundation
> /usr/lib/swift-lldb/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /usr/lib/swift-lldb/swift/CoreFoundation/CoreFoundation.h:25:
> #include <sys/types.h>
> ^
> <module-includes>:3:10: note: in file included from <module-includes>:3:
> #include "///usr/include/utmp.h"
> ^
> ///usr/include/utmp.h:23:10: note: in file included from ///usr/include/utmp.h:23:
> #include <sys/types.h>
> ^
> error: /usr/include/sys/types.h:145:10: error: 'stddef.h' file not found
> #include <stddef.h>
> ^
> <module-includes>:1:10: note: in file included from <module-includes>:1:
> #include "CoreFoundation.h"
> ^
> error: /usr/lib/swift-lldb/swift/CoreFoundation/CoreFoundation.h:25:10: error: could not build module 'SwiftGlibc'
> #include <sys/types.h>
> ^
> /usr/lib/swift-lldb/swift/CoreFoundation/CFStream.h:20:10: note: while building module 'CDispatch' imported from /usr/lib/swift-lldb/swift/CoreFoundation/CFStream.h:20:
> #include <dispatch/dispatch.h>
> ^
> <module-includes>:1:10: note: in file included from <module-includes>:1:
> #include "dispatch.h"
> ^
> /usr/lib/swift-lldb/swift/dispatch/dispatch.h:30:10: note: in file included from /usr/lib/swift-lldb/swift/dispatch/dispatch.h:30:
> #include <os/generic_unix_base.h>
> ^
> /usr/lib/swift-lldb/swift/os/generic_unix_base.h:17:10: note: in file included from /usr/lib/swift-lldb/swift/os/generic_unix_base.h:17:
> #include <sys/sysmacros.h>
> ^
> error: /usr/include/sys/sysmacros.h:39:10: error: could not build module 'SwiftGlibc'
> #include <features.h>
> ^
> error: could not build C module 'CoreFoundation'
Yep, was going to revisit that; first time I tried it, way-back-when, my computer exploded with errors, but that was before Swift was building successfully, so I tabled it.
How would you pass that include to LLDB for debugging? I'm trying to debug a compiled program in LLDB and it is failing to see my types with roughly the same errors. Though I'm not sure how I pass the -I /usr/lib/swift-lldb/swift/clang/include/ path.
Nevermind I just made an Ubuntu 16.04 build and installed the build from Swift.org. This is a problem in the actual Swift package. I'll see if I can figure out how to report upstream.
Yes, I had similar issues from the get-go, even with the official Ubuntu build back in the 3-days. I've been doing the ol' fallback print()-level debugging. I figured to start with getting Swift built on Fedora as a way of getting more familiar with the code base before trying to dive in and tacking this problem, as it is pretty frustrating.
Do you have any interest in updating the copr repo to use the released 4.1? If not I'm fine with trying my hand at building myself.
Funny enough I'm working on that right now. It'll be at tachoknight/swift-lang Copr. Sorry it's taken awhile; I've been dealing with unrelated issues at work.
I've updated the copr repo with a newer version. There are two tracks I'm trying to pursue (with limited success): allowing Swift to find everything in /usr/lib64 (for Fedora packaging) and trying to fix, once and for all (complete with appropriate pull requests, the 'error: failed to launch REPL process: process launch failed: 'A' packet returned an error: -1' issue.
On the first issue I've gotten to the point where the swift-packaging project causes a compiler error, and on the second, I'm still deep in the weeds of how Swift is looking for its associated libs.
Definitely been interesting to see how a compiler toolchain is put together!
As an update, I abandoned the effort to make Swift work under lib64 and determined that it's not really necessary anyway; the .so files don't get dumped willy-nilly in /usr/lib, but are neatly contained in subdirectories; there are a lot of places where "lib" is hard-coded (in flavors of /lib/, lib/, etc.).
The latest copr builds, built from the April 15th release, are available, and I'm working on putting together a script to track the Apple releases automatically.
Regarding the problems using LLDB to debug Swift code on Linux, I recently landed a bunch of improvements on the swift-4.2-branch that should make LLDB much more robust at finding the correct clang headers and importing Swift modules that depend on Clang modules. Please do let me know if you find more problems getting LLDB or the Swift REPL to work!
Sure thing Adrian! I'll make a special build and check it out.