Building DLLs and other Qs

[Vincent Béron]

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