Created attachment 259999 [details] patch file that adds the new port
One testbuild on 14.3-BETA2 has issues, see: https://people.freebsd.org/~pi/logs/swift510-5.10.1.log
Two problems according to submitter: 1) build fails if GNU ld is in PATH before ld from the base system 2) timers not working correctly Submitter works on those issues.
Created attachment 260903 [details] revised patch for adding the port I'm attaching a revised patch for adding the port. The new patch fixes many issues with the original patch. One issue that is not fixed is the creation of files in var/run/libuuid during the build. The files are created by the port misc/e2fsprogs-libuuid during its normal operation. The port lang/swift510 uses misc/e2fsprogs-libuuid as a service and cannot be held responsible for the files that that service creates.
Created attachment 261258 [details] one extra patch file I'm attaching a patch file that fixes a problem with initialization of static variables on aarch64. It should be considered an amendment to the big patch for adding the port and should be placed in the 'files' subdirectory of the port.
(In reply to Jordan Gordeev from comment #4) testbuilds@work, sorry for the delay
I got the following <unknown>:0: warning: the '-enable-experimental-cxx-interop' flag is deprecated; please pass '-cxx-interoperability-mode=' instead <unknown>:0: note: Swift will maintain source compatibility for imported APIs based on the selected compatibility mode, so updating the Swift compiler will not change how APIs are imported <unknown>:0: error: unable to open output file '/nonexistent/.cache/clang/ModuleCache/19853H37GFUFQ/SwiftShims-3ONVSK7WGTNL4.pcm': 'Permission denied' <unknown>:0: error: could not build C module 'SwiftShims' ninja: build stopped: subcommand failed. Full log is available at https://kib.kiev.ua/kib/swift510-5.10.1.log
(In reply to Konstantin Belousov from comment #6) my testbuild on 14.3 only failed because the libuuid issue. Log see: https://people.freebsd.org/~pi/logs/swift510-5.10.1.log
(In reply to Jordan Gordeev from comment #3) Adding ${RM} ${STAGEDIR}/var/run/libuuid/* to the do-install target seems to work around the libuuid problem.
Created attachment 261351 [details] Resolve build failure when user's home directory is not writable The problem observed by Konstantin Belousov is because some steps in the build process use the default for the clang module cache path which is $HOME/.cache/clang/ModuleCache. When the user's home directory is not writable (e.g. because it doesn't exist), the build fails. I'm attaching a patch that resolves the problem. This patch is supposed to be applied to the ports tree after the big patch that adds the port.
The situation with the leftover files in var/run/libuuid is as follows: The port misc/e2fsprogs-libuuid has two major components: a library (libuuid) and a daemon (uuidd). The library generates UUIDs. The daemon helps clients of the library avoid generating duplicate UUIDs. The leftover files belong to the daemon and are its PID file, the socket which clients use to make requests and some internal information that the daemon keeps. The daemon can be configured by the system administrator to run all the time, or alternatively it can be launched on demand and automatically terminate after a period of inactivity. Launching the daemon on demand can happen only if the process using libuuid has sufficient privileges. If you build the port as a non-privileged user, you shouldn't notice any leftover files. For the daemon to do its intended job, it is important that it is shared between all clients of the library. A user may be building the lang/swift510 port while simultaneously using other apps that rely on libuuid. It is inappropriate for the lang/swift510 port to delete files belonging to the uuidd daemon or to stop the daemon because that may interfere with other simultanous use. It is also inappropriate to force the daemon to put its files in a different directory because the whole idea of the daemon is that it is shared. I request understanding of the unique situation and an exception to be made. FreeBSD has some support in the base system for generating UUIDs and in the future the possibility of using that built-in support instead of misc/e2fsprogs-libuuid should be studied.
(In reply to Jordan Gordeev from comment #9) That worked, thanks.
(In reply to Jordan Gordeev from comment #3) I reformatted the Makefile according to the guidance from portclippy from the ports-mgmt/portfmt port and applied your latest patches. I'll do another round of testbuilds.
(In reply to Jordan Gordeev from comment #10) The uuid thing pops up if the port is build using poudriere. So it messes up the build, and there's no 'manual exception' to grant. It needs a solution. Strangly, sometimes the ${RM} ${STAGEDIR}/var/run/libuuid/* works, sometimes it doesn't.
FYI - a commit yesterday to Swift brings FreeBSD support to the development branch - https://github.com/swiftlang/swift/commit/cf2f7154a5c381b794f4fc64a402084da329a85b
(In reply to Jordan Gordeev from comment #3) Testbuilds are ok on 14.2, 14.3, 13.4 (!), but fail on 13.5 and 15.0. See https://people.freebsd.org/~pi/logs/swift510-135-1750278453.txt https://people.freebsd.org/~pi/logs/swift510-150-1750278453.txt 15.0 fails because of the uuid issue, btw. 13.5 fails due to compile problems, as expected. I guess we can let it land for now, if you're OK with that status ?
If you land this new port with the libuuid issue still unresolved, is the result going to be that the port will sometimes build successfully and sometimes will fail to build? The port switching frequently from buildable to unbuildable state and vice versa may cause undesirable stress on the port building infrastructure and the people who monitor the ports and handle build failures. Is there a way to force all poudriere builds for a port to be done as an unprivileged user? This would be a good workaround as the uuidd daemon wouldn't get started and no files would be created by it. Is there a way to detect when a port is being built with poudriere on the official package building cluster? The port's behaviour could change slightly in that environment to delete the /var/run/libuuid files that it would normally not touch.
(In reply to Nathan Reilly from comment #14) Apple has announced FreeBSD support will come in Swift 6.2. There is a GitHub project tracking their progress: https://github.com/orgs/swiftlang/projects/16/views/1 I suspect there’s not much point in pressing on with 5.x.
(In reply to Nathan Reilly from comment #17) Working port is there, and it would be pity to loose the work done. If and when the Apple-provided port appear, it would replace existing work.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=95f54e562650032c2f9b27e9052d51de4237152f commit 95f54e562650032c2f9b27e9052d51de4237152f Author: Jordan Gordeev <jgopensource@proton.me> AuthorDate: 2025-06-22 09:11:40 +0000 Commit: Kurt Jaeger <pi@FreeBSD.org> CommitDate: 2025-06-22 09:11:40 +0000 lang/swift510: New port The Swift programming language -- a modern programming language with many great features. This port includes: * the Swift compiler * the Swift standard library * various tools * the Foundation framework * the Swift Package Manager (SwiftPM) * the run-time support that you need for running compiled programs PR: 286454 Reviewed-by: kib lang/Makefile | 1 + lang/swift510/Makefile (new) | 108 +++ lang/swift510/distinfo (new) | 57 ++ .../files/patch-llbuild_Package.swift (new) | 33 + ...atch-llbuild_include_llvm_Config_config.h (new) | 11 + ...h-llbuild_lib_LLBSQLite3_module.modulemap (new) | 8 + .../patch-llbuild_lib_LLBSQLite3_sqlite.h (new) | 17 + ...build_utils_adjust-times_adjust-times.cpp (new) | 11 + ...clang_tools_IndexStore_IndexStore.exports (new) | 42 + ...project_compiler-rt_cmake_config-ix.cmake (new) | 13 + ...ct_compiler-rt_lib_tsan_dd_CMakeLists.txt (new) | 11 + ...ift-asn1_cmake_modules_SwiftSupport.cmake (new) | 15 + ...ificates_cmake_modules_SwiftSupport.cmake (new) | 15 + ..._CoreFoundation_Base.subproj_CFPlatform.c (new) | 26 + ...ion_Base.subproj_CoreFoundation__Prefix.h (new) | 13 + ...oreFoundation_NumberDate.subproj_CFDate.c (new) | 13 + ...ation_PlugIn.subproj_CFBundle__Internal.h (new) | 11 + ...oreFoundation_RunLoop.subproj_CFRunLoop.c (new) | 324 +++++++ ...ources_Foundation_FileManager+POSIX.swift (new) | 11 + ...tion_Sources_Foundation_FileManager.swift (new) | 29 + ...-foundation_Sources_Foundation_Host.swift (new) | 29 + ...undation_Sources_Foundation_NSError.swift (new) | 20 + ...oundation_Sources_Foundation_NSLock.swift (new) | 28 + ...ation_Sources_Foundation_NSPlatform.swift (new) | 11 + ...n_Sources_Foundation_NSSwiftRuntime.swift (new) | 11 + ...-foundation_Sources_Foundation_Port.swift (new) | 31 + ...undation_Sources_Foundation_Process.swift (new) | 29 + ...oundation_Sources_Foundation_Thread.swift (new) | 38 + ...undation_cmake_modules_SwiftSupport.cmake (new) | 15 + ...dispatch_cmake_modules_SwiftSupport.cmake (new) | 11 + ...ft-corelibs-libdispatch_dispatch_source.h (new) | 29 + ...ch-swift-corelibs-libdispatch_src_apply.c (new) | 10 + ...tch-swift-corelibs-libdispatch_src_data.c (new) | 11 + ...ibs-libdispatch_src_event_event__config.h (new) | 19 + ...ibs-libdispatch_src_event_event__kevent.c (new) | 141 +++ ...orelibs-libdispatch_src_event_workqueue.c (new) | 106 +++ ...bdispatch_src_event_workqueue__internal.h (new) | 11 + ...tch-swift-corelibs-libdispatch_src_init.c (new) | 11 + ...patch-swift-corelibs-libdispatch_src_io.c (new) | 11 + ...ch-swift-corelibs-libdispatch_src_queue.c (new) | 90 ++ ...ift-corelibs-libdispatch_src_shims_lock.c (new) | 70 ++ ...ift-corelibs-libdispatch_src_shims_lock.h (new) | 28 + ...relibs-libdispatch_src_swift_Source.swift (new) | 47 + ...elibs-libdispatch_src_swift_Wrapper.swift (new) | 29 + ...corelibs-libdispatch_tests_CMakeLists.txt (new) | 10 + ...relibs-libdispatch_tests_bsdtestharness.c (new) | 68 ++ ...s-xctest_cmake_modules_SwiftSupport.cmake (new) | 15 + lang/swift510/files/patch-swift-crypto (new) | 686 +++++++++++++++ ...t-driver_Utilities_build-script-helper.py (new) | 22 + ...t-stress-tester_SwiftEvolve_Package.swift (new) | 11 + ...x_cmake_modules_AddSwiftHostLibrary.cmake (new) | 20 + ...h-swift-system_Sources_System_Errno.swift (new) | 50 ++ ..._Sources_System_Internals_Constants.swift (new) | 32 + ...pport-core_Sources_TSCBasic_Process.swift (new) | 29 + ...ort-core_Sources_TSCUtility_FSWatch.swift (new) | 29 + ...Sources_TSCUtility_InterruptHandler.swift (new) | 11 + ...port-core_Sources_TSCUtility_Triple.swift (new) | 28 + ...ift_cmake_modules_AddSwiftUnittests.cmake (new) | 11 + ...h-swift_cmake_modules_SwiftCXXUtils.cmake (new) | 9 + ...ift_cmake_modules_SwiftConfigureSDK.cmake (new) | 11 + ..._Differentiation_DifferentiationInvoker.h (new) | 15 + ...swift_lib_ClangImporter_ClangImporter.cpp (new) | 27 + .../files/patch-swift_lib_IRGen_GenDecl.cpp (new) | 22 + .../files/patch-swift_lib_IRGen_IRGen.cpp (new) | 12 + ...stdlib_cmake_modules_AddSwiftStdlib.cmake (new) | 13 + ...wift_stdlib_public_Cxx_std_CMakeLists.txt (new) | 11 + ...ift_stdlib_public_Platform_Platform.swift (new) | 35 + ...tdlib_public_Platform_glibc.modulemap.gyb (new) | 11 + ...blic_SwiftShims_swift_shims_SwiftStdint.h (new) | 11 + ...tch-swift_stdlib_public_core_CTypes.swift (new) | 12 + ...atch-swift_stdlib_public_stubs_Random.cpp (new) | 11 + ...Kit_cmake_modules_AddSwiftSourceKit.cmake (new) | 11 + ...wift_tools_libStaticMirror_CMakeLists.txt (new) | 11 + ...h-swift_tools_libSwiftScan_CMakeLists.txt (new) | 11 + .../patch-swift_unittests_AST_CMakeLists.txt (new) | 13 + ...ft_unittests_ClangImporter_CMakeLists.txt (new) | 13 + ...tch-swift_unittests_Driver_CMakeLists.txt (new) | 13 + .../patch-swift_unittests_IDE_CMakeLists.txt (new) | 11 + ...atch-swift_unittests_Parse_CMakeLists.txt (new) | 13 + ...patch-swift_unittests_Sema_CMakeLists.txt (new) | 16 + .../patch-swift_utils_build-script-impl (new) | 61 ++ ...t_swift__build__support_products_cmark.py (new) | 7 + ..._support_swift__build__support_targets.py (new) | 20 + ...-swiftpm_Sources_Basics_Cancellator.swift (new) | 11 + ...ics_DispatchTimeInterval+Extensions.swift (new) | 11 + ...wiftpm_Sources_Basics_Triple+Basics.swift (new) | 20 + ...rces_Basics_Vendor_Triple+Platforms.swift (new) | 11 + ...wiftpm_Sources_Basics_Vendor_Triple.swift (new) | 20 + ...ription_ClangTargetBuildDescription.swift (new) | 17 + ...s_Build_BuildPlan_BuildPlan+Product.swift (new) | 11 + ...swiftpm_Sources_SPMSQLite3_CMakeLists.txt (new) | 10 + ...tch-yams_cmake_modules_SwiftSupport.cmake (new) | 15 + lang/swift510/files/pkg-message.in (new) | 2 + lang/swift510/files/start-build.sh (new) | 34 + lang/swift510/pkg-descr (new) | 10 + lang/swift510/pkg-plist (new) | 946 +++++++++++++++++++++ 96 files changed, 4145 insertions(+)
(In reply to Jordan Gordeev from comment #16) The build fails on 13.5 as defined by the BROKEN in Makefile, so it's expected and will consistently fail. The build fail on 15.0 is another issue, and I'll investigate further, with the port in the tree now. Please check, the Makefile had some makeover using portlint, portclippy and portfmt.
(In reply to Nathan Reilly from comment #17) My guess is that Jordan will work on 6.20 as soon as it's released. It will probably take a while so having 5.10 in the tree will not hurt that much.
Thanks to Jordan for his huge work in getting this port done!
(In reply to Nathan Reilly from comment #17) Looking at the https://github.com/swiftlang/swift-evolution history of Announcement and Release dates shows that generally March/late-Feb announcements for new swift versions had a September Release date. The page lists the Swift 6.2 announcement date as 2025-Mar-08, suggesting the official release will again likely be around September.