Function assigned to variable causes linker errors m68k/gcc

[chris-y]

This follows on from my comment #15 (comment)_

Build target is m68k GCC.

In https://github.com/curl/curl/blob/ff7e5a29c781802ae5f37730e076df44a3936717/lib/vtls/openssl.c#L823 sk_X509_pop_free(ca, X509_free); causes the following linker error when the lib is used:

../lib/.libs/libcurl.a()(.text+0x58d6):: undefined reference to `_X509_free'
../lib/.libs/libcurl.a()(.text+0x59be):: undefined reference to `_X509_free'
../lib/.libs/libcurl.a()(.text+0x5bee):: undefined reference to `_X509_free'

Normal usage of X509_free() in the same file is fine, so I think this is an AmiSSL includes (inline?) issue with the X509_free function being used as a parameter.

There appears to be a related issue with the MD5 functions where they are assigned to a variable before being used and this is also causing the same linker errors.

[chris-y]

My workaround is to create a C function of a different name which mirrors and calls the AmiSSL function.

[Futaura]

I think you'll face this issue on all targets, even OS4. You can't assign library functions to a pointer - there is the added complication of the library/interface needing to be passed as a parameter in A6/r2.

Take a look at amissl/src/libstubs.c - sounds like you've already done something similar. IIRC, on m68k in the old days you could choose not to use the inline macros, and instead build a stub llink ibrary which contains all library calls without the A6 library base parameter, which then call the real library using a globally defined library base. I think there are tools to create such libraries (fd2pragma). Although, for AmiSSL it may be a bit too much overhead - better to create stubs for the functions you need if there are only a few.

[ksdhans]

On OS4, this could be resolved by the change suggested in #31.

[Futaura]

Stub link library now supplied with AmiSSL v5