Build optlink with masm 9 or 10 and with dmc-tools instead of SLR

[rainers]

• build libs with dmc's lib
• masm (v9 or v10) complained about a number of "mov AL,errorCode" which had to be changed to AX (I guess it would not assume an external to fit into a byte)
• add a number of ridiculous "BYTE PTR" modifiers
• do not build loadx.exe

To build, set environment variable DM (if not \dm), add dmc\bin to the path and run build_optlink.bat.

[ghost]

Btw @WalterBright, maybe you know this already but here's a handy tip if you want to diff this locally instead of using Github:

git fetch upstream pull/2/head:pull2
git checkout pull2
git difftool --dir-diff head~1

You would probably replace upstream with master or whatever your remote name is.

[ghost]

Looks good, this compiles and links link.exe for me using VS10.

[rainers]

The compiled version hangs for me after a few files when trying to build
the dmd test suite, but continues for a few files if I restart the test
build.
I remember this was a problem solved in the past. I didn't find a
matching entry in the log, is the respective patch committed?

[WalterBright]

Optlink fails on multicore machines. You have to set the "affinity" to one core.

[WalterBright]

I use:

imagecfg -a 0x1 \cbx\optlinkc\os2link\objnt\link.exe

imagecfg.exe is available on the intarnets. http://www.robpol86.com/index.php/ImageCFG

[CyberShadow]

Maybe OptLink can do this instead?

SetProcessAffinityMask(GetCurrentProcess(), 1);

[rainers]

Thanks, that explains it. Until we have it in optlink as Vladimir
suggested, I've added it to the build rules.

[ghost]

Is it correct to just call this external app like that? xfBuild used an elaborate way to call the

[ghost]

Is it correct to just call this external app like that? xfBuild used an elaborate way to call the SetProcessAffinityMask function, and it was specifically made to tame Optlink, see here.

[rainers]

On 11.03.2013 01:54, Andrej Mitrovic wrote:

Is it correct to just call this external app like that? xfBuild used an elaborate way to call the SetProcessAffinityMask function, and it was specifically made to tame Optlink, see here.

I think setting the affinity in the exe header is ok. The only drawback
I see is that the process is fixed to the first core, so multiple
instances of optlink (or any other program applying the same technique)
will not run in parallel on other cores.
Randomizing the core by setting the affinity from within optlink might
be better, but I don't think anyone has complained that the linking has
taken too long so far.

[WalterBright]

I think it would be better if optlink, upon startup, could say "stay on this core". But I don't know if there's a windows api to do that.