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. >> 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.
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? > 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. > 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. Ludo ------------------------------------------------------------------------------ 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
