Tomasz, is there any chance for x64 version of fasm? I ask because I use (and probably not me alone) an amd64-nomultilib system and fasm cannot run on it. Have to compile code under Win, which is not super convenient.
Thanks in advance

Did you test it? Because Linux FASM should work on 64bit Linux systems without any compatibility libraries installed.

zhak: To answer your specific question. No, there is not any 64-bit native version of fasm. It would require a complete rewrite.

JohnFound: Just now I did some basic searching and I see lots of people complaining about the inability to run 32-bit binaries on a system using nomultilib. Do you know of a workaround?

The Linux version of fasm does not need any shared libraries, only pure syscalls. If I understand correctly that "nomultilib" simply means that the 32-bit libraries (including libc) are not available, it would only affect the libc version of fasm.

But if the IA32 emulation was turned off in kernel then you would no be able to run even the syscall-based version of fasm - and perhaps this is the problem here.

Off on a tangent: in case of fasm g the multilib is required, because fasm g uses malloc/realloc from libc. I was considering making a custom malloc implementation (or perhaps taking one from FASMLIB) to get rid of that libc-dependency (I could also make a DOS version of fasm g then), but I'm not sure if it's worth the effort.

On the other hand, I have written fasm g in such a way, that it should be possible to convert it to x86-64 (or even other architectures) much easier than fasm 1. And it may even be possible to run it in the long mode with no changes (though the re-assembly would be necessary to get rid of the short INC/DEC encodings), as long as malloc was forced to allocate only in the low 4G (and the stack pointer would need to be in the low range, too). With fasm 1 such trick would be harder - not only because it uses some of the instructions that are not available in long mode, but mainly because it uses [esp+offset] constructions to access pushed values all over the place.

Well, I don't know what "nomultilib" means, but the only x64 Linux I know that to not support 32bit application, means simply the 32bit shared libraries are not installed.

For example on my hosting provider web servers. The system calls through int 80h and the loading of the 32bit ELF binaries works on these systems. So, all 32bit programs that use only system calls or are statically linked can run on such systems. I am running this way all my assembly written CGI/FastCGI code and fossil server, that is C application, but statically linked.

Maybe there are some special kernels with switched off support for 32bit ELF format, but I know nothing about such systems.