error: linker `x86_64-w64-mingw32-gcc` not found - rust

I am using MacOS Big Sur, and i am trying to cross compile to windows, but the problem is, this "error: linker x86_64-w64-mingw32-gcc not found" prevents me from doing that, here are my cargo dependencies:
[dependencies]
rand = "0.8.4"
macroquad = "0.3.13"
perlin_rust = "0.1.0"
libm = "0.2.2"
I have tried Cargo Clean/Update, and I have tried mvsc instead of gnu

TLDR;
Besides installing a cross target with rustup you need to install an actual cross linker and tell cargo about it using cargo config file or an environment variable
It seems you are attempting to cross compile your package.
you can read here more about cross compilation;
In a nutshell compiler is a program that takes your text source code and produces something the your operating system and cpu can understand.
When you are building software for the platform you are developing on, it's all nice. You have all the tools but when you want to target another platform or os, you need a compiler that is produced to work on your machine but outputs a binary that is supposed to work on the target platform/os.
So, In your case you need to install a cross toolchain that for mac for mingw target because rust does not have a cross linker itself. Once you get a cross toolchain all you need to do is to tell cargo how to find it.
Here is a project aims to make cross compilation less painful.
I also strongly advise you to read the cargo book
here you can see one of the ways of telling cargo about the cross linker
another way is to use an environment variable (which I like better and easier to use with makefiles)
and below you can see an example of that from one of my makefiles
and Again the cargo book refers to it
Overall cross compiling is painful it took me quite some time to understand the mechanics of it but it was worth it instead of copy pasting commands I found on the blogs.
I also feel like it lacks severe documentation. Cargo book doesn't tell you anything about finding a linker assumes you know this already and pictures cross compiling as something just work out of box after installing a target toolchain with rustup.

I had the same problem, the reason was that there were special characters in the directory where I had the project. such as accents á, í, etc.
So I changed them for regular characters and the problem stopped showing.

Related

Handling autoconf with Android after NDK16

