I'm developing a Qt project on OS X.
I'm using Jni and include the header jni.h present in the Java jdk.
I'm using the function JNI_CreateJavaVM to create the vm, whose symbols are in the libclient.dylib (libjvm.dylib is the symbol link).
The problem is my app is 64 bits, whereas this library is for i386 architecture, so I cannot link/load it.
How can I use this function in a 64 bits application ?
My only choice is to build Qt in 32 bits, but I don't really like this, cause I'll be stuck in 32 bits forever...(unless java provide this lib for 64bits)
Related
I use 32 bit windows and my assistant has 64 bit. We both use gcc (I specifically use tdm-gcc. My assistant uses qt which also uses gcc as far as I'm aware). I wanted to write a very simple plugin in a form of simple .dll for my assistant to use from inside of her application. To do so I need just to compile my .dll for windows 32 (like 32 bit XP) as a .dll for a windows 64 (like win 7 or 10).
I found that -m64 option could work. However when I compile it and she links it and tries to call my functions it shows that this application with this plugin .dll I've made (on 32 bit windows with tdm-gcc with that -m64 option) silently crashes (program ends and no output is generated).
What is the problem with that? The test we were doing was simple like exporting a function that just returns 232323 and trying to receive and print it on application side - but is still doesn't work.My guess is that this 64 bit .dll is wrong (dependency walker shows dependency on kernel32, isn't it 32 bit specific?)
Should I do something more than putting -m64 to make my plugin compile to 64 bit and work properly there?
It showed it most probably work.. She cant link it in QT from unknown reasons to me (we work remotely and i cannot check) but she succesfully linked it dynamically so it seems -m64 in fact suffice
I'm working on windows applications. I've created a application for windows(64-bit). But when I have installed that application on my system. In services, it is showing something.exe * 32. But I want to make that application only compatible with 64-bit windows, not with 32-bit.
Q1. Is it possible for make application only compatible with 64-bit, not with 32-bit architecture?
Q2. if it is possible, then please tell me the factors which make it 64-bit compatible only, not 32-bit.
Q3. What changes i need to make for compatibility with 64-bit Windows only.
Yes it is possible. Compile it using 64-bit op codes and 64 bit registers and it will not run on a 32 bit Windows system. For example, using GCC, you can add the -arch x86_64 option to force 64 bit compilation.
You, however, have not stated which language you're using. If you're using Java or some other byte-code style language then there's nothing that you can do.
I have a 32-bit dll that I have gotten from a third party. They have no 64 bit version. I wish to load this dll into 64 bit python. To do this, I need a 64 bit dll. Is there a tool to convert a 32 bit dll to a 64 bit dll or is this impossible? If it impossible then I must use 32 bit python I guess.
Only the vendor can do this, unless you get access to the DLL's source code. It must be recompiled for 64 bit.
I guess you'll have to use 32-bit python...
32 and 64bit DLLS have different ABIs and calling conventions. You just can't load a 32bit DLL into a 64bit process or the other way around.
As mentioned in the comments, you have to recompile from source.
You can't create a 64-bit DLL from 32-bit one without the source code.
But you can create an adapter as a native 32-bit application that loads the 32-bit DLL and provides access to it's functions via some kind of inter-process communications (e.g. named pipes)
Of course, that's may be senseless in some cases and you may prefer to use 32-bit python.
So it depends.
I'm thinking like Apple did with their universal binaries containing both x86 and ppc code
No. The IMAGE_FILE_HEADER.Machine field determines whether a DLL is x86 or x64. One field cannot hold two different values simultaneously, and there's only one IMAGE_FILE_HEADER in a DLL.
That said, a pure .Net DLL contains IL instructions, and they can be compiled to either 32 bits or 64 bits.
You can build the dll as 32Bit and it can work in both 64 and 32 environment, but it will be 32 bit dll
I initially thought that 64 bit instructions would not work on OS-X 10.5.
I wrote a little test program and compiled it with GCC -m64.
I used long long for my 64 bit integers.
The assembly instructions used look like they are 64 bit. eg. imultq and movq 8(%rbp),%rax.
I seems to work.
I am only using printf to display the 64 bit values using %lld.
Is this the expected behaviour?
Are there any gotcha's that would cause this to fail?
Am I allowed to ask multiple questions in a question?
Does this work on other OS's?
Just to make this completely clear, here is the situation for 32- and 64-bit executables on OS X:
Both 32- and 64-bit user space executables can be run on both 32- and 64-bit kernels in OS X 10.6, without emulation. On 10.4 and 10.5, both 32- and 64-bit executables can run on the 32-bit kernel. (This is not true on Windows)
The user space system libraries and frameworks are built 32/64-bit fat on 10.5 and 10.6. You can link against them normally, whether you're building for 32-bit, 64-bit, or both. A few libraries (basically the POSIX layer) are also built 32/64-bit fat on 10.4, but many of them are not.
On 10.6, the build tools produce 64-bit executables by default. On 10.5 and earlier, the default is 32-bit.
On 10.6, executables that are built fat will run the 64-bit side by default. On 10.5 and earlier, the 32-bit side is executed by default.
You can always manually specify which slice of a fat executable to use by using the arch command. eg. arch -arch i386 someCommandToRunThatIWantToRunIn32BitMode. For application bundles, you can either launch them from the command line, or there is a preference if you "get info" on the application.
OS X and Linux use the LP64 model for 64-bit executables. Pointers and long are 64 bits wide, int is still 32 bits, and long long is still 64 bits. (Windows uses the LLP64 model instead -- long is 32 bits wide in 64 bit Windows).
Mac OS X 10.5 supports 64-bit user-land applications pretty well. In fact, Xcode runs in 64-bit in 10.5 on a compatible architecture.
It's only the built-in applications (Finder, Safari, frameworks, daemons etc.) also have the 64-bit version in 10.6.
Meta: I don't like to see answers deleted. I guess this has been discussed somewhere.
Anyway, KennyTM and the other kind sole got me started and although one answer was deleted, I appreciated your efforts.
It looks like this is expected behaviour on the Mac, and it even seems to work on a 32-bit Linux as well (although I have not tested extensively)
Yep. GCC behaves different (at least in my limited observation) for 32 (-m32) and 64 (-m64) bit modes. In 32 bit, I was able to access variable arguments using an array. In 64 bit mode this just does not work.
I have learnt that you MUST access variable parameters using va_list as defined by stdarg.h because it works in both modes.
Now I have a command-line program that runs and passes all of my test cases in 32 bit and 64 bit modes on Mac OS-X.
The program implements a linked list garbage collector sweeping 16-byte aligned malloc-allocated objects from a global list as well as machine registers and the stack - actually, there are extra registers in 64 bit mode, so I still have a bit of work to do.
Objects are either a collection of 32 or 64 bit words which link together to form LISP/Scheme-like data structures.
In summary, it is a complex program that does a lot of messing with pointers and it works the same under 32 and 64 bit modes.
Asking multiple questions does not get you all the answers you might want.
It seems to work, as I wrote, on Linux.
Again, thank you for helping me with this.