Build breaks on arm64, armv7, i386: undefined reference to `resvg_parse_tree_from_data'

[yurivict]

The FreeBSD package fails to build on these architectures, but it builds fine on amd64.

sample log

The build uses the resvg-c-api-0.44.0_1 package that provides libresvg.a and libresvg.so I verified that libresvg.a from the i386 package resvg-c-api-0.44.0_1 does contain resvg_parse_tree_from_data and other resvg_xx functions. But for some reason usql fails to use them.

Version: 0.19.12

[kenshaw]

@yurivict thanks for bringing this to my attention. There is a very large change coming to usql that will provide terminal graphic based chart rendering. At the moment, there is no pure Go rendering available for SVGs, at least not at a caliber good enough to handle the SVGs that are generated by the chart dependencies, as such I have created a wrapper around the very minimal Rust resvg library, which is: github.com/xo/resvg.

As such, the issue here is that there are no build artifacts for that platform and architecture:

$ cat resvg.go
// Package resvg is a wrapper around rust's [resvg] c-api crate.
//
// [resvg]: https://github.com/RazrFalcon/resvg
package resvg

/*
#cgo CFLAGS: -I${SRCDIR}/libresvg
#cgo darwin,amd64 LDFLAGS: -L${SRCDIR}/libresvg/darwin_amd64 -lresvg -lm
#cgo darwin,arm64 LDFLAGS: -L${SRCDIR}/libresvg/darwin_arm64 -lresvg -lm
#cgo linux,amd64 LDFLAGS: -L${SRCDIR}/libresvg/linux_amd64 -lresvg -lm
#cgo linux,arm64 LDFLAGS: -L${SRCDIR}/libresvg/linux_arm64 -lresvg -lm
#cgo linux,arm LDFLAGS: -L${SRCDIR}/libresvg/linux_arm -lresvg -lm
#cgo windows,amd64 LDFLAGS: -L${SRCDIR}/libresvg/windows_amd64 -lresvg -lm -lkernel32 -ladvapi32 -lbcrypt -lntdll -luserenv -lws2_32
...

As you can see, FreeBSD/NetBSD/etc. binaries are not available.

I had tried to build the artifacts for FreeBSD, but was not able to properly do so for FreeBSD, NetBSD, Solaris, and the other *Nix's. If you'd like to give a shot at fixing the build scripts in github.com/xo/resvg to generate the necessary binaries for FreeBSD, I'd be glad to incorporate it into the github.com/xo/resvg package.

Alternately, a pure Go SVG renderer would be equally welcome (this is said tongue-in-cheek, and meant to be a joke -- I don't really expect there to ever be a pure Go SVG renderer any time in the next decade).

[kenshaw]

One other thing that I am likely to do before the full release of the chart rendering feature: is to add a build tag to completely disable charts/terminal graphics.

However, I don't have an immediate ETA on when I'll be able to add that, but I'll make it a priority and try to get a point release out for usql ASAP.

[yurivict]

libresvg is sourced from https://github.com/RazrFalcon/resvg, not from github.com/xo/resvg. I am not sure what's the difference.

If, as you are saying, FreeBSD is simply not supported, how does the amd64 package build then? Also, why are these symbols present in libresvg.a for i386? Something isn't right with this explanation.

[kenshaw]

I assure you, as the primary author of usql and the Go resvg package, that what I shared above is how it works. As a Go application, 'usql' is not able to natively use Rust code without a bridge. That bridge, specifically, is the github.com/xo/resvg package. Within that package there is a C binding to Rust's resvg c-crate, which via CGO (and ala the #cgo stanzas I copied/pasted above) is how Go (or rather CGO) links to Rust's c-crate.

I'm neither a Go expert, nor a FreeBSD expert, as such I have no idea how it's compiling for you. Maybe there's some kind of FreeBSD ELF compatibility that allows it to work with ELF built binaries. All I have is wild speculation on how it might be working.

If you would like to track down what Go is using to compile/link against, I would suggest cloning the github.com/xo/resvg source tree and trying to run the github.com/xo/resvg unit tests directly on FreeBSD. If you do it with go test -v -x, Go will show you the exact compilation commands that are being used, which might shed some light as to what's going on.

I spin up a FreeBSD VM and figure out how you're able to get it to compile, but I'm not sure I'll be able to do that any time soon.

[yurivict]

The FreeBSD port resvg-capi builds from a different repository: https://github.com/linebender/resvg It might be a fork.

[kenshaw]

I'm not the FreeBSD port maintainer for usql, so I don't know what's going on here. I will make a point of looking into getting it to work out of the box with FreeBSD, but there's no realistic ETA I could give you on that.

[yurivict]

I am the FreeBSD port maintainer. -) That's why I am here.

I will make a point of looking into getting it to work out of the box with FreeBSD [...]

Thank you.