while porting tools to different Systems I have encounter a Problem with windows 64 bit.
I have successfully build dlls with linux 32/64 and windows32. I have tried mingw-64 with msys but unfortunately I get only 32 bit dlls. This is a part of my script to obtain the dlls
gcc -o tool_jni.dll -static-libgcc -static-libstdc++ -Wl,--add-stdcall-alias -shared - IC:/Java/jdk/include -IC:/Java/jdk/include/win32 $SOURCES
I get NO error messages, just not the desired DLLs
I am open for any solution. I dont have to use the script, I just need the DLLs.
Related
I'm trying to compile and link an assembly file to an executable with NASM and the standard LD linker on my MacBook Air M1. I have no problems with getting the .o file, but if I want to link it with LD, it throws that error:
ld: file not found: elf_i386
Command:
ld -m elf_i386 -s -o hello hello.o
What do I have to change?
Those are options for GNU ld on x86 Linux. (Note the ELF part of the target object-file format, and the i386). MacOS uses the MachO object-file format, not ELF, and apparently their ld takes different options.
Also, MacOS hasn't supported 32-bit x86 for a few versions now, so an M1 mac with an AArch64 CPU definitely can't run 32-bit x86 executables natively.
So get an emulator for a 32-bit Linux environment if you want to follow a tutorial for that environment, or find a tutorial for AArch64 MacOS. Or possibly x86-64 MacOS which should still work transparently thanks to Rosetta, but make sure single-step debugging actually works. That's an essential part of a development environment for learning asm.
Assembly language is not portable at all, you need a tutorial for the OS, CPU-architecture, and mode (32-bit vs. 64-bit) that you're going to built in. Don't waste your time trying to port a tutorial at the same time you're learning the basics it's trying to teach. You'd have to already know both systems to know which parts of the code and build commands need to change.
I need to use the TCC compiler to link object files generated by GCC. However, GCC in MinGW outputs object files in COFF format, and TCC only supports the ELF format. How can I make GCC generate ELF object files?
$ cat test.c
int main(void)
{
return 0;
}
$ gcc -c test.c
$ file test.o
test.o: MS Windows COFF Intel 80386 object file
$ tcc -c test.c
$ file test.o
test.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
However, GCC in MinGW outputs object files in COFF format
GCC can be configured to generate various outputs (including ELF) regardless of which host it runs on.
That is, a GCC running on Linux could be configured to generate COFF, and a GCC running on Windows could be configured to generate ELF32 or ELF64, for various processors (e.g. x86, or SPARC, or MIPS).
A compiler that runs on one kind of host, but generates code for a different kind, is called a cross-compiler.
TCC only supports the ELF format
This is not a meaningful statement: it could mean that you want GCC to generate ELF32 for i686 Linux, or ELF64 for SPARC Solaris, or any number of other processor/os/bit combinations.
You should figure out what target processor and operating system you want to run your final executable on, and then build (non-trivial) or download appropriate cross-compiler from Windows to that target.
file test.o
test.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
Ok, you want Windows to Linux/i386/ELF32 cross-compiler.
strip might help. strip accepts various object file formats for input and output type (the bfdname). strip --info for the supported formats.
strip -o outputname -O elf32-i386 objfile Doing so on a 64 bit executable, converted to 32bit control headers will lead to nothing but crash, so pick your output form carefully. Make sure you aren't changing assumed bitwidths / endians along with headers.
Not running MinGW, so, not tested, may not work for your needs, or worse, may jump and catch fire.
You want your compiler (MinGW) to generate binaries that are not of the type usable for your host system (Windows). This is called cross-compiling, and it is a somewhat involved subject -- because to create complete executables you will also need the various libraries: standard libraries, target OS libraries, third-party libraries... so it is not merely the subject of "how do I get the compiler to create ELF", but also "how do I get the whole supporting cast of ELF libs so I can link against them?".
OSDev has quite extensive documentation on the subject of setting up a cross-compiler; however, since you did not tell us what exactly your problem is, it is difficult to advise you further.
If what you want is generating Linux binaries, my advise would be to not bother with cross-compilation (which is a tricky subject -- and much better supported the other way around, i.e. targeting Windows from Linux), but rather install a Linux distribution in parallel to your Windows, and work natively with that.
I have a 64-bit system, but gcc is 32-bits and when I do
>./gcc -c foobar.c
it makes foobar.o which is 64-bits. OK, but how does it know to do that? Based on what environment setting does it know to produce 64-bit object, and where is that documented??
Come to think about it, it is strange that it does that, is it not?? But file utility clearly says, gcc is 32 bits and foobar.o is 64 bits. ( I moved everything to the same directory so it would not be confused. )
I also checked the 3 dynamically linked libraries that it reads: libc, libm and libz and they are also all 32 bits.
To clarify, I don't want to know, how to make it do 32 bits. I want to know, what is it looking at now that it makes it do 64. That is my question, not how to force it the other way around.
When GCC is configured three different systems can be specified:
build: - the system where GCC is going to be built (probably not
relevant to your question)
host: - the system where GCC is going to
be executed (32 bit in your case)
target: the system where binaries, produced by GCC are going to be executed (64 bit in your case)
You can see how your GCC was configured by running:
gcc -v
command (look for --{build,host,target} options.
I'm compiling very simple code in windows7 64bit.
(in C:\MinGw\bin) "mingw32-g++.exe -c -Wall filepath\filename.cpp -o filepath\filename.exe"
When the .exe run, it give me 16-bit incompatibility error on the system.
Adding -m32 in the compiling arguments, the result are the same;
I'm using MinGwfrom www.mingw.com actually I don't want use IDE.
What could be the solution?
p.s. This happen since I've installed and try various IDE, it is possible that some of these have installed a different version of mingw, have changed some path or have changed the configuration somewhere. I tried code::blocks, codelite, microsoft visual studio express(didn't go right).
Thanks
I have recently downloaded the mingw-w64 package under Fedora Linux in order to be able to cross compile targetting both win32 and "Windows 64". But I fail to understand how to specify what target I want to use. What flags do I need to supply to gcc and to the linker in order to choose my target architecture?
W32 and W64 are two different architectures, so you distinguish by compiler name. The debian mingw-w64 calls them i686-w64-mingw32-gcc for Win32 and x86_64-w64-mingw32-gcc for Win64.