I'm trying to update an existing configuration we have we are cross compiling for a number of targets - the question specifically here is about Android. More specifically we are building code using cmake and the hunter package manager. However we are building ICU using a link that uses autoconf/configure, called from cmake. Not sure that is specifically important except that we have less control on the use of configure than is generally the case.
OK: we have a version that builds against an old NDK but I am updating and have hit a problem identified by https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md: with NDK16 and later, the value of the sysroot parameter needs to vary between compilation and linkage. As it stands the configure script tries to build a small program conftest.c - the program fails to link. Manually I can compile the code in two stages using -c and then linking the subsequent .o, but that is not what configure is trying to do.
Now the reality is that when I build this code, I don't actually need to link the code - I am generating a library which is used elsewhere. However that is not currently the way that configure sees it.
I may look to redo the configuration script to just check that the code can be compiled when cross compiling. However I am curious to know if anybody has managed to handle this sort of thing by keeping the existing config files and just changing the parameters by which the scripts are called.
When r19 releases to stable this problem will go away on its own (https://github.com/android-ndk/ndk/issues/780), but since that's still in beta it's not a good solution just yet.
Prior to r19 (this isn't really unique to r16+, this has always been the case and it was just asymptomatic previously), autoconf builds should be done using a standalone toolchain.
You however should not use a standalone toolchain for CMake, so odds are something about your configuration will need to change until r19 is released. Depending on the effort involved, it may make sense to keep to r15 until r19 is available.

How do I build with a custom libstd?

I want to make some changes in libstd and then test them with a toy program. It looks like I can build libstd.so by going to rust/src/libstd and doing a (nightly) cargo build. Once I've done that, how do I get a toy program to build with that libstd instead of the regular version installed on my system?
There are two possibilities in my mind.
Build the compiler from source everytime
Download the Rust source
Make your changes to std
Follow the steps for building from source
Pass an option to rustc that modifies it search path
Run rustc --help
The first two options (--cfg SPEC or -L [KIND=]PATH) are probably were you would point rustc to your version of the std.
I am not very sure how this would work. Ideally someone more knowledgeable could answer this part, because I think it is the preferred solution and way easier.

arm-linux-gnueabi toolchain vs arm-linux-androideabi toolchain.

Can I compile files (e.g. C or C++ source code) using for my android device using the arm-linux-gnueabi-* toolchain?
My question might seem a bit silly, but will I get the same result as compiling with the arm-linux-androideabi-* toolchain?
A compilation might mean more than just converting source code to binary. A compiler like GCC also provides certain libraries, in this case libgcc for handling what hardware can't handle. When a compiler becomes a toolchain, it also provides runtime libraries standardised by the programming language similar to ones provided in target system. In arm-linux-gnueabi-'s case that might be libc and for arm-linux-androideabi- that's bionic.
You can produce compatible object files to be used by different compilers, that's what elf is for.
You can produce static executable which can be mighty in size and they should work on any matching hardware/kernel, because in that case toolchains aim for that.
But if you produce dynamic executables, those ones can only run on systems that's supporting their dependencies. Because of that a simple "hello world" application that's not static build by arm-linux-gnueabi- won't work on an Android system since it provides bionic, not libc.

Compile dodgy Fortran 77 code in a modern compiler

I am trying to compile a piece of software written in Fortran 77. I should point out that I don't know much at all about Fortran, and would really rather not start modifying the code for this software - particularly as I'm not sure what the licensing of the software is, and I don't know if I would be able to redistribute my modified version.
The code compiles fine on OS X and Windows using the g77 compiler that is (fairly easily) available for these systems. However, I cannot get it to work on my Ubuntu distribution, as I can't seem to get hold of g77 for Ubuntu anymore, and if I try and install an old version of it, it seems to muck up my entire GCC installation. I have tried compiling the code with both gfortran and g95, but it doesn't work with either as:
The code uses real variables as loop indices (yes, I know, bad idea). g95 supports this with the -freal-loops option, but gfortran doesn't.
The code uses real variables to index into arrays, which gfortran will support (with a warning), but g95 won't support.
Can anyone suggest a way to compile this code with those two 'dodgy' features using a modern and easily-available compiler such as g95 or gfortran?
Pass the argument -std=legacy to gfortran. Features removed in F95, like real loop and array indices, should compile (perhaps with a warning) in legacy mode.

how to change the host type for a 'Canadian cross' compilation of GCC with crosstool-NG

I've installed crosstool-NG and built GCC on a host+build x86 machine that targets arm-unknown-linux-gnueabi. I've then used arm-unknown-linux-gnueabi-gcc to compile a program that ran well on my ARM board.
I'm wanting to now build GCC, targeting ARM to be hosted on ARM. I believe the lingo is
build=i486-pc-linux-gnu
target=arm-unknown-linux-gnueabi-gcc
host=arm-unknown-linux-gnueabi-gcc
How do I do this? do I run ./configure for crosstool-NG passing --host=arm-unknown-linux-gnueabi-gcc?
or do I change the environment variables for CC/etc?
You do this with a .config file. I think samples with a comma in the name are good ones to look at. The main difference is that you must run ct-ng multiple times to create several cross compilers.
ct-ng has under went some changes in Canadian crosses lately. However, you will probably need to re-use your original cross compiler that runs on the PC. The reason is that a compiler will include libraries compiled for the ARM and you need to generate these libraries on your PC. Generally, ensure that the iX86-host+ARM-target compiler is on your path. Then you must set the host tuple or prefix for this tool chain in the toolchain menu. You need set the build tuple to the same compiler.
ct-ng help | grep variables
This gives a directory with a bunch of text files that you can grep for hints.
See 6 - Toolchain types.txt for example. Cross-native or Canadian-cross really doesn't matter, in terms of complexity of building. You need only one intermediate for Cross native, but you need two intermediate compilers for a Canadian cross.
Edit: Ct-ng's How a compiler is constructed has some information on all the happening.

Resources