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
[SR-2100] Add support for multi-lib systems #5418
Comments
Good catch, thanks. I'd be happy to accept a patch to swift-corelibs-xctest, if it contains any hardcoded paths to |
Comment by Jeremy Fergason (JIRA) I have a patch that modifies it for the fedora RPMs I am building but I don't think it's in a fit state for the repos. It's one of those things that needs to be done all at once. There were no changes necessary to XCTest except for the location of the Std Lib, Foundation and the module path. |
Could you show your patch in its current form, just so we have an idea of the places that need changing? |
Comment by Felipe Bugno (JIRA) I did successfully created a patch for that on Slackware 14.2 multilib. Attached you guys have it. It was designed to be applied on top of 4.0-RELEASE, and as such, requires that below to test:
After decompressing everything inside some folder, and moving the patch inside that folder, just rename everything to the default Swift build structure:
And then, apply the patch with:
That's it. Now... a observation: Under FHS 3.0 standard ( http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf ), on lib64 all 64bits must go. But, Ubuntu/Debian do not follow the standard, instead using a lib32 and lib structure. To solve that, normally experienced Linux package maintainers define a LIBDIR variable on the build system to be the result of the following command captured: "gcc -print-multi-os-directory". So, on my Slackware system, i have
And on my Ubuntu 17.10 system, i have
My patch is quite brittle, and don't do that. As such, it breaks on Ubuntu/Debian systems. We need to implement on top of that patch a proper detection like that above. Doing that, Swift can become pretty much "Linux agnostic", and as such, could be compiled and packaged to any distribution. For curiosity, that below is the build command that i use: utils/build-script -R -l -b -p --xctest --foundation -i --tvos 1 --watchos 1 \
--no-swift-stdlib-assertions --build-swift-static-stdlib \
--build-swift-static-sdk-overlay --build-swift-stdlib-unittest-extra --skip-test-lldb \
--install-destdir=$PKG --install-prefix=usr --install-swift \
--install-lldb --install-foundation --install-llbuild --install-swiftpm --install-xctest --install-libdispatch \
--swift-install-components='autolink-driver;compiler;clang-builtin-headers;stdlib;swift-remote-mirror;sdk-overlay;license;sourcekit-inproc' \
--reconfigure Tks! |
Attachment: Download
Additional Detail from JIRA
md5: 8786cef65def4eeae0eea5d2859d7870
Issue Description:
On some linux distributions (i.e., the Redhat / CentOS / Fedora family of distros) there is a requirement to use /usr/lib64 instead of /usr/lib on 64-bit machines. The "lib" directory is hard-coded throughout the source code.
I think I have all the places tracked down and have a patch that simply hard-codes it to lib64. It would be nice to make this more flexible and allow the libdir to be specified to build-script.
The text was updated successfully, but these errors were encountered: