Compiling Rust code on UT

Giiba

I'm looking into how to do it by installing gcc-multilib to ~/

A libertine container is just going to make everything more complex as I would need Rust, gcc-multilib, and a terminal emulater installed in the container... and then the osk doesn't always work so great in a container. I know the libertine way is the reccomended approach for many things, but Libertine isn't exactly a working solution to much of anything, more just a bunch of layers of complication.

Really I just need to figure out the 'cc linker' part as most of gcc-multilib is superfluous to Rust.

doniks

@Giiba said

and a terminal emulater installed in the container... and then the osk doesn't always work so great in a container

Why would you need a terminal emulator installed in the container

Giiba

Tis the only way I know how to issue command line commands...

dobey

@Giiba No, you can use the main terminal app instead if you're only using CLI tools in the container. See https://docs.ubports.com/en/latest/userguide/dailyuse/libertine.html#shell-access

mirroronthewall

@dobey So, some tools can be installed and contained in the container, but it can be accessed from the normal UT terminal app?

And, instead OP was trying to either directly install the tools to the terminal app (outside of a container), or install a terminal emulator inside a Libertine container and then use the tools within that (like a terminal within a terminal)?

arubislander

@mirroronthewall
Your understanding is correct

doniks

@dobey said in Compiling Rust code on UT:

@Giiba No, you can use the main terminal app instead if you're only using CLI tools in the container. See https://docs.ubports.com/en/latest/userguide/dailyuse/libertine.html#shell-access

Now that we talk about this, I'm thinking ... Why not append the bin folders from the libertine container to the PATH variable ... That would be even easier and more seemless to use the cli tools that are installed in the container than the shell access from the docs ... Any downsides/risks?

arubislander

That would only work for statically compiled executables. Or possibly also for executables that only depend on libraries that happen to be installed on the host system. It would not work for executables that make use of libraries that are installed in the container, but not available outside the container, or have different versions.

dobey

@doniks Things in the container need to be run from inside the container. Otherwise, they won't be contained.

Giiba

Very interesting, learn something all the time.

So if I understand correctly I could create an alias for the gcc component in a container and then rustc could call it to do the linking thing when compiling? Would this work on files located outside the container (ie. my home directory ~/)?

Having now updated a couple of times since first doing this I can confirm that action does wreck-up the gcc install and it needs to be reinstalled after updates. However Rust's installation in ~/.cargo persists between updates just fine.

Now I just have to determine what exactly rustc is calling... doing some digging (with almost no understanding) I figured the 'linker' in question is 'ld' that comes with 'binutils', only to discover that they are already installed on the UT system.

Anyone know why the installed files don't work or what it is I would need to create an alias for? I'm going to try asking in some Rust discussion areas.

Because at this moment I can hack on gcc-multilib to the system image via apt with 60MB of space used, or install hundreds of MB of container and still not know what I need to alias...

dobey

@Giiba I'm not sure what you mean by alias here.

Simply create a container, and install the needed dependencies from apt using libertine-container-manager install-package for example, and then with libertine-launch -i <container_name> bash to get a shell in the container, you can do the rust install in ~/.cargo. After that, it should be usable just the same as when you are running in the host, once you open a terminal and run libertine-launch -i <container_name> bash to get the shell inside the container.

I don't recall which folders are bind mounted by default inside the container, but I think ~/Documents/ is one, so if you put all your source files under ~/Documents/code/ for example, you should be able to cd to there inside the container to compile things, while being able to transfer via MTP from a PC if that's what you're looking for. Otherwise, it'd probably be better to just use git or such as an intermediate for source transfer between multiple locations.

Giiba

@dobey I was thinking of the alias feature of the container as detailed by the page you linked. But I understand how that is not necessary now.

I really am just playing with simple code, nothing requiring git or large transfers so as long as I can access a few small files in ~/Documents I am fine. I am just working through the book and it's examples which are all less than 50 lines of code.

I am continuing to be impressed with Seabass as it is a reasonable code editor neglecting the crazy backspace key behaviour (which is easy enough to avoid with the new selectiin features of the osk).

Giiba

I set up a Libertine container, and installed gcc-multilib and rust with in and as expected everything ran and compiled within my ~/Documents folder

Interestingly, within the container the build of the 'hello world' program takes 3x longer than with gcc-multilib hacked onto the system: