build: Add missing shared library linker flags

[Dim-P]

Issue: I noticed that when building the shared library on FreeBSD, it fails to be loaded by any programs attempting to use it via dlopen().

Solution: This PR fixes that by adding the necessary linker flags, to link the shared library to util. It probably fixes the same issue on armv7l, but I have not tested that scenario.

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

[N/A] Example configuration file for the change
[N/A] Debug log output from testing the change

[N/A] Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

[N/A] Run local packaging test showing all targets (including any new ones) build.

• Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

[N/A] Documentation required for this feature

Backporting

• Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[patrick-stephens]

Please fill out the PR template appropriately.
What issue is this resolving? For what target, etc.? Does it compile for every supported target with your change (see the helper scripts)?

[Dim-P]

Please fill out the PR template appropriately. What issue is this resolving? For what target, etc.? Does it compile for every supported target with your change (see the helper scripts)?

Are there any instructions on how to setup an environment to run local packaging test?

[patrick-stephens]

Please fill out the PR template appropriately. What issue is this resolving? For what target, etc.? Does it compile for every supported target with your change (see the helper scripts)?

Are there any instructions on how to setup an environment to run local packaging test?

It repeats the packaging/build.sh script but for each target so needs a container runtime and potentially QEMU set up: https://github.com/fluent/fluent-bit/tree/master/packaging#usage
QEMU set up may be different per OS but I did try to capture the details at the time in the script for Ubuntu 20.04:

fluent-bit/packaging/local-build-all.sh

Lines 5 to 14 in 281aea0

	# Simple script to test a build of all supported targets.
	# To build multi-arch, QEMU can be used and ideally buildkit support in Docker.
	#
	# Follow the relevant instructions to do this for your OS, e.g. for Ubuntu it may be:
	# $ sudo apt-get install qemu binfmt-support qemu-user-static # Install the qemu packages
	# $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
	# Confirm you can run a non-native architecture image, e.g.:
	# $ docker run --rm -t arm64v8/ubuntu uname -m # Run an executable made for aarch64 on x86_64
	# WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
	# aarch64

The container build also covers it: https://github.com/fluent/fluent-bit/tree/master/dockerfiles#multiple-architecture-support

[Dim-P]

Please fill out the PR template appropriately. What issue is this resolving? For what target, etc.? Does it compile for every supported target with your change (see the helper scripts)?

Are there any instructions on how to setup an environment to run local packaging test?

It repeats the packaging/build.sh script but for each target so needs a container runtime and potentially QEMU set up: https://github.com/fluent/fluent-bit/tree/master/packaging#usage QEMU set up may be different per OS but I did try to capture the details at the time in the script for Ubuntu 20.04:

fluent-bit/packaging/local-build-all.sh

Lines 5 to 14 in 281aea0

	# Simple script to test a build of all supported targets.
	# To build multi-arch, QEMU can be used and ideally buildkit support in Docker.
	#
	# Follow the relevant instructions to do this for your OS, e.g. for Ubuntu it may be:
	# $ sudo apt-get install qemu binfmt-support qemu-user-static # Install the qemu packages
	# $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
	# Confirm you can run a non-native architecture image, e.g.:
	# $ docker run --rm -t arm64v8/ubuntu uname -m # Run an executable made for aarch64 on x86_64
	# WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
	# aarch64

The container build also covers it: https://github.com/fluent/fluent-bit/tree/master/dockerfiles#multiple-architecture-support

Is that required for the PR to be approved, given that the CI passes?

[patrick-stephens]

Is that required for the PR to be approved, given that the CI passes?

No, we just prefer it to be working prior to spending the compute resources to build it all and verify.

[Dim-P]

Is that required for the PR to be approved, given that the CI passes?

No, we just prefer it to be working prior to spending the compute resources to build it all and verify.

Anything else required to get this approve?

I believe the failing CI test is irrelevant to this PR.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.