Linking Error

[ju6ge]

Hey I have been trying to build the code myself, because I am interested in playing around and maybe creating an application for the remarkable. I have installed both SDKs ("codex", "oecore"). But no matter which one i set in the cargo config the build of the examples fails with a linker error. Not really sure what to make of it. Any ideas what I am missing?

/home/judge/GitHub/remarkable/toolchains/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/7.3.0/real-ld: cannot find Scrt1.o: No such file or directory
          /home/judge/GitHub/remarkable/toolchains/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/7.3.0/real-ld: cannot find crti.o: No such file or directory
          /home/judge/GitHub/remarkable/toolchains/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/7.3.0/real-ld: cannot find crtbeginS.o: No such file or directory
          collect2: error: ld returned 1 exit status

[LinusCDE]

I have not seen this particular linking error before.

Some ideas:

• Ensure the environment-setup-cortexa9hf-neon-oe-linux-gnueabi file in your toolchain location is sourced
• Disable the appctx feature (since it links lua stuff it's the most likely to cause of linker problems if cross-compilation is not set up properly). Try to use libremarkable = { version = "0.6.0", default-features = false, features = [ "framebuffer" ] )
• Investigate more by adding -vv for more debugging info
• Try to use cross

[ju6ge]

So I made sure to start from a clean environment and source the correct environment file. But the linker error persists. The files are definitely there. They are located under
<sysroot>/usr/lib. Just the linker refuses to find them. I tried setting an linker option for the sysroot as well, which did not help …

Disabling appctx is not an option since for the start I am just trying to build the demo app. I will need to investigate further and maybe also try to use a different machine. But anyway I have some more pressing things on my plate right now 🙈.

[LinusCDE]

Just to narrow down the problem, it would be helpful to disable appctx nonetheless.

Let me know when you investigate further on this.

[bkirwi]

Just to check - you mention installing "both" toolchains and sourcing the "correct" environment file... which makes me a bit suspicious, since the toolchain I have installed came as a single download with a single environment file. Is that the case for you as well?

In any case, sharing more details about your environment -- which version of the toolchain you have, where you installed it from, your OS, a paste of your cargo config, a set of commands that will reproduce this issue in a fresh shell -- would be really helpful as we chase this down!

[ju6ge]

If you take a look at the remarkable wiki They provide multiple toolchains. The more modern version is called "codex" and the legacy version "oecore". I installed them both in seperate directory trees. Originally I tried it with codex and when that did not work i noticed that the README on this wiki references "oecore". But both show this behavior. I am basically just following the README guide for setting up the toolchain within the ".cargo/config" file. Then i source the environment file for the toolchain I want to use. Afterwards I am using cargo build --release --target=armv7-unknown-linux-gnueabihf --example demo to try and build the demo binary.

Otherwise I am running on arch linux, with rust installed via rustup. And rust version 1.60. I am using zsh as shell, but I also tried using bash, because that has bitten me once already.

[bkirwi]

If you take a look at the remarkable wiki They provide multiple toolchains. The more modern version is called "codex" and the legacy version "oecore". I installed them both in seperate directory trees. Originally I tried it with codex and when that did not work i noticed that the README on this wiki references "oecore". But both show this behavior.

Great. FWIW, I'm not aware of any incompatibilities between toolchains as far as libremarkable is concerned. I personally use 3.1.2.

We should probably stop referencing oecore in the README, since like you say that string isn't normally used to refer to the newer toolchains.

I am basically just following the README guide for setting up the toolchain within the ".cargo/config" file.

FWIW, that file configures linking, so it's a very likely place for the error to be. Note that slightly different paths may be appropriate depending on the toolchain version you're using. Here's mine, again for 3.1.2:

[target.armv7-unknown-linux-gnueabihf]
linker = "/home/bkirwi/opt/rm11x/3.1.2/sysroots/x86_64-codexsdk-linux/usr/bin/arm-remarkable-linux-gnueabi/arm-remarkable-linux-gnueabi-gcc"
rustflags = [
  "-C", "link-arg=-march=armv7-a",
  "-C", "link-arg=-marm",
  "-C", "link-arg=-mfpu=neon",
  "-C", "link-arg=-mfloat-abi=hard",
  "-C", "link-arg=-mcpu=cortex-a9",
  "-C", "link-arg=--sysroot=/home/bkirwi/opt/rm11x/3.1.2/sysroots/cortexa7hf-neon-remarkable-linux-gnueabi",
]

That final line in particular is important; you'll definitely get linking errors like the one you pasted initially if it's not correct.

Then i source the environment file for the toolchain I want to use. Afterwards I am using cargo build --release --target=armv7-unknown-linux-gnueabihf --example demo to try and build the demo binary.

Otherwise I am running on arch linux, with rust installed via rustup. And rust version 1.60. I am using zsh as shell, but I also tried using bash, because that has bitten me once already.

Thanks. That sounds fairly typical.

It's hard to say exactly what's going wrong without knowing the contents of your cargo config or exactly which versions you're using, but hopefully the above is enough to get things working with 3.1.2 at least.

If that does turn out to unstick you, we should probably update the readme with known-good revisions (and a warning that paths may change as the toolchain does) to avoid future suffering.

[ju6ge]

Yes, not referencing the legacy toolchain and warning about the paths, would be a good idea. I am on version 3.1.15.

So I just double checked the paths again and had to face palm myself. The error originated in a wrong number within the cortexaX part. In the old toolchain if was cortexa9 and in codex it is cortexa7. This fixes the problem of course. My monkey brain just refused to see it, even though I thought to have checked it. I probably mixed them up when testing both toolchains. Sorry for trouble. Anyway since there is an envrionment variable for this it would be nice to use that directly. TDIL .cargo/config does not support environment variables 🙄. So apart from warning people about this there is not much that can be done sadly. The environment variables also do not provide the path to the actual compiler, so it also not possible to create a template that would generate the correct .cargo/config once the environment file was sourced. 🙈

[ju6ge]

Actually just as a note, I just tested without sourcing the environment file. Which works fine! So that is basically unnecessary, only the correct .cargo/config file is required, to be able to build the code. Bummer it would have been much nicer for purposes of testing against different version if the environment files could be used.

[ju6ge]

Well my earlier assessment that it would not be possible to generate the .cargo/config from the environment turned out to be false. I just got the hacking fever and solved that particular problem once and for all. Enjoy with #102 😉

[LinusCDE]

Cool to see. I was also suspicious of some typo or missing env file. Numerous similar occasions have taught me to first search for typos if somethings seems weird.

We should probably stop referencing oecore in the README, since like you say that string isn't normally used to refer to the newer toolchains.

I'm somewhat hesitant to do this. In general I'm all for updating the toolchain. In fact I think I was involved in migrating it to oecore if memory serves right and also updated the wiki page you referenced when oecore and the toltec toolchain came along and official download links on https://remarkable.engineering/ went away.

My current worry is, that the codex toolchain might confuse people into building two different binaries (rm10x and rm11x) which in most cases is not really needed. I'm still using oecore and would also happlily use poky. Oecore still works flawless as long as you don't need libs such as qt stuff which you in rust generally don't use anyway.

---

I only glanced at the PR and will take a closer look at it tomorrow. Just fyi, I can point out that there actually also is a way to specify most content of it in envs. I think CC_armv7_unknown_linux_gnueabihf and CARGO_TARGET_ARMV7_UNKNOWN_LINUX_GNUEABIHF_LINKER are the relevant ones here and both specify the ..-gcc binary.

This approach could lead to some nice toolchain-env.sh (and maybe a .bat version) to optionally source before building. Reason is, that I already have the little annoyance with having to include the file referencing the standard path of oecore in my projects (example). Since this is basically a hardcoded assumption, that needs to be removed when packaged for toltec (here).

So a sourced file might be a more flexible solution that would also offer the possibility of using codex-rm10x and codex-rm11x if you want as well as ensuring a user-wide config ($HOME/.cargo/config as used in toltec here) can just work without being overriden by a specific on on the project level.

For now I'm happy with an improvement to the existing solution though. Just noting that this specification isn't ideal, but was a thing I also didn't care to solve in the past years as well.

[LinusCDE]

Took a slightly closer look. Combined with .gitignoring and then generating the file, that seems like a great solution I didn't consider! I assumed you would generate one and then still have it in the repo. Your way it really nice though and I would like to merge that tomorrow or when finished.

[ju6ge]

Thanks 😊. The script can totally also be updated in the future to not write a file and instead be used generate the correct cargo environment variables 🤔. Though that would require digging quite deep into the cargo documentation. This is good enough for now.

[bkirwi]

I'm somewhat hesitant to do this. In general I'm all for updating the toolchain. In fact I think I was involved in migrating it to oecore if memory serves right and also updated the wiki page you referenced when oecore and the toltec toolchain came along and official download links on https://remarkable.engineering/ went away.

TBC, I think the problem is that the instructions "assume" a specific toolchain version but don't say which one. Specifying it would solve that, or making the instructions more generic. I don't have strong feelings about what the "right" version is, though I do have a slight bias towards more recent versions for the usual reasons.

But also a generation script sounds fine too!