Closed patrikaxelsson closed 2 years ago
You mention "normal" a lot - unfortunately OpenSSL is not normal!
The helper functions are defined that way in OpenSSL, as static inline functions. Macros could in theory be used instead, but then you'd lose all the type checking and tracing, which would make debugging difficult. Unfortunately, VBCC does not have an "inline" keyword for forcing functions to be inlined, unlike GCC (and SAS/C incidentally), so I guess -O3 is your only option there.
As these inline functions simply call OpenSSL functions, AmiSSLBase has to be a global variable - I don't see a way around that.
One alternative to inline functions would be to create a link library instead, but still this approach would require AmiSSLBase to be a global variable too, if those functions are used.
BTW, I guess you could try the following, if you do not need those helper functions:
#define AMISSL_INLINE_H
#include <proto/amissl.h>
Everything in amissl/inline.h
is actually a copy of the corresponding code from openssl/safestack.h
and openssl/lhash.h
, so that's where those inline functions originate in OpenSSL.
Thank you very much - when AMISSL_INLINE_H is defined, none of the issues mentioned above appear when including proto/amissl.h:
$ make EmptyAmiSSLTest EmptyAmiSSLTest_O3 LocalBaseAmiSSLTest
vc +aos68k -nostdlib -c99 -O2 -lvc -DAMISSL_INLINE_H -IAmiSSL/Developer/include -o EmptyAmiSSLTest EmptyAmiSSLTest.c
vc +aos68k -nostdlib -c99 -O3 -lvc -DAMISSL_INLINE_H -IAmiSSL/Developer/include -o EmptyAmiSSLTest_O3 EmptyAmiSSLTest.c
vc +aos68k -nostdlib -c99 -O2 -lvc -DAMISSL_INLINE_H -D__NOLIBBASE__ -IAmiSSL/Developer/include -o LocalBaseAmiSSLTest LocalBaseAmiSSLTest.c
$ ls -la EmptyAmiSSLTest EmptyAmiSSLTest_O3 LocalBaseAmiSSLTest
-rwxr-xr-x 1 patrik access_bpf 56 4 Sep 00:19 EmptyAmiSSLTest*
-rwxr-xr-x 1 patrik access_bpf 56 4 Sep 00:19 EmptyAmiSSLTest_O3*
-rwxr-xr-x 1 patrik access_bpf 40 4 Sep 00:19 LocalBaseAmiSSLTest*
The https.c example included in AmiSSL builds with AMISSL_INLINE_H defined (and works), so I guess it is still functional enough for common use without those helper functions?
Sure. You'd get a linker error anyway if the code you are compiling actually needs those functions. IBrowse needs them for user certificate handling, for example, but for basic HTTPS they are not required.
Would it perhaps be sensible to make amissl/inline.h an opt-in include instead, as it is not needed in the general case and it gives these side-effects?
Apart from the unexpected behavior, the build time and memory consumption makes it impossible or very impractical to build on a real Amiga.
@patrikaxelsson I don't think so. I think we need to leave the maximum OpenSSL compatibility enabled by default.
I can compile IBrowse perfectly fine for OS3 with SAS/C on my A1200 and for OS4 with GCC on my A1XE, without needing to disable these headers (in fact, IBrowse needs some of those functions). AmiSSL itself is even buildable on my A1XE.
I shall keep this in mind with OpenSSL 3.0 though, which I am currently trying to port - at first glance, it seems they've made the safestack/lhash inline stuff even more complicated, but we shall see.
AMISSL_INLINE_H worked great as a workaround for this issue in 4.x, closing.
By just including proto/amissl.h, the resulting binary will increase 40kBytes+, unless at least -O3 is used:
This is not normal when using libraries with vbcc or any compiler on/for the Amiga. Also, apart from building very slowly when proto/amissl.h is included, I noticed that it consumes a lot of memory to build this nop-exe - a 16MB Amiga was not enough.
If a local instead of global AmiSSLBase is used (together with -DNOLIBBASE or not), it will not compile or link:
Also not normal and I think this has something to do with the first issue.
AmiSSLTest.zip