[PATCH] winegcc - do not create .exe.so

[Charles Davis]

On 3/20/11 6:54 PM, Chris Robinson wrote:
> On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote:
>> On 03/20/2011 05:14 AM, Pali Rohár wrote:
>>> Can anybody review my patch?
>>
>> Not sure what you trying to do exactly. Wine already has wrapper that makes
>> all wine binaries executable after they are being installed into system.
> 
> Wine installs wrapper scripts which call wine with the appropriate .exe.so 
> DSO. The .exe.so file can't be run directly.
> 
> As far as I can tell, the patch makes it so the .exe.so file can be run 
> directly, by adding a _start section that automatically execs wine with all 
> the same arguments passed on the command line. As a result, it removes the .so 
> extension so you can, for example, just run the 'winecfg.exe' executable 
> itself, with no 'winecfg' wrapper script needed.
It's not enough to have a 'start' symbol. The binary has to be of the
right type, too. On Mac OS, for example, the binary has to be of the
MH_EXECUTE type (instead of MH_BUNDLE, which it would be right now), or
you won't be able to execve(2) it. With ELF, the binary type has to be
ET_EXEC (instead of ET_DYN).

Also, I don't know if Mac OS, Linux, or any other platform allows you to
dlopen(3) something that isn't a DSO (MH_DYLIB and MH_BUNDLE on Mac OS,
ET_DYN on ELF platforms). In that case, the right answer might just be
to leave this alone. Another solution might be to re-implement the Wine
loader logic in the executable itself, but I'm not sure if that's a good
idea.

Also, as near as I can tell, this will only work on x86 Linux. It won't
work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is
because the 'start' code invokes execve(2) using the interrupt 80h
interface. Even if other systems use int 80h for their syscall vector
(Mac OS does, at least for Unix syscalls), the syscall numbers usually
aren't the same across different platforms.

Chip