Add libcurl, openssl and libbreakpad to the base image

[Eeems]

See https://github.com/Eeems/oxide/runs/4736055110 It's provided in the reMarkable toolchain.

[matteodelabre]

I’ll take a look this evening.

[Eeems]

I’ll take a look this evening.

Thanks! It's likely some missed files, or an environment variable that we haven't populated.

[Eeems]

Some more information on what I'm building: https://docs.sentry.io/platforms/native/guides/qt/

[matteodelabre]

Can you try adding -DCMAKE_TOOLCHAIN_FILE="/usr/share/cmake/$CHOST.cmake" to your CMake command-line? See this package for example: https://github.com/toltec-dev/toltec/blob/46b33fd84637fb7e86ba741b92ebd7e5e965277e/package/yaft/package#L23

[Eeems]

Sure, although that will break building with the normal toolchain. Ideally, the toolchain should just work for cmake. I'll report back when it's done.

[Eeems]

That gets us further now. I'll sort out how to handle building in both toolchains in my package recipie.

Next up is that the toolchain is missing curl: https://github.com/Eeems-Org/oxide/runs/4746173317

[matteodelabre]

the toolchain should just work for cmake

That’s a good point. I see that in recent versions (⩾3.21), CMake reads the CMAKE_TOOLCHAIN_FILE variable from environment variables. We can add this to the image.

[matteodelabre]

Since this requires upgrading CMake, I’m rebuilding the base image to use the latest Debian release. This will take a few hours, so I’ll work on adding libcurl tomorrow.

[Eeems]

Since this requires upgrading CMake, I’m rebuilding the base image to use the latest Debian release. This will take a few hours, so I’ll work on adding libcurl tomorrow.

Thank you!

[matteodelabre]

Regarding setting a default value in the environment for CMAKE_TOOLCHAIN_FILE, I’m actually not convinced it’s the best solution. Consider projects that need to build some executables with the “normal” gcc compiler, and then use the resulting executables in the cross build [1]. Setting a default for CMAKE_TOOLCHAIN_FILE in this case will break the part that needs the normal gcc. We would need to unset the env var before running cmake to build the first part, and then setting the env var back before building the second part. This is also the reason why I haven’t overridden the CC and CXX env vars in the image: some parts of the build may want the normal gcc, and some other parts the cross gcc. I think it’s best that each part explicitly declares which compiler it wants, for example by passing the CMAKE_TOOLCHAIN_FILE argument for CMake projects, or setting the CXX variable, etc.

As you’ve mentioned, having such a behavior differ from the oecore toolchain means both toolchains need to be handled differently. This may not be desirable. But the oecore behavior is really not ideal for projects having a dual-compiler layout.

[1] I have encountered such cases before. This can be used for example to generate some code that is used for the second half of the build.

[matteodelabre]

As a compromise, we may add some emulate-oecore script that can be sourced to behave like oecore for projects that want it.

[Eeems]

Regarding setting a default value in the environment for CMAKE_TOOLCHAIN_FILE, I’m actually not convinced it’s the best solution. Consider projects that need to build some executables with the “normal” gcc compiler, and then use the resulting executables in the cross build [1]. Setting a default for CMAKE_TOOLCHAIN_FILE in this case will break the part that needs the normal gcc. We would need to unset the env var before running cmake to build the first part, and then setting the env var back before building the second part. This is also the reason why I haven’t overridden the CC and CXX env vars in the image: some parts of the build may want the normal gcc, and some other parts the cross gcc. I think it’s best that each part explicitly declares which compiler it wants, for example by passing the CMAKE_TOOLCHAIN_FILE argument for CMake projects, or setting the CXX variable, etc.

As you’ve mentioned, having such a behavior differ from the oecore toolchain means both toolchains need to be handled differently. This may not be desirable. But the oecore behavior is really not ideal for projects having a dual-compiler layout.

[1] I have encountered such cases before. This can be used for example to generate some code that is used for the second half of the build.

As a compromise, we may add some emulate-oecore script that can be sourced to behave like oecore for projects that want it.

Fair enough. Even if we don't go with the script, we should properly document this to lower the barrier to entry for people wanting to package things with our toolchain.

[matteodelabre]

Definitely. Referencing #12 as a reminder.

[matteodelabre]

Unfortunately the latest GCC 11 release breaks the build of glibc 2.31 in several ways, including a build-time segfault that I didn’t manage to resolve yet. This may take more time than initially planned.

[Eeems]

@matteodelabre have you had a chance to look at this again?

[matteodelabre]

Not yet. It’s still on my list but I have limited time available currently.

[matteodelabre]

Finally managed to make the build work again on the latest Debian… by pinning GCC to version 10. This should allow moving forward for now. Ideally reMarkable would update their glibc to the latest version soon so that we can move to more recent versions of GCC.

[Eeems]

Is there a new image tag I can use?

[matteodelabre]

Should be available on latest once the CI completes. Note that this image should be equivalent to the previous ones (if nothing broke). It’s essentially an update. I’ll then work upon this to implement the things we discussed in this thread.

[matteodelabre]

Just added libcurl and OpenSSL to latest. Could you give it a try @Eeems?

[Eeems]

@matteodelabre https://github.com/Eeems-Org/oxide/runs/5324827668

[ DEBUG] toltec.builder: oxide [rmall]: /opt/x-tools/arm-remarkable-linux-gnueabihf/lib/gcc/arm-remarkable-linux-gnueabihf/10.3.0/../../../../arm-remarkable-linux-gnueabihf/bin/ld.bfd: cannot find -lbreakpad_client

Which is odd since it should be building it as part of the compile.

[matteodelabre]

Looks like the libbreakpad_client.a and libbreakpad.a static libraries are present in the OECore toolchain (no dynamic library counterpart is available on the rM system).

[Eeems]

That might be why. I guess I'll have to add building it into the steps

[matteodelabre]

Since it’s available on the rM toolchain I could also add it to ours.

[matteodelabre]

Just published another latest update that includes breakpad and breakpad-client @Eeems

[Eeems]

@matteodelabre Running it again

[Eeems]

Looks like that did it! @matteodelabre

[matteodelabre]

Excellent! I’ll prepare a new release then.

[matteodelabre]

Now available under the 2.3 tag.

[matteodelabre]

Closing this, will track adding docs for using CMake in #12.