Question about handling of memory layout

[SeleDreams]

Hi,
This issue is more about questions on how ctru-rs works.
I am working on a wrapper of libnds for the DS and I would like to be able to do something like ctru-rs that can simply be included as a dependency to build for ds with just the .json of the target.

The DS and 3DS both work with specs files that define .ld, .mem files that are included during the build process.
I tried to link them with println!("cargo:rustc-link-arg=-specs={}/sys/crts/ds_arm9.specs",&blocksds_path); for the DS but i found out that build.rs link args don't extend to parent crates, as such this wouldn't work when used as a dependency.

How does ctru-rs handle this type of things ? as from what I know it depends on devkitpro which does rely on specs files as well

[Meziu]

These are things that cannot be handled by a simple build script, since they override compilation on a compiler/linker level.

You can specify them as additional linker arguments when creating a target triple .json file or rustc-target configuration.

Here's where we specify these requirements.

Admittedly, this is the only direct reference of devkitPro specific configurations we make in that target triple, but we have also put the toolchain as a requirement in the target docs, so it's fine.

[SeleDreams]

I see
global path wise, is there a way to set it somewhere ? because if I just do -specs=ds_arm9.specs it won't find it unless I like copy the specs file in my project directory

[Meziu]

I see

global path wise, is there a way to set it somewhere ? because if I just do -specs=ds_arm9.specs it won't find it unless I like copy the specs file in my project directory

I find weird that your linker can't find the file, since it should be placed in a relative file directory to which it has direct access. Are you sure the linker running is the one by devkitPro?

Usually we had problems of not finding the linker (on the global path), but once found it was always able to find its files.

[SeleDreams]

I am using BlocksDS instead of devkitpro (a newer toolchain for the DS with improvements)
https://blocksds.github.io/docs/introduction/introduction/

[Meziu]

I am using BlocksDS instead of devkitpro (a newer toolchain for the DS with improvements)

https://blocksds.github.io/docs/introduction/introduction/

Ouch, this makes the situation a bit harder. Are you sure the file is properly included? I have no idea on how their compiler toolchain works.

[SeleDreams]

I was able to make it work by forking cargo-3ds, modifying it for ds specific stuff, and inserting the specs file with the correct path based on the BLOCKSDS environment variable.
So I now have a working cargo-nds to build ds homebrews. though at the moment, only arm9 homebrews are supported (which should be the majority of cases, but I still plan to support arm7 long term)

https://github.com/SeleDreams/cargo-nds

[SeleDreams]

Since I am in the same discord as the main BlocksDS developer, I'll talk to them about it. They might find a way to make things easier Le lun. 29 avr. 2024 à 13:05, Meziu ***@***.***> a écrit :

…

I am using BlocksDS instead of devkitpro (a newer toolchain for the DS with improvements) https://blocksds.github.io/docs/introduction/introduction/ Ouch, this makes the situation a bit harder. Are you sure the file is properly included? I have no idea on how their compiler toolchain works. — Reply to this email directly, view it on GitHub <#185 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4UF4K45VGXZYY3U3OIDFTY7YSQJAVCNFSM6AAAAABG5JTPASVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TENRRGQYTK> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[SeleDreams]

I figured out the best way to handle it with the limitations. I'm going to try, in the new cargo-nds I'll make to make it create a symlink to the specs file's directory before the build so that the linker can find it from the project's relative path. And then it would delete the symlink after the build. That seems like the best way to handle it Le lun. 29 avr. 2024 à 13:06, SeleDreams ***@***.***> a écrit :

…

Since I am in the same discord as the main BlocksDS developer, I'll talk to them about it. They might find a way to make things easier Le lun. 29 avr. 2024 à 13:05, Meziu ***@***.***> a écrit : > I am using BlocksDS instead of devkitpro (a newer toolchain for the DS > with improvements) > > https://blocksds.github.io/docs/introduction/introduction/ > > Ouch, this makes the situation a bit harder. Are you sure the file is > properly included? I have no idea on how their compiler toolchain works. > > — > Reply to this email directly, view it on GitHub > <#185 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AD4UF4K45VGXZYY3U3OIDFTY7YSQJAVCNFSM6AAAAABG5JTPASVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TENRRGQYTK> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >