Recommend changing macros in inline4/amissl.h to inline stubs about amissl

[jens-maus]

@ksdhans Feel free to do so and submit a PR

[ksdhans]

Transferring a discussion to here from issue #35. I mentioned that I'm hoping to create an OpenSSL => AmiSSL stub library so that libcurl (and other static libs) could use AmiSSL instead of OpenSSL. In ZitaFTP's case, that would remove the redundant OpenSSL that's statically linked in because libcurl is used by its licensing code.

Having a stub library isn't quite the same as having inline stub functions in header files, but it is related.

[Futaura]

I'm not so sure changing the includes is the best solution - are you thinking something similar to idltool -b?.

You should be able to create a stub library by removing the LIB_ prefix in amissl.xml and using idltool -L amissl.xml. Then use something like the following Makefile in the main_stubs directory:

CC = gcc
CFLAGS = -O2 -fomit-frame-pointer

SRC := $(wildcard *.c)
OBJ := $(SRC:.c=.o)

%.o: %.c
   $(CC) $(CFLAGS) -c $< -o $@

all: libamisslstubs.a

libamisslstubs.a: $(OBJ)
   ar r $< $@ $(OBJ)
   ranlib $@

It might take a little while to compile all those stubs though.

[ksdhans]

I can't remember the idltool options, but yes, I think you can get it to generate static inline stubs. I personally think that should be the default, as its less invasive than using macros. They get inlined, so there's no performance penalty.

Would the stub library method you outlined create a stub lib for all the required libraries?

[Futaura]

@ksdhans Did anyone ever use a inline function stub instead of inline macros, I wonder. Looking at the file generated from idltool, the stub functions are not declared as inline, nor static. I'm not sure how clever GCC (4.0.4) is, but the header file would declare around nearly 5,000 functions, and maybe it will inline them automatically without the inline keyword, but if they are not declared static I would have thought that for every file you include the header file in, you'll end up getting 5,000 duplicate functions defined, which would cause problems. I guess I'll have to try it.

Yes, the stub library method would create a stub for every function - this way, only needed stubs would be brought in when linked. I guess you could use the inline function stub file instead and compile that into a .o file, but I presume all the stubs would be added when linked, unless GCC is clever enough to discard those unused.

[Futaura]

@ksdhans So, I've been experimenting a lot in this area recently. Firstly, idltool --linklib for creating stub link libraries was broken and secondly idltool --stubs was also broken because it created invalid functions when the return value is a function pointer. I've fixed both those, which allowed me to use both with AmiSSL v5. Also, I've fixed up sfdc because it too had trouble with function pointers.

Inline stubs looks like a largely useless option. If you include the inline4/amissl.h file in more than one source file, you end up with 6000 or so OpenSSL stubs in every .o file, and of course it then won't link due to multiple occurrences of the same functions. It also slows down compilation extremely heavily (no doubt due to the huge amount of OpenSSL stub functions) - I imagine this might also bring vbcc to its knees.

So, for AmiSSL v5, I intend to include a pre-built libamisslstubs.a, which can optionally be linked with applications. Applications can still be compiled with the regular inline4 macros, and then for OpenSSL functions that take an OpenSSL function as an argument, the stub will then be brought in for that when linking. I think this is going to be the best solution.

[ksdhans]

@Futaura
Thanks for the update. I never did get round to experimenting with it.