Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generating libcore for architecture #22

Closed
0xc0170 opened this issue Jan 23, 2016 · 2 comments
Closed

Generating libcore for architecture #22

0xc0170 opened this issue Jan 23, 2016 · 2 comments

Comments

@0xc0170
Copy link
Contributor

0xc0170 commented Jan 23, 2016

Makefile for libcore is currently broken if you build for more than one platform There are two platforms, let's just say one is cortex-m0 and cortex-m4 (different thumb versions). Triple does not match for core lib. The error output:

./tock/src/process/lib.rs:1:1: 1:1 error: couldn't find crate `core` with expected target triple ./tock/src/chips/nrf51822/target.json [E0461]
./tock/src/process/lib.rs:1 #![crate_name = "process"]
                                              ^
./tock/src/process/lib.rs:1:1: 1:1 note: crate `core`, path #1, triple ./tock/src/chips/sam4l/target.json: \\?\C:\Code\github\rust\tock\build\libcore.rlib
error: aborting due to previous error
make: *** [build/libprocess.rlib] Error 101

This is caused by copying libcore to build directory without appending any triple specific value. A quick fix would be to copy libcore to a platform specific build directory or just define libcore.rlib as phony target.

A better one might be to come up with a schema from target.json file. What shall we consider, arch, llvm-target?

@alevy
Copy link
Member

alevy commented Jan 25, 2016

This is actually not limited to libcore. Each rust crate is compiled for a specific target, so, in fact, all the drivers and common kernel components need to be recompiled as well. Simiarly, applications may need to be compiled with different GCC targets, so they too need to be recompiled.

Ideally the build directory could maximize artifact sharing by splitting have a separate build directory per chip and platform (so multiple platforms using the same chip could reuse a compiled libcore and lib-chipname.

But a separate build directory for each platform would be a good start.

@alevy
Copy link
Member

alevy commented Feb 5, 2016

Duplicate of #30

@alevy alevy closed this as completed Feb 5, 2016
alexandruradovici added a commit to OxidosAutomotive/tock that referenced this issue Jul 27, 2023
* kernel works

* OXID-48-Implement-deferred-tasks-for-uart (tock#15)

* deferred tasks for uart and io.rs panic added

* NOP added to arch/wasm

* NOP asm operation added for wasm

* Update arch/wasm/src/lib.rs

Co-authored-by: Alexandru Radovici <alexandru.radovici@wyliodrin.com>

* Update lib.rs

* cargo.toml deno-wasm optimization removed

---------

Co-authored-by: Alexandru Radovici <alexandru.radovici@wyliodrin.com>

* PROCESS_PRINTER fix

* nvic added

* alarm working

* Update lib.rs

* comments fixes

* alarm_test moved to examples directory

* deno function calls update

* updated the architecture and added multiple timers

* interrupts readme added to deno chip

* added deno formatter

* Update ci.yml

* cleanup

* classes comments added

* Update ci.yml

---------

Co-authored-by: Alexandru Radovici <alexandru.radovici@oxidos.io>
Co-authored-by: Alexandru Radovici <alexandru.radovici@wyliodrin.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants