On Mon, December 10, 2012 09:20, Ludo Brands wrote: > On 09/12/2012 22:48, Tomas Hajny wrote: >>> Add a sslcheck after it to see what the error is. >> SSLCheck doesn't help because ErrGetError again returns 0. :-( > You could comment out the lines in THTTPSend.InternalDoConnect that set > FSock.SSL.SNIHost but I think this is just a red herring.
Will do and let you know. I assume you mean commenting it out temporarily for the debug purposes only, right? >>> I'm a little out of ideas also. There is not a problem with calling >>> convention? >> That also came to my mind, but cdecl is the standard calling >> convention used for all 32-bit libraries coming from the "C world" >> (this makes it a bit easier compared to Win32 with its stdcall versus >> cdecl). I have noticed that the OpenSSL imports are all declared as >> cdecl (even under Win32), i.e. this should be OK. >> > This quote from > http://www.mail-archive.com/openssl-dev@openssl.org/msg10947.html is > interesting since apparently you are using the EMX dll: > "True, the DLLs will only work properly with EMX gcc compiled apps (though > I > believe other compilers will work if you avoid stdio & sockets and can > arrange matching the calling convention) but the primary target of this > patch is people porting unix apps to OS/2 & that's usually done using EMX > gcc." > The "avoid sockets" is important. Apparently the EMX and IBM C-runtime > libs conflict. This is indeed interesting. We use neither EMX nor IBM C (nor Watcom, etc.) runtime libs in FPC. The OpenSSL DLL binaries indeed use the EMX libc (or newer GCC LIBC - depending on the particular binary / compiler used for generating it). > ssl_openssl_lib also uses BaseUnix which loads libc if FPC_USE_LIBC is > defined. Don't know if that is the case for OS/2. Is there a way to > force the use of the EMX C runtime from pascal? If you mean something comparable to FPC_USE_LIBC, then no, this is not supported (and it wouldn't make much sense - you don't do something like that on Win32 either). >> Most of the calls seem to succeed as far as I can see (they return >> either 1, or some pointer, or non-zero length of generated certificate >> string). The trouble comes with SSLAccept returning -1 (again :-( ) >> without providing any other information (the same symptoms as with >> SSLConnect). The socket is clearly created and listening on the >> defined port before that. That probably suggests that we are as far as >> we were before. > Indeed. Looked into the openssl source code and the rare cases where > SSL_connect or SSL_accept return -1 without setting an error are linked > to low level calls such as allocating memory or writing to a fd. Memory > allocation does work otherwise you wouldn't get anywhere in the > CreateSelfSignedCert routine. > > The test you did before substituting the winsock send with bsd send > which succeeded is using the same c runtime library for both sends. The > possibility of conflicting c runtimes still holds with that test. There should be no C runtime involved when accessing the standard OS/2 API (which includes both the native BSD sockets and the Winsock compatibility layer). Whatever is done when using EMX libc, it must still go through this OS/2 API in the end. However, I understand that there may be some socket initialization involved on the EMX libc side (this indeed seems to be the case as suggested by peeking into http://svn.netlabs.org/repos/libc/branches/libc-0.6/src/emx/src/os2/tcpip.c - really bad, all this ugly world of mixing file and socket handles together on a platform having these concepts completely separated :-( ). I'll see what I could do (probably start by extending the previous test to import the "send" call from EMX libc). It would be the best to just allocate the fake "file" handle expected by EMX libc to the existing socket number if necessary (i.e. if OpenSSL is involved), but I'm afraid that the respective EMX libc function (tcpip_new_handle) may not be exported / accessible externally. Too bad. :-( >> Thanks for all your thoughts so far (and obviously also those >> possibly coming in the future). I'm afraid that the next step would >> be skipping the easy path and rewriting the OS/2 support to use the >> native BSD sockets (possibly in platform specific way rather than >> trying to re-use and just slightly modify the include file for Unix >> due to the additional dependencies involved), but that will probably >> require a lot of time / effort. :-( > Try forcing the use of the EMX C-runtime in FPC. If the library conflict > is the cause of the problem, using BSD sockets is not going to solve > anything if they use the IBM C run time. The OS/2 implementation of BSD sockets should not use any C run time itself, but I could try importing the EMX libc versions of send, recv, accept, bind, select, etc., in the worst case. _Very_ ugly for a Pascal program on a platform not providing any libc as part of its official API at all (i.e. much worse than with Linux where libc may not be necessary for some tasks, but at least it is always included and accessible - OS/2 also includes some libc for certain applications, but the official API doesn't depend on this libc and it is only used for some "user-land" tools and applications). Thanks anyway. Tomas ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ synalist-public mailing list synalist-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synalist-public
