Only static link gnutls

[timower]

This prevents a crash on firmware versions 3.6+.
The NSS functions in glibc don't play nice with static linking.

Resolves toltec-dev/toltec#731

[Eeems]

The one concern I have here, is that no longer static linking means that we could have other compatibility issues in the future that break this build of wget on some versions. Which is why we static linked in the first place.

[Eeems]

I have tested this and it does seem to work on 2.15.1 though, so I'd be willing to merge it and add a new tag though. Have you tested on a rM1/2 on 3.6+?

[timower]

The one concern I have here, is that no longer static linking means that we could have other compatibility issues in the future that break this build of wget on some versions. Which is why we static linked in the first place.

True, but we have compatibility issues right now with 3.6+, even though we're statically linking. If we want to keep it static, we need to move to a musl toolchain.

I have tested this and it does seem to work on 2.15.1 though, so I'd be willing to merge it and add a new tag though. Have you tested on a rM1/2 on 3.6+?

I've tested on 2.15, 3.5 and 3.6.

[Eeems]

I would be more comfortable moving this to musl than making it dynamic. I'll take a look later today at doing so.

[Eeems]

For the interim though, did you explore updating the image this is building with to the latest to see if that resolved this first?

[Eeems]

https://stackoverflow.com/a/57478728
For context around why static linking of glibc is an issue, which is what we ran into. glibc always dynamically loads when using NSS calls, do to it using dlopen in its code. Which can (and has) cause issues when the system has a different version of glibc installed than it was generated against.

Due to this, I'm more comfortable merging this in the current state, and moving just this to a musl based static build at a later date. We may still run into issues with new versions not being properly backwards compatible, as glibc has broken backwards compatibility in the past. These issues seem to be minor though, so I'm not as concerned for now.

[timower]

For the interim though, did you explore updating the image this is building with to the latest to see if that resolved this first?

I did not, but as glibc is definitely not forwards compatible, moving to 3.x would break older firmwares.

https://stackoverflow.com/a/57478728 For context around why static linking of glibc is an issue, which is what we ran into. glibc always dynamically loads when using NSS calls, do to it using dlopen in its code. Which can (and has) cause issues when the system has a different version of glibc installed than it was generated against.

Due to this, I'm more comfortable merging this in the current state, and moving just this to a musl based static build at a later date. We may still run into issues with new versions not being properly backwards compatible, as glibc has broken backwards compatibility in the past. These issues seem to be minor though, so I'm not as concerned for now.

Nice find, and yeah, we might run into other issues, but currently it's not working, so at least this should improve it.

[Eeems]

For the interim though, did you explore updating the image this is building with to the latest to see if that resolved this first?

I did not, but as glibc is definitely not forwards compatible, moving to 3.x would break older firmwares.

Static compile should avoid most of that, but as we've found, NSS calls are the exception here, so it will probably break things. Right now we don't support older than 2.6.1.71 due to the breaking Qt library changes that happened at that version. So we aren't as worried about dropping support for older than that, but perhaps we should still be.

We should also probably document the minimum version properly, right now you have to infer it from the toolchain readme as most things use the 2.x branch. This wget build is still using the 1.x branch, so it should still work on older and newer versions.

https://stackoverflow.com/a/57478728 For context around why static linking of glibc is an issue, which is what we ran into. glibc always dynamically loads when using NSS calls, do to it using dlopen in its code. Which can (and has) cause issues when the system has a different version of glibc installed than it was generated against.
Due to this, I'm more comfortable merging this in the current state, and moving just this to a musl based static build at a later date. We may still run into issues with new versions not being properly backwards compatible, as glibc has broken backwards compatibility in the past. These issues seem to be minor though, so I'm not as concerned for now.

Nice find, and yeah, we might run into other issues, but currently it's not working, so at least this should improve it.

Alright, I'm going to merge this, and sort out how to get it pushed out to the website etc, and then we'll need to update toltec-bootstrap to use it.