Remove antilib shared object because it's not really shared!

[AriaMoradi]

Original Issue:

I was browsing the file list of the built package. We are building all c++ stuff under libantilib.so.1 and linking libantilib.so to it.

That looks a little dumb. If it won't cause problems, we could name it libantimicro(x).so and no .1 file for more cleanness?

edit: numbers in the shared object name ending is for versioning the file and letting different programs link against different object versions. Since we are shipping the appropriate object with every version and we are the only program using it, it defeats the purpose.

And @gombosg said:

Libraries have to have soname fields. If we don't need it because it's not shared, then let's not ship a shared library.

So we should seek to completely remove it and statically link our code.

[pktiuk]

I also think so.

[gombosg]

This is because of Fedora packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning

Libraries have to have soname fields. If we don't need it because it's not shared, then let's not ship a shared library.

I'm fine with removing this separate library and just compiling it as part of the main executable. I'd rather write a PR for that solution when I get the time to do so.

[AriaMoradi]

This is because of Fedora packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning

This is not really a "shared" object. agreed.

I'm fine with removing this separate library and just compiling it as part of the main executable. I'd rather write a PR for that solution when I get the time to do so.

I'm going to try change my PR

[pktiuk]

Okay, but don't merge it instantly when it will be ready, I think it would be good to at least think what was their original purpose.

[gombosg]

We had that conversation here: juliagoda/antimicroX#118 (comment)