Update docker-build-static.yml add FreeBSD static build

[n-connect]

Add x86_64-unknown-freebsd static build, create tar.gz from static builds

[nitnelave]

Pardon my ignorance, but since this is a statically linked binary without dependencies, can't you run the Linux version of the binary? How is freebsd special in that respect?

[nitnelave]

Oh, duh, different kernels, the syscalls are different. Pardon the derp

[nitnelave]

You'll need to install rust for freebsd as well: "consider downloading the target with rustup target add x86_64-unknown-freebsd"

[n-connect]

Hi @nitnelave

Yes, your are right. As there are different low level kernel elements when you change the CPU/SOC family: armv7 aarm64 vs amd64, here even a completely different OS underlying. But luckily its a Rust code, so after a rustup target add x86_64-unknown-freebsd it should just compile it. If a toolchain exist in Rust/cargo/cross theoretically it (compilation) should just work. Checkout other codes like this https://github.com/nextcloud/notify_push/releases/tag/v0.6.9

Answering the last one:

It's not AMD, can you fix the binary name?

It is amd64 an actual build starts with this cargo --build x86_64-unknown-freebsd I used the naming based on that and the other already used naming conventions in the "docker-build-static.yml". I'm happy to change in between thing, I think the final tar.gz filename should stand

[n-connect]

@nitnelave,

Based on your review, the build name changed: instead of "build_x86_freebsd" to "x86_64-unknown-freebsd" in the commented line 37.

I think a rustup target add x86_64-unknown-freebsd line should be added somewhere too, at least on my fork the GitHub Actions are failed because lack of that.

[n-connect]

It seems there's a linker issue (ld) in the building docker image. I've checked Dockerfile.dev. There you are specifying cc compilers per target. Following the links, I think it could be x86_64-linux-musl-cross.tgz it needs. Although I'm not sure I've never used them like that before. I've either used the target directly, or installed cross and used that. Will check with a local build using rust docker.

[martadinata666]

So freebsd approach wise likely want to use CLANG rather normal gcc. The best sample I can get is from https://github.com/smartmontools/docker-build/blob/master/Dockerfile#L77. That in simple term use clang, fetch freebsd libs. Then following suit to development file

    CARGO_TARGET_ARMV7_UNKNOWN_LINUX_MUSLEABIHF_LINKER=armv7l-linux-musleabihf-gcc \
    CARGO_TARGET_AARCH64_UNKNOWN_LINUX_MUSL_LINKER=aarch64-linux-musl-gcc \
    CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=x86_64-linux-musl-gcc \
    CARGO_TARGET_X86_64_UNKNOWN_FREEBSD_LINKER=clang++ \
    CC_armv7_unknown_linux_musleabihf=armv7l-linux-musleabihf-gcc \
    CC_x86_64_unknown_linux_musl=x86_64-linux-musl-gcc \
    CC_aarch64_unknown_linux_musl=aarch64-linux-musl-gcc \
    CC_x86_64_unknown_freebsd=clang++

Maybe just clang? or clang++? Trial error begins.

There is also https://github.com/marketplace/actions/freebsd-vm but this route gonna be start from scratch.

Additional ref

• https://github.com/wezm/freebsd-cross-build

[n-connect]

@martadinata666

Thanks for the details, checked the smartmontools and the Wezm repo too. Unfortunately ran into several linked problems while tried to build one. In this direction this seems to most up-to-date Docker x86_64-unknown-freebsd by mcandre.

Honestly pervious projects I tried to get a FreeBSD build, were constucted different from Github actions point of view, editing only the YAML files of github action to add target x86_64-unknown-freebsd was simply enough.

Here I had to go under the hood, so there are three ways:

1. Use cross, just tested successfully. Caveats: cross wants to spin up another docker -> ghcr.io/cross-rs/x86_64-unknown-freebsd . To be able to do, one needs to enable the Docker-in-Docker. It needs from host to run with the docker socket passed into the building Docker (lldap_dev?), also docker need to be installed, and cross installed by passing and ENV that Docker-in-Docker will happen

2. Building freebsd-clang. Finally I've had the same linker error messages as before

3. Building freebsd-cc. Haven't tried yet, seemed the most complex for me.

[martadinata666]

When freebsd-cc will complicate stuff as it needs to rebuild many things just to achieve the x86_64 platform, thankfully musl had cross cc available.

I also want to suggest using cross action, but instead doing inside this main yml. Do it separately and use workflow call to build freebsd on this main yml.

