On 8/21/07, trulyliu trulyliu@gmail.com wrote:
Can I made Arithmetic.dll.so ? And link it against my linux App?
A library function runs in the context of the process that invokes it. A library doesn't have its own TEB/memory layout/exception handling that works independently of the process that calls it, no matter how it is compiled. If the wine plugin API is ever made, it will modify the process so it has what the library expects when the library functions are called.
Does your Arithmetic.dll.so call any Windows functions? If so, you need wine and you will always need wine, plugin API or no plugin API, whether you compile it into a DLL or .dll.so. But if you only use ANCI C stuff you can compile it into a .so and use it without wine.
If you want something that runs seamlessly on every operating system today, IMHO you should consider Java.
2007/8/21, Damjan Jovanovic <damjan.jov@gmail.com >:
On 8/21/07, trulyliu <trulyliu@gmail.com > wrote:
I have tried these code, It works well. Thanks a lot. Could I use gcc/g++ instead of winegcc/wineg++ ??? mplayer use gcc as it's complier? What's the mystery in it?
gcc/g++ would give you the wrong ABI (eg. 4 bytes per wide char instead of 2 bytes), and the special code needed to set up the Windows memory layout and the thread extension block and structured exception handling wouldn't get executed, leading to segfaults when you call any code that tries to access them. That's assuming you can even compile and link.
That's why you need winegcc/wineg++.
trulyliu@gmail.com
Damjan
-- trulyliu@gmail.com
Damjan
2007/8/21, Damjan Jovanovic damjan.jov@gmail.com:
On 8/21/07, trulyliu trulyliu@gmail.com wrote:
Can I made Arithmetic.dll.so ? And link it against my linux App?
A library function runs in the context of the process that invokes it. A library doesn't have its own TEB/memory layout/exception handling that works independently of the process that calls it, no matter how it is compiled. If the wine plugin API is ever made, it will modify the process so it has what the library expects when the library functions are called.
Does your Arithmetic.dll.so call any Windows functions? If so, you need wine and you will always need wine, plugin API or no plugin API, whether you compile it into a DLL or .dll.so. But if you only use ANCI C stuff you can compile it into a .so and use it without wine.
If you want something that runs seamlessly on every operating system today, IMHO you should consider Java.
Yes, Java may be a good choice for crossing platform.
As you said, my Arithmetic.dll does not call any windows function. It's pure ANSI C library. What's the step of make .dll.so ??
Use winegcc or gcc ??
-- trulyliu@gmail.com
Damjan
On 8/21/07, trulyliu trulyliu@gmail.com wrote:
2007/8/21, Damjan Jovanovic damjan.jov@gmail.com:
On 8/21/07, trulyliu trulyliu@gmail.com wrote:
Can I made Arithmetic.dll.so ? And link it against my linux App?
A library function runs in the context of the process that invokes it. A library doesn't have its own TEB/memory layout/exception handling that works independently of the process that calls it, no matter how it is compiled. If the wine plugin API is ever made, it will modify the process so it has what the library expects when the library functions are called.
Does your Arithmetic.dll.so call any Windows functions? If so, you need wine and you will always need wine, plugin API or no plugin API, whether you compile it into a DLL or .dll.so. But if you only use ANCI C stuff you can compile it into a .so and use it without wine.
If you want something that runs seamlessly on every operating system today, IMHO you should consider Java.
Yes, Java may be a good choice for crossing platform.
As you said, my Arithmetic.dll does not call any windows function. It's pure ANSI C library. What's the step of make .dll.so ??
Use winegcc or gcc ??
Use gcc and make a .so like this: gcc -c arithmetic.c -fPIC gcc arithmetic.o -shared -o arithmetic.so
Then put it in /usr/lib and link to it like so: gcc -c application.c gcc application.o -o application -larithmetic
-- trulyliu@gmail.com
Damjan
-- trulyliu@gmail.com
Damjan