Hi,
Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&v...
Attached is a patch enabling the build:
- dlls/ntdll/directory.c: Define a character array on the heap of size 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This approach was used in dlls/ntdll/file.c:server_get_unix_name() where an array of size 1024 was defined. In case this solution is not OK, a fixed size array on the stack could be used, or as a last resort adding #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, at least from a GNU/Hurd aspect).
- libs/wine/ldt.c: Add LDT support for GNU/Hurd
- dlls/ntdll/signal_i386.c: Add i386 signal handling support for GNU/Hurd
Applications tested so far (slow to start) include cmd, hostname, clock, winemine, wineconsole, notepad, wordpad and explorer.
This patch is sent upstream on recommendation by the Debian Wine maintainers, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733605
Thanks!
Am 03.01.2014 12:32, schrieb Svante Signell:
Hi,
Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&v...
This winterbreak i looked into this again, too. I was quite suprised that i had no problems with socket credentials, but it might still be a problem in other hurd distros.
Attached is a patch enabling the build:
- dlls/ntdll/directory.c: Define a character array on the heap of size
4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This approach was used in dlls/ntdll/file.c:server_get_unix_name() where an array of size 1024 was defined. In case this solution is not OK, a fixed size array on the stack could be used, or as a last resort adding #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, at least from a GNU/Hurd aspect).
I recently sent a patch for this and failed, problem is that you can't allocate memory inside an APC callback. I think we should address this first before the other issues.
libs/wine/ldt.c: Add LDT support for GNU/Hurd
dlls/ntdll/signal_i386.c: Add i386 signal handling support for
GNU/Hurd
The interesting part of these patches were made by Andrew Nguyen some years ago, i already contacted him some days ago to ask how he wants to proceed with this, no response yet.
Applications tested so far (slow to start) include cmd, hostname, clock, winemine, wineconsole, notepad, wordpad and explorer.
These are winelib apps and a bad indicator for functionality. I tried PowerPointViewer here for this reason and it installs and runs.
Hi,
On Fri, 2014-01-03 at 15:35 +0100, André Hentschel wrote:
Am 03.01.2014 12:32, schrieb Svante Signell:
Hi,
Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&v...
This winterbreak i looked into this again, too. I was quite suprised that i had no problems with socket credentials, but it might still be a problem in other hurd distros.
The only credentials needed by wine is SCM_RIGHTS, and that is already supported. The problem was with *context functions and TLS. Since they are now supported, wine runs :)
Just FYI: There is no current Hurd distro except Debian. Arch Hurd exists, but is now outdated. Efforts are ongoing however, to re-vitalise it.
Attached is a patch enabling the build:
- dlls/ntdll/directory.c: Define a character array on the heap of size
4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This approach was used in dlls/ntdll/file.c:server_get_unix_name() where an array of size 1024 was defined. In case this solution is not OK, a fixed size array on the stack could be used, or as a last resort adding #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, at least from a GNU/Hurd aspect).
I recently sent a patch for this and failed, problem is that you can't allocate memory inside an APC callback. I think we should address this first before the other issues.
If not possible to use the heap, then the stack should be used: preferably a fixed size array of 4096 bytes (not PATH_MAX).
libs/wine/ldt.c: Add LDT support for GNU/Hurd
dlls/ntdll/signal_i386.c: Add i386 signal handling support for
GNU/Hurd
The interesting part of these patches were made by Andrew Nguyen some years ago, i already contacted him some days ago to ask how he wants to proceed with this, no response yet.
Yes I know, they should hopefully have been integrated upstream a long time ago.
Applications tested so far (slow to start) include cmd, hostname, clock, winemine, wineconsole, notepad, wordpad and explorer.
These are winelib apps and a bad indicator for functionality. I tried PowerPointViewer here for this reason and it installs and runs.
I did only try the functions available under .wine/drive_c, and did not find any PowerPointViewer application. Is that an M$ application?
Am 03.01.2014 16:49, schrieb Svante Signell:
Hi,
On Fri, 2014-01-03 at 15:35 +0100, André Hentschel wrote:
Am 03.01.2014 12:32, schrieb Svante Signell:
Hi,
Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&v...
This winterbreak i looked into this again, too. I was quite suprised that i had no problems with socket credentials, but it might still be a problem in other hurd distros.
The only credentials needed by wine is SCM_RIGHTS, and that is already supported. The problem was with *context functions and TLS. Since they are now supported, wine runs :)
Which *context functions do you mean?
Just FYI: There is no current Hurd distro except Debian. Arch Hurd exists, but is now outdated. Efforts are ongoing however, to re-vitalise it.
Attached is a patch enabling the build:
- dlls/ntdll/directory.c: Define a character array on the heap of size
4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This approach was used in dlls/ntdll/file.c:server_get_unix_name() where an array of size 1024 was defined. In case this solution is not OK, a fixed size array on the stack could be used, or as a last resort adding #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, at least from a GNU/Hurd aspect).
I recently sent a patch for this and failed, problem is that you can't allocate memory inside an APC callback. I think we should address this first before the other issues.
If not possible to use the heap, then the stack should be used: preferably a fixed size array of 4096 bytes (not PATH_MAX).
AJ didn't like that approach back then...
libs/wine/ldt.c: Add LDT support for GNU/Hurd
dlls/ntdll/signal_i386.c: Add i386 signal handling support for
GNU/Hurd
The interesting part of these patches were made by Andrew Nguyen some years ago, i already contacted him some days ago to ask how he wants to proceed with this, no response yet.
Yes I know, they should hopefully have been integrated upstream a long time ago.
Applications tested so far (slow to start) include cmd, hostname, clock, winemine, wineconsole, notepad, wordpad and explorer.
These are winelib apps and a bad indicator for functionality. I tried PowerPointViewer here for this reason and it installs and runs.
I did only try the functions available under .wine/drive_c, and did not find any PowerPointViewer application. Is that an M$ application?
It is, the challange is to run real PE files :)
On Fri, 2014-01-03 at 16:49 +0100, Svante Signell wrote:
Hi,
On Fri, 2014-01-03 at 15:35 +0100, André Hentschel wrote:
Am 03.01.2014 12:32, schrieb Svante Signell:
Hi,
Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see
...
This winterbreak i looked into this again, too. I was quite suprised that i had no problems with socket credentials, but it might still be a problem in other hurd distros.
The only credentials needed by wine is SCM_RIGHTS, and that is already supported.
I found the reason why wine runs now, it was solved by fixing the SCM_CREDS bug in: #724681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724681 resulting in an error: EKERN_INVALID_ADDRESS by returning code 1 from the sendmsg when file descriptor flags are non-zero (=1).
FYI for #733605: The upstream wine patches are at: https://source.winehq.org/patches/data/10143 and http://wiki.winehq.org/Hurd
On Mon, 2014-01-06 at 15:30 +0100, Svante Signell wrote:
On Fri, 2014-01-03 at 16:49 +0100, Svante Signell wrote:
Hi,
On Fri, 2014-01-03 at 15:35 +0100, André Hentschel wrote:
Am 03.01.2014 12:32, schrieb Svante Signell:
Hi,
Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see
...
This winterbreak i looked into this again, too. I was quite suprised that i had no problems with socket credentials, but it might still be a problem in other hurd distros.
The only credentials needed by wine is SCM_RIGHTS, and that is already supported.
I found the reason why wine runs now, it was solved by fixing the SCM_CREDS bug in:
SCM_RIGHTS!!
#724681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724681 resulting in an error: EKERN_INVALID_ADDRESS by returning code 1 from the sendmsg when file descriptor flags are non-zero (=1).
FYI for #733605: The upstream wine patches are at: https://source.winehq.org/patches/data/10143 and http://wiki.winehq.org/Hurd
On Fri, Jan 3, 2014 at 6:32 AM, Svante Signell wrote:
- dlls/ntdll/directory.c: Define a character array on the heap of size
4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This approach was used in dlls/ntdll/file.c:server_get_unix_name() where an array of size 1024 was defined. In case this solution is not OK, a fixed size array on the stack could be used, or as a last resort adding #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, at least from a GNU/Hurd aspect).
This version of the patch still hard-codes data_size. The Debian hurd porting guide requires paths to be dynamically allocated.
Best wishes, Mike
On Fri, 2014-01-03 at 10:18 -0500, Michael Gilbert wrote:
On Fri, Jan 3, 2014 at 6:32 AM, Svante Signell wrote:
- dlls/ntdll/directory.c: Define a character array on the heap of size
4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This approach was used in dlls/ntdll/file.c:server_get_unix_name() where an array of size 1024 was defined. In case this solution is not OK, a fixed size array on the stack could be used, or as a last resort adding #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, at least from a GNU/Hurd aspect).
This version of the patch still hard-codes data_size. The Debian hurd porting guide requires paths to be dynamically allocated.
From the reply by André Hentschel:
I recently sent a patch for this and failed, problem is that you can't allocate memory inside an APC callback. I think we should address this first before the other issues.
Additionally, the code mentioned in dlls/ntdll/file.c also use a hardcoded array size.
-
André Hentschel -
Michael Gilbert -
Svante Signell