From: bc@nospicedham.freeuk.com   
      
   On 19/01/2018 08:08, Alexei A. Frounze wrote:   
   > On Thursday, January 18, 2018 at 6:13:31 PM UTC-8, Bartc wrote:   
   >> At the minute I'm stuck using ld from gcc (under Windows), as alternates   
   >> either have problems, or they don't exist.   
   >   
   > If you have tried mine (from Smaller C), what's missing?   
      
   I think I've played with Smaller C in the past.   
      
   But my requirements are that linker inputs be 64-bit object files in   
   COFF format, and also .DLL shared libraries.   
      
   When I tried the SMLRL.EXE file today (which I had to rename to SL.EXE   
   because those names of yours are hard to type consistently!) it said it   
   wanted an ELF file.   
      
   (Up until now, I've been using my own compilers that generate ASM source   
   code for x64 in Nasm format. I've used NASM -fwin64 on that to create   
   object files. I've then used something like this ('link' is a rename of   
   'ld'):   
      
      link -e main -o hello.exe hello.obj c:/windows/system32/msvcrt.dll   
      
   as my system can't deal with .a or .lib files for such external libraries.   
      
   I've also tried GOLINK in a similar way, but that has a peculiar set of   
   problems of its own (the most serious is that the resulting EXE triggers   
   anti-virus traps. And it can run 2-4 times more slowly).   
      
   However, NASM also has some problems, the most notable of which is that   
   it gets VERY slow on large inputs. So I am now using my own assembler   
   for x64, and yesterday started switching over to using it over NASM.   
   That assembler only generates 64-bit COFF object files. It needs a   
   linker that deals with such files, and also .DLLs.   
      
   I will probably create such a linker eventually, but the task is not   
   very appealing.)   
      
   --   
   bartc   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)