name: build freebsd

on:
  workflow_call:

env:
  CARGO_TERM_COLOR: always

jobs:
  build-bin:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        target: [x86_64-unknown-freebsd]

    steps:
      - uses: actions/checkout@v3
      - uses: actions/cache@v3
        with:
          key: lldap-bin-${{ matrix.target }}-${{ hashFiles('**/Cargo.lock') }}
          restore-keys: |
            lldap-bin-${{ matrix.target }}-
      - name: Install podman
        run: |
             sudo apt update
             sudo apt install -y podman
      - name: Use cross?
        run: cargo install cross --git https://github.com/cross-rs/cross
      - name: Build with cross
        run: /home/runner/.cargo/bin/cross build --release --target x86_64-unknown-freebsd -p lldap -p lldap_migration_tool -p lldap_set_password
      - name: check path
        run: ls -alr target/release

      - name: upload ${{ matrix.target}} lldap artifacts
        uses: actions/upload-artifact@v3
        with:
          name: ${{ matrix.target}}-lldap-bin
          path: target/${{ matrix.target }}/release/lldap

      - name: upload ${{ matrix.target }} migration tool artifacts
        uses: actions/upload-artifact@v3
        with:
          name: ${{ matrix.target }}-migration-tool-bin
          path: target/${{ matrix.target }}/release/lldap_migration_tool

      - name: upload ${{ matrix.target }}-set-password-bin
        uses: actions/upload-artifact@v3
        with:
          name: ${{ matrix.target }}-lldap-set-password-bin
          path: target/${{ matrix.target }}/release/lldap_set_password

[n-connect]

@nitnelave

I have successful complete builds for FreeBSD by downloading/updating the actual Dockerfile.dev:

• installing docker.io
• adding rust x86_64-unknown-freebsd
• setting environment variable about Docker-in-Docker
• install cross and wasm-pack via cargo
• build the Docker, run the Docker and build app via cross (+ app/build.sh)
• pieces tar.gz'd out from docker: the lldap binaries, and the app/build.sh results. Uploaded here. The bootstrap and font files arer missing, I beleive those are put together with actions/upload-artifact@v4 (fixme)

Help me out: how can I find what actions/upload-artifact@v4 do, or how the additional fonts and bootstrap files get into under app/static & app/pkg for a release?

The modified Dockerfile.dev is in another temporary repo, to not contaminate this PR

Right now it is out of the way of current static build, but can be integrated:

• leave out changes from Dockerfile.dev, which are in docker-build-static.yml already
• modify docker-build-static.yml to have DinD instructed cross installed
• add line to cross build x86_64-unkown-freebsd
• BUT this docker (job: build-bin) need to be run via docker run -v /var/run/docker.sock:/var/run/docker.sock ... FAQ - cross-rs/cross Wiki

Finally: is this important, or is it this LICENCE file it is talking about?
[INFO]: Installing wasm-bindgen... [INFO]: Optimizing wasm binaries with wasm-opt... [INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory [INFO]: :-) Done in 1m 45s [INFO]: :-) Your wasm pkg is ready to publish at /tmp/lldap/app/pkg.

[n-connect]

@martadinata666

Yeah, had similar idea, but were thinking about extending the original static-build YAML, just see the above. What I didn't catch yet really, how the existing static build dockers called in life and by what. If there's no issue with running them via mapping /var/run/docker.sock into them to do DinD, that seems to be the simplest extension for this.

However if you do have some more details on the freebsd-cc way to share with, I'm interested in that too, it could help the BSD/SunOS/IllumOS area further.

When freebsd-cc will complicate stuff as it needs to rebuild many things just to achieve the x86_64 platform, thankfully musl had cross cc available.

I also want to suggest using cross action, but instead doing inside this main yml. Do it separately and use workflow call to build freebsd on this main yml.

[codecov]

Codecov Report

Merging #856 (ac58173) into main (533d1bc) will increase coverage by 0.03%.
Report is 5 commits behind head on main.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #856      +/-   ##
==========================================
+ Coverage   86.28%   86.32%   +0.03%     
==========================================
  Files          50       50              
  Lines       10925    10956      +31     
==========================================
+ Hits         9427     9458      +31     
  Misses       1498     1498              

[martadinata666]

Kindly check the run result https://github.com/lldap/lldap/actions/runs/8360008854

[martadinata666]

PR closed due weird issue, freebsd rc.d taken as binary rather than text.