Docker builds are not working

[thirtythreeforty]

Looks like something changed upstream and recent Docker builds are not working:

error: linking with `cc` failed: exit code: 1
  |
  = note: /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../lib/libgstrtspserver-1.0.so: undefined reference to `gst_rtsp_connection_set_content_length_limit'

[QuantumEntangledAndy]

The function gst_rtsp_connection_set_content_length_limit is here

#[cfg(any(feature = "v1_18", feature = "dox"))]
    pub fn gst_rtsp_connection_set_content_length_limit(
        conn: *mut GstRTSPConnection,
        limit: c_uint,
    );

and it is supposed to be behind the "v1_18" feature. I think we need to pin the feature set to the minimum required for neolink.

gstreamer = { version = "0.16", features = ["v1_14"]}
gstreamer-app = { version = "0.16", features = ["v1_14"]}
gstreamer-rtsp = { version = "0.16", features = ["v1_14"]}
gstreamer-rtsp-server = { version = "0.16", features = ["v1_14"]}

I am running a build with this now to test

[QuantumEntangledAndy]

So explicit versions didn't help will need to investigate more. Perhaps there's some regression where it gets pulled in as a dependency even when it's behind the feature flag.

[QuantumEntangledAndy]

The version of gstreamer that alpine is pulling is

gst-rtsp-server-dev (1.18.2-r0)

So it should have it anyways. Perhaps we should pin it to the 1.16. Now I need to learn how to pin in alpine....

[QuantumEntangledAndy]

We use alpine rust which means when the rust docker updates the alpine version it will also update here. Perhaps we should use a specific alpine version and add the rust tools ourselves. (I think our more docker images PRs both do this)

[QuantumEntangledAndy]

Ok so this may be to do with the alpine package manager issues:

The package manager pulls this version for gstreamer
gstreamer-dev (1.16.2-r2)

and this for rtsp-server

gst-rtsp-server-dev (1.18.2-r0)

They are from different version sets and rtsp-server cannot link to the older one... sigh....

So I went looking into the http://dl-cdn.alpinelinux.org/alpine/edge/testing repo and found that they don't keep the 1.16 version anymore. Tried looking into main instead of testing and found that main dosent have rtsp server at all... This will likely "fix" itself once alpine package maintaners bump up the gstreamer to 1.18 too, but in the meantime not sure what to do

[QuantumEntangledAndy]

More oddness the repo at http://dl-cdn.alpinelinux.org/alpine/edge/ suggests that gstreamer-dev is already at 1.18 but we are pulling 1.16. Maybe there is some caching going on inbetween github and alpine dl servers... Will keep testing

[QuantumEntangledAndy]

Ok so maybe sorted it out, we are getting rtsp-sever from edge (alpine 3.13, fyi rtsp is only in edge because it is "testing") but the alpine from rust docker.io is 3.12 so when it pulls in gstremer it gets it from there the 3.12 repo which is 1.16. We can't fix alpine to 3.12 as rtsp is not in it anymore (all testing stuff is only kept in latest version 3.13)

[QuantumEntangledAndy]

I think the solution is to use the alpine docker for the base rather than the rust. This can be achieved by merging #84.

[QuantumEntangledAndy]

Ok even better (sarcasm)... The official docker for alpine is still on 3.12 so we cannot fix this at the moment until upstream alpine dockers go to 3.13... ToT

[QuantumEntangledAndy]

Ok so success of a kind. I can force the 3.12 alpine to use the packages of the 3.13 alpine (just for the gstreamer stuff) and that works

@thirtythreeforty would you like me to work up a PR for this with the more armhf docker images in too?

[thirtythreeforty]

And that's the story of why folks use Debian, kids.

In all seriousness, I follow what you're saying. I'm concerned that installing 3.13 packages on 3.12 might break... things. Certainly, at least in the short term, getting it running with your proposed change would be good, so PRs welcome.

Longer term... mmh. Until Alpine has all this stuff in stable releases, I'd be in favor of moving the Docker image back to Debian for the stability. What do you think?

I'm also confused why the Gstreamer Rust crate won't build against various versions of the library. Do they not make that guarantee? You're my Gstreamer wrangler 😉

[QuantumEntangledAndy]

I don't mind either approach debian or alpine edge. The code for fixing is just this

RUN apk add --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/main \
    -X http://dl-cdn.alpinelinux.org/alpine/edge/testing \
  gst-rtsp-server-dev

Which doesn't reference 3.13 explicitly just says pull from edge testing and edge main this gstreamer package and its dependencies. So once the docker gets updated to 3.13 it will work without any more changes and will still work for the 3.13->3.14 cross over when ever that happens. Just maybe odd issues during the transition.

Debian build is quite a bit bigger and not because of the size of the base but because it pulls in gstreamer packages we don't use like the python related stuff by default which means a whole python is in there too bumping up the size. So I can see the appeal of alpine.

The rust part is building fine with its feature gates its the c part that is an issue. The gst-rtsp c code for 1.18 uses a new shiny function that is in the 1.18 gst-core but not in the 1.16 gst-core. So fails to link at this point.

[thirtythreeforty]

The rust part is building fine with its feature gates its the c part that is an issue. The gst-rtsp c code for 1.18 uses a new shiny function that is in the 1.18 gst-core but not in the 1.16 gst-core. So fails to link at this point.

Got it, makes sense. So, linking gst-rtsp 1.18 against 1.16 core fails. Which makes sense. Thanks for the troubleshooting.

I agree what you suggest will likely be fine and I'm cool with merging it. What I was saying is that this same scenario is in principle possible with other packages that are built in edge and then suddenly fail to link against an older version of, say, libc. (Especially common in embedded land.)