| Message ID | 20220710164300.953098-2-otavio@ossystems.com.br |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/2] rust-common: Fix use of target definitions for SDK generation | expand |
On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote: > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> > --- > > (no changes since v1) > > .../cargo/cargo-cross-canadian.inc | 20 ++++++++++++++++++- > 1 file changed, 19 insertions(+), 1 deletion(-) I did look into this with some local testing. With: SDKAMCHINE = "aarch64" MACHINE = "qemuarm64" bitbake rust-cross-canadian-aarch64 still fails so there is still something wrong with the SDK builds :/ Cheers, Richard
Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote: > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> > > --- > > > > (no changes since v1) > > > > .../cargo/cargo-cross-canadian.inc | 20 ++++++++++++++++++- > > 1 file changed, 19 insertions(+), 1 deletion(-) > > I did look into this with some local testing. With: > > SDKAMCHINE = "aarch64" > MACHINE = "qemuarm64" > > bitbake rust-cross-canadian-aarch64 > > still fails so there is still something wrong with the SDK builds :/ > I'll check this. I didn't check this combination.
On Mon, 2022-07-18 at 12:49 -0300, Otavio Salvador wrote: > > > Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie > <richard.purdie@linuxfoundation.org> escreveu: > > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote: > > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> > > > --- > > > > > > (no changes since v1) > > > > > > .../cargo/cargo-cross-canadian.inc | 20 > > > ++++++++++++++++++- > > > 1 file changed, 19 insertions(+), 1 deletion(-) > > > > I did look into this with some local testing. With: > > > > SDKAMCHINE = "aarch64" > > MACHINE = "qemuarm64" > > > > bitbake rust-cross-canadian-aarch64 > > > > still fails so there is still something wrong with the SDK builds > > :/ > > > > > I'll check this. I didn't check this combination. I tried an experiment to see which combinations worked. To do that I added: TOOLCHAIN_HOST_TASK:append = ' packagegroup-rust-cross-canadian-${MACHINE}' to the autobuilder config. This resulted in: qemux86: https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/5491 buildtools: https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5885 beaglebone: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5563 edgerouter: https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5533 genericx86: https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5548 genericx86-64: https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5533 multilib: https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5554 pkgman-deb-non-deb: https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5554 qemumips: https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5498 qemux86-64: https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5487 qemuarm64: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5510 qemuarm: https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5525 so there is something rather wrong :( Cheers, Richard
Hello Richard and Khem Em seg., 18 de jul. de 2022 às 12:59, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > On Mon, 2022-07-18 at 12:49 -0300, Otavio Salvador wrote: > > Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie > > <richard.purdie@linuxfoundation.org> escreveu: > > > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote: > > > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> > > > SDKAMCHINE = "aarch64" > > > MACHINE = "qemuarm64" > > > > > > bitbake rust-cross-canadian-aarch64 > > > > > > still fails so there is still something wrong with the SDK builds > > > :/ > > > > > > > > > I'll check this. I didn't check this combination. > > I tried an experiment to see which combinations worked. To do that I > added: > > TOOLCHAIN_HOST_TASK:append = ' packagegroup-rust-cross-canadian-${MACHINE}' > > to the autobuilder config. This resulted in: > > qemux86: > https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/5491 > > buildtools: > https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5885 > > beaglebone: > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5563 > > edgerouter: > https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5533 > > genericx86: > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5548 > > genericx86-64: > https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5533 > > multilib: > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5554 > > pkgman-deb-non-deb: > https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5554 > > qemumips: > https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5498 > > qemux86-64: > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5487 > > qemuarm64: > https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5510 > > qemuarm: > https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5525 > > so there is something rather wrong :( > It does, indeed, but it doesn't seem related to this PR. Do you know if this has worked? I am asking as I did all development and testing using SDKMACHINE ?= 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However, looking at some of the logs above, it seems it is using an SDKMACHINE as i686, so this appears as a different issue for me.
On Mon, 2022-07-18 at 16:25 -0300, Otavio Salvador wrote: > Hello Richard and Khem > > Em seg., 18 de jul. de 2022 às 12:59, Richard Purdie > <richard.purdie@linuxfoundation.org> escreveu: > > On Mon, 2022-07-18 at 12:49 -0300, Otavio Salvador wrote: > > > Em seg., 18 de jul. de 2022 às 09:45, Richard Purdie > > > <richard.purdie@linuxfoundation.org> escreveu: > > > > On Sun, 2022-07-10 at 13:43 -0300, Otavio Salvador wrote: > > > > > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> > > > > SDKAMCHINE = "aarch64" > > > > MACHINE = "qemuarm64" > > > > > > > > bitbake rust-cross-canadian-aarch64 > > > > > > > > still fails so there is still something wrong with the SDK > > > > builds > > > > :/ > > > > > > > > > > > > > I'll check this. I didn't check this combination. > > > > I tried an experiment to see which combinations worked. To do that > > I > > added: > > > > TOOLCHAIN_HOST_TASK:append = ' packagegroup-rust-cross-canadian- > > ${MACHINE}' > > > > to the autobuilder config. This resulted in: > > > > qemux86: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/5491 > > > > buildtools: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5885 > > > > beaglebone: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5563 > > > > edgerouter: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5533 > > > > genericx86: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5548 > > > > genericx86-64: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5533 > > > > multilib: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5554 > > > > pkgman-deb-non-deb: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/5554 > > > > qemumips: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/5498 > > > > qemux86-64: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5487 > > > > qemuarm64: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/5510 > > > > qemuarm: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/5525 > > > > so there is something rather wrong :( > > > > > It does, indeed, but it doesn't seem related to this PR. > > Do you know if this has worked? > > I am asking as I did all development and testing using SDKMACHINE ?= > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However, > looking at some of the logs above, it seems it is using an SDKMACHINE > as i686, so this appears as a different issue for me. > rust-cross-canadian hasn't officially worked properly or been supported. In assessing whether a patch is better or worse, it is useful to know which cases regress and which improve. I had hoped this list of failures would be smaller. I will admit I don't know whether this is better or worse than before so I guess that is the next thing I need to determine. What we don't know right now is which combinations work and which don't so we can't even tell people what is expected to work and what isn't/doesn't :( I mentioned this report in case someone can work out the pattern, or even better, understand what a fix looks like... Cheers, Richard
Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > > It does, indeed, but it doesn't seem related to this PR. > > > > Do you know if this has worked? > > > > I am asking as I did all development and testing using SDKMACHINE ?= > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. However, > > looking at some of the logs above, it seems it is using an SDKMACHINE > > as i686, so this appears as a different issue for me. > > > > rust-cross-canadian hasn't officially worked properly or been > supported. In assessing whether a patch is better or worse, it is > useful to know which cases regress and which improve. I had hoped this > list of failures would be smaller. I will admit I don't know whether > this is better or worse than before so I guess that is the next thing I > need to determine. > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this worked. What we don't know right now is which combinations work and which don't > so we can't even tell people what is expected to work and what > isn't/doesn't :( > See above. > I mentioned this report in case someone can work out the pattern, or > even better, understand what a fix looks like... > I am not familiar enough to Rust boostrap to help here but we spent a lot of time to get the SDK working and I think this is a step on the right direction, at least.
On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote: > Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie > <richard.purdie@linuxfoundation.org> escreveu: > > > It does, indeed, but it doesn't seem related to this PR. > > > > > > Do you know if this has worked? > > > > > > I am asking as I did all development and testing using SDKMACHINE > > > ?= > > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. > > > However, > > > looking at some of the logs above, it seems it is using an > > > SDKMACHINE > > > as i686, so this appears as a different issue for me. > > > > > > > rust-cross-canadian hasn't officially worked properly or been > > supported. In assessing whether a patch is better or worse, it is > > useful to know which cases regress and which improve. I had hoped > > this > > list of failures would be smaller. I will admit I don't know > > whether > > this is better or worse than before so I guess that is the next > > thing I > > need to determine. > > > > > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this > worked. > > > What we don't know right now is which combinations work and which > > don't > > so we can't even tell people what is expected to work and what > > isn't/doesn't :( > > > > > See above. > > > I mentioned this report in case someone can work out the pattern, > > or > > even better, understand what a fix looks like... > > > > > I am not familiar enough to Rust boostrap to help here but we spent a > lot of time to get the SDK working and I think this is a step on the > right direction, at least. Thanks, I do appreciate the patches. I think we've talked cross purposes as I did report my aarch64 test case issue previously and I thought this series was to attempt to fix things so the recipe did work generically. If I merge this to fix x86_64, I think people will then just ignore the other cases and things will remain broken there which worries me a lot and means we can't generically enable rust SDKs for the project and gain autobuilder testing to spot future regressions. Obviously you want your use case fixed though. I will try and evaluate things a bit more tomorrow. What I don't want to do is merge a fix which then makes it harder to get things correctly done in future though, particularly when I know there will be an instant backport request to an LTS as soon as I accept it for master. We never should have accepted these rust cross-canadian recipes at all as they are just broken :(. Cheers, Richard
Em seg., 18 de jul. de 2022 às 19:54, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote: > > Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie > > <richard.purdie@linuxfoundation.org> escreveu: > > > > It does, indeed, but it doesn't seem related to this PR. > > > > > > > > Do you know if this has worked? > > > > > > > > I am asking as I did all development and testing using SDKMACHINE > > > > ?= > > > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. > > > > However, > > > > looking at some of the logs above, it seems it is using an > > > > SDKMACHINE > > > > as i686, so this appears as a different issue for me. > > > > > > > > > > rust-cross-canadian hasn't officially worked properly or been > > > supported. In assessing whether a patch is better or worse, it is > > > useful to know which cases regress and which improve. I had hoped > > > this > > > list of failures would be smaller. I will admit I don't know > > > whether > > > this is better or worse than before so I guess that is the next > > > thing I > > > need to determine. > > > > > > > > > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and this > > worked. > > > > > What we don't know right now is which combinations work and which > > > don't > > > so we can't even tell people what is expected to work and what > > > isn't/doesn't :( > > > > > > > > > See above. > > > > > I mentioned this report in case someone can work out the pattern, > > > or > > > even better, understand what a fix looks like... > > > > > > > > > I am not familiar enough to Rust boostrap to help here but we spent a > > lot of time to get the SDK working and I think this is a step on the > > right direction, at least. > > Thanks, I do appreciate the patches. I think we've talked cross > purposes as I did report my aarch64 test case issue previously and I > thought this series was to attempt to fix things so the recipe did work > generically. > I had it fixed to SDKMACHINE as x86_64 on a x86_64. I didn't realise it was using a different SDKMACHINE. If I merge this to fix x86_64, I think people will then just ignore the > other cases and things will remain broken there which worries me a lot > and means we can't generically enable rust SDKs for the project and > gain autobuilder testing to spot future regressions. > I understand. > Obviously you want your use case fixed though. I will try and evaluate > things a bit more tomorrow. What I don't want to do is merge a fix > which then makes it harder to get things correctly done in future > though, particularly when I know there will be an instant backport > request to an LTS as soon as I accept it for master. > In fact I need patch 1/2 as this fixes our use case. We worked on 2/2 (this patch) for completeness. > We never should have accepted these rust cross-canadian recipes at all > as they are just broken :(. > Agreed.
On Mon, 2022-07-18 at 21:07 -0300, Otavio Salvador wrote: > Em seg., 18 de jul. de 2022 às 19:54, Richard Purdie > <richard.purdie@linuxfoundation.org> escreveu: > > On Mon, 2022-07-18 at 18:41 -0300, Otavio Salvador wrote: > > > Em seg., 18 de jul. de 2022 às 18:18, Richard Purdie > > > <richard.purdie@linuxfoundation.org> escreveu: > > > > > It does, indeed, but it doesn't seem related to this PR. > > > > > > > > > > Do you know if this has worked? > > > > > > > > > > I am asking as I did all development and testing > > > > > using SDKMACHINE > > > > > ?= > > > > > 'x86_64' and even MACHINE ?= 'qemuarm64' worked just fine. > > > > > However, > > > > > looking at some of the logs above, it seems it is using an > > > > > SDKMACHINE > > > > > as i686, so this appears as a different issue for me. > > > > > > > > > > > > > rust-cross-canadian hasn't officially worked properly or been > > > > supported. In assessing whether a patch is better or worse, it > > > > is > > > > useful to know which cases regress and which improve. I had > > > > hoped > > > > this > > > > list of failures would be smaller. I will admit I don't know > > > > whether > > > > this is better or worse than before so I guess that is the next > > > > thing I > > > > need to determine. > > > > > > > > > > > > > I told you. I tried SDKMACHINE as x86_64 on a x86_64 host and > > > this > > > worked. > > > > > > > What we don't know right now is which combinations work and > > > > which > > > > don't > > > > so we can't even tell people what is expected to work and what > > > > isn't/doesn't :( > > > > > > > > > > > > > See above. > > > > > > > I mentioned this report in case someone can work out the > > > > pattern, > > > > or > > > > even better, understand what a fix looks like... > > > > > > > > > > > > > I am not familiar enough to Rust boostrap to help here but we > > > spent a > > > lot of time to get the SDK working and I think this is a step on > > > the > > > right direction, at least. > > > > Thanks, I do appreciate the patches. I think we've talked cross > > purposes as I did report my aarch64 test case issue previously and > > I > > thought this series was to attempt to fix things so the recipe did > > work > > generically. > > > > > I had it fixed to SDKMACHINE as x86_64 on a x86_64. I didn't realise > it was using a different SDKMACHINE. > > > If I merge this to fix x86_64, I think people will then just ignore > > the > > other cases and things will remain broken there which worries me a > > lot > > and means we can't generically enable rust SDKs for the project and > > gain autobuilder testing to spot future regressions. > > > > > I understand. > > > Obviously you want your use case fixed though. I will try and > > evaluate > > things a bit more tomorrow. What I don't want to do is merge a fix > > which then makes it harder to get things correctly done in future > > though, particularly when I know there will be an instant backport > > request to an LTS as soon as I accept it for master. > > > > > In fact I need patch 1/2 as this fixes our use case. We worked on 2/2 > (this patch) for completeness. > > > We never should have accepted these rust cross-canadian recipes at > > all > > as they are just broken :(. > > Agreed. > I've done a bit more work on this and the more I dig, the more I think we have some issues we need to sort with taking a step back and checking some assumptions. What I'm lacking is a good way to test the resulting rust toolchain. Would someone with some rust knowledge be able to add something to meta/lib/oeqa/sdk/cases/ which tested rust in the SDK? If someone can add some rust tests in the SDK, I think I might have an idea of what the patches look like to properly fix the rust toolchain there. Cheers, Richard
Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > I've done a bit more work on this and the more I dig, the more I think > we have some issues we need to sort with taking a step back and > checking some assumptions. > > What I'm lacking is a good way to test the resulting rust toolchain. > Would someone with some rust knowledge be able to add something to > meta/lib/oeqa/sdk/cases/ which tested rust in the SDK? > > If someone can add some rust tests in the SDK, I think I might have an > idea of what the patches look like to properly fix the rust toolchain > there. > Ok, I will send you a test case shortly.
On Wed, 2022-07-20 at 15:11 -0300, Otavio Salvador wrote: > > > Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie > <richard.purdie@linuxfoundation.org> escreveu: > > I've done a bit more work on this and the more I dig, the more I > > think > > we have some issues we need to sort with taking a step back and > > checking some assumptions. > > > > What I'm lacking is a good way to test the resulting rust > > toolchain. > > Would someone with some rust knowledge be able to add something to > > meta/lib/oeqa/sdk/cases/ which tested rust in the SDK? > > > > If someone can add some rust tests in the SDK, I think I might have > > an > > idea of what the patches look like to properly fix the rust > > toolchain > > there. > > > > > Ok, I will send you a test case shortly. Thanks. Just to share what I'm thinking, I think we need to add a nativesdk to llvm-rust like this: diff --git a/meta/recipes-devtools/rust/rust-llvm.inc b/meta/recipes-devtools/rust/rust-llvm.inc index 9baad12dc8e..625eb570416 100644 --- a/meta/recipes-devtools/rust/rust-llvm.inc +++ b/meta/recipes-devtools/rust/rust-llvm.inc @@ -47,6 +47,13 @@ EXTRA_OECMAKE:append:class-target = "\ -DLLVM_CONFIG_PATH=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-config \ " +EXTRA_OECMAKE:append:class-nativesdk = "\ + -DCMAKE_CROSSCOMPILING:BOOL=ON \ + -DLLVM_BUILD_TOOLS=OFF \ + -DLLVM_TABLEGEN=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-tblgen \ + -DLLVM_CONFIG_PATH=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-config \ +" + # The debug symbols are huge here (>2GB) so suppress them since they # provide almost no value. If you really need them then override this INHIBIT_PACKAGE_DEBUG_SPLIT = "1" @@ -68,4 +75,4 @@ FILES:${PN}-staticdev =+ "${libdir}/llvm-rust/*/*.a" FILES:${PN} += "${libdir}/libLLVM*.so.* ${libdir}/llvm-rust/lib/*.so.* ${libdir}/llvm-rust/bin" FILES:${PN}-dev += "${datadir}/llvm ${libdir}/llvm-rust/lib/*.so ${libdir}/llvm-rust/include ${libdir}/llvm-rust/share ${libdir}/llvm-rust/lib/cmake" -BBCLASSEXTEND = "native" +BBCLASSEXTEND = "native nativesdk" and then I think rust-cross-canadian can either copy in or create a json file just like rust-cross does. Unlike gcc there is no target specific cross compiler for rust as far as I can tell. The crosssdk recipe also looks a bit suspect and I'm not sure that entirely makes sense now or is needed. I guess it might be if we had rust applications we needed to compile for the sdk itself but we don't have any of those yet? Cheers, Richard
Hello Richard, Em qua., 20 de jul. de 2022 às 15:11, Otavio Salvador < otavio@ossystems.com.br> escreveu: > Em qua., 20 de jul. de 2022 às 14:21, Richard Purdie < > richard.purdie@linuxfoundation.org> escreveu: > >> I've done a bit more work on this and the more I dig, the more I think >> we have some issues we need to sort with taking a step back and >> checking some assumptions. >> >> What I'm lacking is a good way to test the resulting rust toolchain. >> Would someone with some rust knowledge be able to add something to >> meta/lib/oeqa/sdk/cases/ which tested rust in the SDK? >> >> If someone can add some rust tests in the SDK, I think I might have an >> idea of what the patches look like to properly fix the rust toolchain >> there. >> > > Ok, I will send you a test case shortly. > As promised. See attached.
diff --git a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc index 7fc22a4128..01ba151d0a 100644 --- a/meta/recipes-devtools/cargo/cargo-cross-canadian.inc +++ b/meta/recipes-devtools/cargo/cargo-cross-canadian.inc @@ -39,6 +39,18 @@ do_compile:prepend () { PKG_CONFIG_PATH="${RECIPE_SYSROOT_NATIVE}/usr/lib/pkgconfig:${PKG_CONFIG_PATH}" } +create_sdk_wrapper () { + file="$1" + shift + + cat <<- EOF > "${file}" + #!/bin/sh + \$$1 \$@ + EOF + + chmod +x "$file" +} + do_install () { SYS_BINDIR=$(dirname ${D}${bindir}) install -d "${SYS_BINDIR}" @@ -47,6 +59,9 @@ do_install () { chrpath -r "\$ORIGIN/../lib" ${i} done + # Uses SDK's CC as linker so linked binaries works out of box. + create_sdk_wrapper "${SYS_BINDIR}/target-rust-ccld" "CC" + ENV_SETUP_DIR=${D}${base_prefix}/environment-setup.d mkdir "${ENV_SETUP_DIR}" ENV_SETUP_SH="${ENV_SETUP_DIR}/cargo.sh" @@ -58,7 +73,10 @@ do_install () { touch "\$CARGO_HOME/config" echo "[build]" >> "\$CARGO_HOME/config" echo 'target = "'${TARGET_SYS}'"' >> "\$CARGO_HOME/config" - fi + echo '# TARGET_SYS' >> "\$CARGO_HOME/config" + echo '[target.'${TARGET_SYS}']' >> "\$CARGO_HOME/config" + echo 'linker = "target-rust-ccld"' >> "\$CARGO_HOME/config" + fi # Keep the below off as long as HTTP/2 is disabled. export CARGO_HTTP_MULTIPLEXING=false
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> --- (no changes since v1) .../cargo/cargo-cross-canadian.inc | 20 ++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)