[PATCH] winegcc - do not create .exe.so
shacklein at gmail.com
Mon Mar 21 00:00:44 CDT 2011
On 21 March 2011 15:47, Charles Davis <cdavis at mymail.mines.edu> wrote:
> On 3/20/11 10:28 PM, Ben Klein wrote:
>> On 21 March 2011 15:10, Charles Davis <cdavis at mymail.mines.edu> wrote:
>>> On 3/20/11 9:31 PM, Ben Klein wrote:
>>>> On 21 March 2011 12:26, Charles Davis <cdavis at mymail.mines.edu> wrote:
>>>>> 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.
>>>> Does this also mean it will fail to work on amd64/ia64 systems?
>>> For 32-bit (x86) code running on an x86-64/IA64 system, it will work.
>>> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels
>>> keep the old int 80h interface around solely for the benefit of old
>>> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and
>>> AJ fixed it) that expect it to be there.
>>> In fact, even if 64-bit code supported the int 80h interface, it still
>>> wouldn't work, because even across different architectures on Linux, the
>>> syscall numbers are different.
>> Thanks for explaining it.
>> Something else I noticed in this patch though; what happens to the
>> environment variables handled by the loader script?
> Nothing. He even hard-coded the path to the 'wine' binary (as a series
> of DWORDs, no less!).
I suspected that's what was going on. Basically, this patch makes
absolutely no logical sense at all.
More information about the wine-devel