libamisslstubs.a missing a few stubs about amissl

[Futaura]

Did you recompile libcurl? The parts that use OpenSSL must be recompiled with the new AmiSSL SDK, not just because of the above, but due to OpenSSL 3.0 ABI changes. IIRC, the functions above were renamed in OpenSSL 3.0 and are replaced by macros pointing to the new names in the OpenSSL headers, as you correctly say. Even if you make the stubs yourself, you are going to run into trouble if libcurl is not recompiled for OpenSSL 3.0.

[ksdhans]

No, I didn't. I've never been any good at porting *nix software, so I used the latest version from os4depot.net.

[ksdhans]

If the libs compiled for OpenSSL 1.1.1 can't be used with libamisslstubs.a, then adding stubs for the two functions listed above would be a waste of time. Those missing symbols will disappear when the libraries are recompiled for OpenSSL 3.

[Futaura]

Absolutely. The libs are compiled for OpenSSL 1.1.1, so it is unsafe to use AmiSSL v5 with them at all. You'll need to stick with the AmiSSL v4 SDK until libcurl.a gets updated. It is a shame that we don't have a curl.library already - it is something that I'd like to do, if I had the time! The API seems more stable and simple than what has to be covered with OpenSSL, so I would guess a much easier project than AmiSSL.

My original aim with AmiSSL v5 was to retain backwards compatibility and indeed IBrowse was using it one point, despite being compiled with AmiSSL v4. Ultimately though, OpenSSL public structure and API changes meant adding workarounds for backwards compatibility was becoming a bit of a nightmare and I couldn't be 100% sure of catching every single difference that would need patching, partly due to all the macro usage in the OpenSSL includes.

[ksdhans]

@Futaura
Do you know how to configure something like libcurl to use the bsdsocket.library's networking functions instead of the ones in newlib or clib2? AmiSSL uses bsdsocket.library directly for networking, and the socket file descriptors are incompatible with the ones in newlib/clib2.

[Futaura]

@ksdhans I've never needed to use libcurl before, so not really no. For AmiSSL, we do not use newlib or clib2 at all, and have our own cutdown c library which we link against - this is primarily to support access via multiple tasks, but also where the networking functions are implemented directly using bsdsocket.library. Something similar would be needed when building libcurl.a I guess.

I'm toying with the idea of making a curl.library - I built a quick example program at the weekend, linking with libcurl, just to find out what the global variable usage was like. Unlike OpenSSL, it is extremely light on global variables. so this makes it somewhat easier to turn into a library without having to rely on baserel stuff. ABI changes between versions breaking compatibility will be an issue though it seems, so might need to use a similar design to AmiSSL to allow multiple versions.

[ksdhans]

I've asked around, and there appears to be no way to bypass the newlib/clib2 networking headers and get it to use the bsdsocket.library's headers instead. The best they could do was __get_default_file() to extract the native descriptor, but that's only for clib2.

Unfortunately, there's no __get_default_file() equivalent for newlib. That's a shame, because otherwise a small modification to ossl_connect_step1() would probably have been enough to get libcurl working.

[Futaura]

Is this in the context of trying to recompile libcurl? If I understood the sources correctly, if compiling with the use AmiSSL option enabled, it will then include proto/bsdsocket.h. In which case the inlines, such as for socket(), map directly to bsdsocket.library and not clib2/newlib equivalents . Therefore, internally libcurl will use the native socket descriptor, which it will then pass to AmiSSL via SSL_set_fd().

[ksdhans]

I just checked, and I do indeed see proto/bsdsocket.h in curl_setup.h, which gets included if HAVE_PROTO_BSDSOCKET_H is set. I'll forward this to Michael, who is the one trying to get it built.

[ksdhans]

Digging through libcurl a bit more, I think the problem might be AmigaOS 4's library interfaces. I see no USE_INLINE anywhere, and without that bsdsocket.library's functions will need ISocket-> in front.

[Futaura]

Yes, that's probably it - it will need that defined somewhere. I think I was under the wrong impression the libcurl on os4dept already used AmiSSL, but I'm guessing that has to be linked with libssl and libcrypto instead, right?

[ksdhans]

Correct. The os4depot version has to be linked with libssl & libcrypto.

[Futaura]

@ksdhans I've been playing with building libcurl. It certainly isn't so simple as linking with -lamisslstubs and passing the underlying socket to SSL_set_fd to make it work with AmiSSL. I've been playing with the autoconfig stuff to make it work properly on OS4 and to make the --with-amissl option work correctly. I've made good progress and it ultimately now builds using bsdsocket.library and AmiSSL directly, and is working. I can see that the Amiga related code in the curl repository is for OS3 only, so I intend on making a PR to add the OS4 stuff so that things don't need to be hacked about after configuring and when compiling libcurl on OS4, hopefully making it easier to update/build. I can send you a build of libcurl.a if you're interested in testing it? (let me know if you need clib2 or newlib)

The one thing I'm trying to get my head around is the AmiSSL SDK version that libcurl.a is compiled with really needs to match
the AmiSSL SDK version that the application linking with libcurl.a and libamisslauto.a is linked with.

[ksdhans]

@Futaura That's great news. I'm using newlib, and would welcome a libcurl.a that has been built for AmiSSL 5.3. 5.3 is still the latest, right?

I look forward to your PR with the OS4 changes too.

[ksdhans]

Closing this, because the "missing stubs" aren't needed.