Open Flamefire opened 9 months ago
It would likely be easier to debug using a local FreeBSD. That assumes you have debugging ideas in mind, such as extra flags to increase the verbosity of the errors, or some other methods.
At a relatively low price per hour, you could launch an AWS instance. SSH in locally. Terminate the server when it's done. Only pay for a few days of operation. https://aws.amazon.com/marketplace/pp/prodview-ukzmy5dzc6nbq
Let me know if you are intending to do this, and would like me to create such an instance in our account.
What packages are installed on the dronerunner? https://github.com/cppalliance/ansible-dronerunner/blob/master/vars/FreeBSD-family.yml
FreeBSD built one year ago. https://drone.cpp.al/boostorg/locale/22.
A brute force method could be to add multiple CI jobs:
- gcc11
- gcc10
- gcc9
- gcc8
- llvm15
- llvm14
- llvm13
- llvm12
- llvm11
- llvm10
Test the version of locale from a year ago.
I tested that version and it seems the FreeBSD image has changed. I now run into an ICU related issue that wasn't there before: It includes an iconv.h from inside the ICU folder which has different symbols than the glibc iconv and hence requires explicit linking against libiconv
Anyway I started a couple test jobs to see if I can reduce the issue a bit and might try running FreeBSD in a local VM
I now run into an ICU related issue
In the list of packages, icu
was installed, probably because another boost library required it, git commit dated 2022-10-11.
I see. I now tested the old Locale version with all compilers and the Clang version works while all GCC versions segfault. So the symbol issue on Clang happens only on develop. Will try it locally first if I get the VM running.
BTW: Searching for other repos using FreeBSD jobs I've seen:
# from https://github.com/boostorg/boost-ci
load("@ci_automation//ci/drone/:functions.star", "linux_cxx","windows_cxx","osx_cxx","freebsd_cxx", "generate")
So it looks like there are 2 function.star files while that 2nd isn't on Boost.CI despite the comment? Can you publish that? I'm especially worried about potential duplication and differences in the underlying implementations of the *_cxx
functions and how to exactly use generate
The other functions.star
is published at https://github.com/cppalliance/ci-automation. It's a heavily opinionated version of the file written by Alan, for use internally on a few repos.
Am I right assuming the "opinionated" part is only the generate
function (and it's helpers)? If so wouldn't it make sense to fold the *_cxx
functions into the existing file here and load that such that we have less duplication?
See for example adding the new MacOS required adding it to both files where one would have been enough, wouldn't it? (BTW: Thanks for that!)
This is starlark. it has limited capabilities, the files can't access each other, load functions from one file to another file.
Another concern is that https://github.com/drone/drone-convert-starlark has been "archived". They embedded a starlark converter natively. But without support for server-side-includes, such as functions.star
hosted on the drone server.
What do you mean by files can't load functions from other files? Only one level of "load"? Because that function does load functions from another file, doesn't it?
If a function calls other functions, but that isn't possible across files.
Using a local FreeBSD VM I found the following:
Researching the starlark topic again, I think that maybe there were other reasons.
It was to streamline .drone.star as much as possible by only having one load statement. and/or Alan was planning to customize functions at the time.
Multiple starlark load statements do seem to work, at least if they are ordered correctly.
I have trouble with FreeBSD on Drone and would need a hand:
job(compiler='clang-10', cxxstd='11,14,17,20', os='freebsd-13.1')
works but throws warnings for system headers in/usr/local
job(compiler='clang-15', cxxstd='11,14,17,20', os='freebsd-13.1')
fails at runtime withUndefined symbol "_ZTIDu"
job(compiler='gcc-11', cxxstd='11,14,17,20', os='freebsd-13.1', linkflags='-Wl,-rpath=/usr/local/lib/gcc11')
fails at runtime with a seg faultAny idea how to solve or even approach this without a local FreeBSD?