I've tested both on Linux and MinGW. They definitely work.

It works because instead of exporting the variable in the current shell, you're telling it to start the following command "make" with these specified environment variables. So it only affects the make command, and doesn't make a change to the current shell, which is what what the explicit export does.

Only place it won't is Windows Command Prompt - it doesn't have %OSTYPE% as an environment variable, only %OS%.

As I also said earlier, doing an explicit export before the make, also passes the variable through to make.

Sam.

I've committed the auto-detection lines for Macosx. Essentially what DaveF said.

In case anyone is interested in the answer to this issue, I figured it out just now (while grappling with GCC for another project).

The solution is simple - it seems that these days the difference between the gcc and g++ executables is more pronounced. BeebAsm used to launch gcc to do both the compiling (of C and C++ source code) and linking, as was the old way. These days it seems that if you want to link a C++ program, you need to invoke the linker with g++ rather than with gcc. If you don't, some essential C++ 'glue' won't be linked in to the executable, even when specifying -lstdc++ on the command line.

Like this, both dynamically and statically linked versions of BeebAsm work fine under GCC / MinGW, without any kind of hacks or special cases for different versions of GCC.

I'll update the BeebAsm repository accordingly when I release a new version.