How would me vpc.bat should be? Supposed I'm on Windows 64 bit (hence AMD64) and I will not use any of the AVX variants so I won't need NASM. But it seems there is a bug. Even if -cpuAMD64 is specified, it still asking for NASM to be installed and will use NASM. I want to use just GNU AS.
The only changes I made to vpc.bat is replacing -cpugnuP4 with -cpuAMD64. But for unknown reasons the compilation is always invoking NASM and always error with relocation and symbols not found. From my days as a C developer it's the symptom of missing library to the linker reported such error.
I have a closer look at the gcc command vpc invoked that printed on the screen. Did you got it wrong? It should be rtl.o, not rtl.c, you are telling it to link with a C source file so the symbols from rtl.o are missing and it error. As I don't know Java and don't know how to build the project from source I can only reach you for help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is my email address. william.cockshott@glasgow.ac.uk
Up to about 12 years ago an effort was put in, with my students to maintain windows compatibility. We generally, at that point used the djgpp version of gcc for compatibility.
With the obsolescence of that subsystem under windows, it has not been worth putting an effort into it.
The more modern WSL subsystem now supports a purely Linux based toolset so there is no need to differentiate between windows and Linux.
I am no longer teaching here so I do not have students to put in effort to maintain things. My own effort is directed at making the system work on other Linux architectures.
There are a lot of obsolete architectures still in the system which should probably be cleaned out – all the 32 bit compiler targets for a start.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The use of rtl.c is deliberate.
It enables us to avoid having to have separate jar/zip release files for different architectures which we would have to do if we distributed .o files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I removed -cpugnuP4 as it will default to -cpuAMD64 anyway so don't need to specify it. I also removed -felf as I think it's nonsense on Windows. ELF format is of Linux and I have no idea if Windows supports it or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I should stop guessing it and waiting for your help. I'm not good C programmer either. I found C is hard so I go for Pascal. This is the full error message:
As you see, there are indeed two problems. First, the symbols of the RTL are not available, hence undefined reference. Second, the output by NASM seems incompatible with GNU AS and GNU LINKER, hence the relocation truncated error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After moving test.pas to the same directory as other files (now everything is in %mmpcdir%), the problem about RTL symbols not found disappeared. But the relocation truncated error is still there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@paulcockshott I know you developed mainly on Linux but you shouldn't hardcode this command. It makes no sense to generate elf64 format on Windows isn't it? It seems you don't check this mailing list either. How could I contact you? So far there is no answers from you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How would me vpc.bat should be? Supposed I'm on Windows 64 bit (hence AMD64) and I will not use any of the AVX variants so I won't need NASM. But it seems there is a bug. Even if -cpuAMD64 is specified, it still asking for NASM to be installed and will use NASM. I want to use just GNU AS.
The only changes I made to vpc.bat is replacing -cpugnuP4 with -cpuAMD64. But for unknown reasons the compilation is always invoking NASM and always error with relocation and symbols not found. From my days as a C developer it's the symptom of missing library to the linker reported such error.
I have a closer look at the gcc command vpc invoked that printed on the screen. Did you got it wrong? It should be rtl.o, not rtl.c, you are telling it to link with a C source file so the symbols from rtl.o are missing and it error. As I don't know Java and don't know how to build the project from source I can only reach you for help.
Here is my email address. william.cockshott@glasgow.ac.uk
Up to about 12 years ago an effort was put in, with my students to maintain windows compatibility. We generally, at that point used the djgpp version of gcc for compatibility.
With the obsolescence of that subsystem under windows, it has not been worth putting an effort into it.
The more modern WSL subsystem now supports a purely Linux based toolset so there is no need to differentiate between windows and Linux.
I am no longer teaching here so I do not have students to put in effort to maintain things. My own effort is directed at making the system work on other Linux architectures.
There are a lot of obsolete architectures still in the system which should probably be cleaned out – all the 32 bit compiler targets for a start.
The use of rtl.c is deliberate.
It enables us to avoid having to have separate jar/zip release files for different architectures which we would have to do if we distributed .o files.
@paulcockshott The faulty command is here:
gcc -g -no-pie -lm -o test\test p.o C:/mmpc/rtl.c -DPTW32
You are telling it to link with a C source file! The correct is rtl.o. This is just a typo of yours.
This is currently my vpc.bat:
@echo off
java -Xmx800m -Dmmpcdir=%mmpcdir% -jar %mmpcdir%\mmpc.jar %1 -o%1.exe -U -DPTW32 -opt0 %2 %3 %4 %5 %6 %7 %8
I removed -cpugnuP4 as it will default to -cpuAMD64 anyway so don't need to specify it. I also removed -felf as I think it's nonsense on Windows. ELF format is of Linux and I have no idea if Windows supports it or not.
It seems I was wrong about rtl.c and rtl.o, but the problem is still there. Please help.
I think I should stop guessing it and waiting for your help. I'm not good C programmer either. I found C is hard so I go for Pascal. This is the full error message:
As you see, there are indeed two problems. First, the symbols of the RTL are not available, hence undefined reference. Second, the output by NASM seems incompatible with GNU AS and GNU LINKER, hence the relocation truncated error.
I did try make all and it successfully built rtl.o and rtlb.o, but it doesn't solve the problem.
Last edit: dwzgocl0 2022-09-22
After moving test.pas to the same directory as other files (now everything is in %mmpcdir%), the problem about RTL symbols not found disappeared. But the relocation truncated error is still there.
Look at the command sent to nasm:
nasm -f elf64 -lasm.lst -g -o p.o p.asm
@paulcockshott I know you developed mainly on Linux but you shouldn't hardcode this command. It makes no sense to generate elf64 format on Windows isn't it? It seems you don't check this mailing list either. How could I contact you? So far there is no answers from you.