11-25-2022, 07:32 PM
This line in the error log:
seems to indicate a 32-bit "data.o" file was created. Quite possibly a 32-bit object file that is used by the linker to produce an executable. This is not compatible with 64-bit. This rings a bell because of the switches used in the program to convert to object file. Likely this came out of "DATA" statements in your program.
That line with "objcopy.exe" has to be investigated.
This line:
is a very small portion of a really large command line (which is less likely to work on Linux but works quite well on Windows) that seems to be including 32-bit libraries into what is supposed to be a 64-bit program. A bunch of things say "32" which means 32-bit; the 64-bit libraries do not have such labelling. Again, the achitectures (i386/i486/i586/i686 for 32-bit, and amd64/x86_64 for 64-bit) are different and do not get along. If you say you are on a 64-bit system and have 64-bit QB64, then you cannot use 32-bit libraries nor object files at all.
If you said you tried compiling your program with a fresh installation of QB64 Phoenix Edition, instead of the old QB64 Team edition, and it's all on a 64-bit operating system then something is out of place here.
Where do you have QB64 installed? It should be inside the user account. Some people hate the extra typing that comes from that and therefore create a directory right under "C:\", but it would be at your own risk if you do it. Do not install into "Program Files (x86)" if it exists because this has been a historial mess that M$ created. It would require write permissions in the QB64 directory and at least the "internal" child directory, and it gets tiresome having to give confirmation to write something in there unless User Account Control is disabled, which is not recommended on Windows. I don't know how it is on Windows10+, I'm only speaking out of small experience with Windows10 and a bit better experience with Windows7 and the best at WindowsXP 32-bit.
Code: (Select All)
internal\c\c_compiler\bin\objcopy.exe -Ibinary -Oelf32-i386 -Bi386 internal\temp/data.bin internal\temp/data.oseems to indicate a 32-bit "data.o" file was created. Quite possibly a 32-bit object file that is used by the linker to produce an executable. This is not compatible with 64-bit. This rings a bell because of the switches used in the program to convert to object file. Likely this came out of "DATA" statements in your program.
That line with "objcopy.exe" has to be investigated.
This line:
Code: (Select All)
internal\c/parts/audio/extras/libxmp-lite.a internal\c/parts/audio/extras/midi_ma_vtable_stub.o internal\c/parts/core/src.a -static-libgcc -static-libstdc++ -lcomdlg32 -lole32 -mwindows -lopengl32 -lglu32 -lwinmm -lwinmm -lwinmm -lksguid -ldxguid -lole32 -lgdi32is a very small portion of a really large command line (which is less likely to work on Linux but works quite well on Windows) that seems to be including 32-bit libraries into what is supposed to be a 64-bit program. A bunch of things say "32" which means 32-bit; the 64-bit libraries do not have such labelling. Again, the achitectures (i386/i486/i586/i686 for 32-bit, and amd64/x86_64 for 64-bit) are different and do not get along. If you say you are on a 64-bit system and have 64-bit QB64, then you cannot use 32-bit libraries nor object files at all.
If you said you tried compiling your program with a fresh installation of QB64 Phoenix Edition, instead of the old QB64 Team edition, and it's all on a 64-bit operating system then something is out of place here.
Where do you have QB64 installed? It should be inside the user account. Some people hate the extra typing that comes from that and therefore create a directory right under "C:\", but it would be at your own risk if you do it. Do not install into "Program Files (x86)" if it exists because this has been a historial mess that M$ created. It would require write permissions in the QB64 directory and at least the "internal" child directory, and it gets tiresome having to give confirmation to write something in there unless User Account Control is disabled, which is not recommended on Windows. I don't know how it is on Windows10+, I'm only speaking out of small experience with Windows10 and a bit better experience with Windows7 and the best at WindowsXP 32-bit.