Drone FreeBSD failures (warnings, segfault, missing _ZTIDu)

[Flamefire]

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 with Undefined 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 fault

Any idea how to solve or even approach this without a local FreeBSD?

[sdarwin]

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

[sdarwin]

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.
• Test locale now.

[Flamefire]

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

[sdarwin]

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.

[Flamefire]

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

[sdarwin]

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.

[Flamefire]

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!)

[sdarwin]

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.

[Flamefire]

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?

[sdarwin]

If a function calls other functions, but that isn't possible across files.

[Flamefire]

Using a local FreeBSD VM I found the following:

• Undefined symbol "_ZTIDu":
  This is "typeinfo for char8_t" which is defined on Ubuntu in libc++-abi.so but that seemingly doesn't exist on FreeBSD. I see no way around that except not supporting char8_t on FreeBSD libc++ or implementing logic which doesn't rely on typeid for type-erasure of char types.
• Crash with GCC:
  It crashes at the startup in some std-library code with typeinfo references to some streams. Turns out ICU is linked against libc++ but GCC uses libstd++ so we now have 2 std-libraries with clashing symbols. --> Can't use ICU with GCC unless explicitly using libc++

[sdarwin]

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.