Before I get onto my questions I would just like to say:
This mail is not intended to start a flame war ----------------------------------------------
It is intended in a spirit of understanding what is the current status.
First the quick question - I want to install a built-from-CVS wine on multiple Fedora Core 1 machines. I can't find a spec file anywhere to make an RPM with - should I just pinch one from a FC1 Wine package, or is anyone maintaining a set of package-build scripts (RPM, dpkg, etc.)?
Now the more complicated and possibly flame-inducing question. While looking round the source tree for a spec file I noticed that all the WINE DLLs seem to end up as .dll.so files. I assume this is because the native platform's gcc can't build a real DLL, so it is wrapped up as a .so and wine (the binary) loads them as such and them does a connect-the-dots exercise to make it look to the application as if it loaded a real DLL.
My understanding is that a cross-compiled gcc would build real DLLs, and as wine is able to load them when given them, would there be any advantage to building them with a cross-compiling toolchain if one were available. I am thinking here of perhaps some kind of loading speed improvement (unlikely to be significant if any) or maybe some perverse custom installer that looks for specifically named files in specific places on the filesystem it sees.
If there is no advantage, could the converse be true - that there would be some benefit to wrapping native DLLs in a .so shell for speed improvement - perhaps analysing the DLL on load is very hard work and if this were done once and the result saved as a .so .....
Peter
Hello Peter,
As far as I understand .so are linux native shared libraries.
That means you can access linux native APIs from within the shared library. This is how wine works, it implements the windows API in .so files by using other (non wine) native shared libraries (example is the Xfree86 libraries to display certain windows stuff).
A .dll is a Windows (native) DLL, you need a specific loader (in wine) to load this dll into memory.
I'm not sure, but I don't think you can access native linux shared libraries from with a native windows dll.
Peter Riocreux wrote:
Before I get onto my questions I would just like to say:
This mail is not intended to start a flame war
It is intended in a spirit of understanding what is the current status.
First the quick question - I want to install a built-from-CVS wine on multiple Fedora Core 1 machines. I can't find a spec file anywhere to make an RPM with - should I just pinch one from a FC1 Wine package, or is anyone maintaining a set of package-build scripts (RPM, dpkg, etc.)?
Now the more complicated and possibly flame-inducing question. While looking round the source tree for a spec file I noticed that all the WINE DLLs seem to end up as .dll.so files. I assume this is because the native platform's gcc can't build a real DLL, so it is wrapped up as a .so and wine (the binary) loads them as such and them does a connect-the-dots exercise to make it look to the application as if it loaded a real DLL.
My understanding is that a cross-compiled gcc would build real DLLs, and as wine is able to load them when given them, would there be any advantage to building them with a cross-compiling toolchain if one were available. I am thinking here of perhaps some kind of loading speed improvement (unlikely to be significant if any) or maybe some perverse custom installer that looks for specifically named files in specific places on the filesystem it sees.
If there is no advantage, could the converse be true - that there would be some benefit to wrapping native DLLs in a .so shell for speed improvement - perhaps analysing the DLL on load is very hard work and if this were done once and the result saved as a .so .....
Le ven 23/07/2004 à 08:36, Peter Riocreux a écrit :
Before I get onto my questions I would just like to say:
This mail is not intended to start a flame war
It is intended in a spirit of understanding what is the current status.
First the quick question - I want to install a built-from-CVS wine on multiple Fedora Core 1 machines. I can't find a spec file anywhere to make an RPM with - should I just pinch one from a FC1 Wine package, or is anyone maintaining a set of package-build scripts (RPM, dpkg, etc.)?
Use the .spec from the fc1 source package on sf.net. Note that there are some additional patches in that package, some of them harmless if removed (the kde2 menu part), some potentially more harmful (the nvidia part is because latest Nvidia opengl headers are a bit broken as is).
Now the more complicated and possibly flame-inducing question. While looking round the source tree for a spec file I noticed that all the WINE DLLs seem to end up as .dll.so files. I assume this is because the native platform's gcc can't build a real DLL, so it is wrapped up as a .so and wine (the binary) loads them as such and them does a connect-the-dots exercise to make it look to the application as if it loaded a real DLL.
It's not really wrapped in a .so, it is a .so (shared object) file. "file foo.dll.so" will tell you so. The wine loader knows how to handle those and the native dll files (.dll).
My understanding is that a cross-compiled gcc would build real DLLs, and as wine is able to load them when given them, would there be any advantage to building them with a cross-compiling toolchain if one were available. I am thinking here of perhaps some kind of loading speed improvement (unlikely to be significant if any) or maybe some perverse custom installer that looks for specifically named files in specific places on the filesystem it sees.
For the last part, we do have some soft links in the fake C: drive to handle some apps which look directly for a file.
For the cross-compiling part, my guess is that it'd be more difficult to link from a .dll (builtin) to a system .so, without jumping through some hoops along the way.
If there is no advantage, could the converse be true - that there would be some benefit to wrapping native DLLs in a .so shell for speed improvement - perhaps analysing the DLL on load is very hard work and if this were done once and the result saved as a .so .....
Vincent
-
Jeroen Janssen -
Peter Riocreux -
Vincent Béron