RFC: Adding Mac support to secur32/schannel.c
jjmckenzie51 at earthlink.net
Thu Feb 3 13:56:22 CST 2011
Charles Davis <cdavis at mymail.mines.edu> wrote:
>On 2/3/11 9:22 AM, James Mckenzie wrote:
>> 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get around some of the code issues. Both of the
>>known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to build and work on MacOSX without stepping on
>>the existing capabilities.
>What are you talking about? MacPorts doesn't need patches for GnuTLS anymore. Looking at GnuTLS's Portfile, there are no
>patch files pulled in and no reinplace (i.e. sed -ie) operations.
It was my understanding that MacPorts did have them. I'll look at Fink tonight and see if there still is a patch file needed with the latest version. In any case, Mac users should be using build in functionality and as few as possible (none if possible) external 'Unix' add-on packages. For a while, they will be needed.
>> I tend to agree with Ken Thomases for MacOSX we should be using the native code vice adding a package that may not provide full TLS functionality and moving towards schannel functionality to the higher levels of code in Wine.
>I'm for that. In fact, my humble opinion is that Wine on Mac should only use libraries that are part of the OS (i.e. only
>dylibs in /usr/lib and frameworks in /System/Library/Frameworks). There are a whole host of benefits, not the least of
>which is that it makes binary distribution easier (to date, Mac OS is one of the few platforms that does not have
>an official binary distribution) and it could potentially expand our user-base (since users would no longer have to have
>MacPorts or Fink or Gentoo Prefix or use a third-party distro just to run Wine).
+1 :) It would be a great thing if we did not have to have 'special' builds for MacOSX and we could send out either an installable package or a disk image as the project.
>We've got a long way to go in that department, unfortunately. :(
More information about the wine-devel