Please don't export private symbols

[wRAR]

It seems there are a lot of symbols which are private and not a part of the public ABI that are exported. Those include _hashtable_*, blake2b_ (when the bundled b2 is used), and probably some of rs_* functions (at least some of rs_* functions were exported in 1.0.0 but are not exported anymore because they were made static but SONAME was not changed so I assume they were private from the beginning).
Setting all symbols as hidden and only explictitly marking public ones as visible helps maintaining ABI correctly and understanding when the SONAME must be bumped.

[dbaarda]

The intention has always been "if it's not in librsync.h, it's not public". I realize that this doesn't really hide them from the linker, and the TODO.md includes "Rename all symbols that are intended to be private to rs__" as a way to try and avoid name collisions when librsync is linked into other projects.

I'm not entirely sure how to make them properly private. The problem is the implementation is spread out over multiple *.c files that need to call these "private" functions in each other. For example, the state machine driver is implemented in job.c, but the state functions for each operation type are defined in their own delta.c/mksum.c/etc files. Some of these *.c files are stand-alone reusable components (like hashtable or rollsum) or come from upstream sources (like blake2). We'd have to extensively patch upstream sources with "static"s all over the place and then they couldn't call each other over the *.c file module boundaries.

The only way I can think to hide these is to either merge them all into one monolithic *.c file, or do the equivalent and have a main librsync.c file that #includes all the *.c files. Is there some other standard way to do this in C that I'm unaware of? Is there some best-practice code structure we could adopt to fix this?

We can probably improve things without major restructuring by just doing the TODO renaming and making sure everything that can be is marked static. Other than that, I'm open to suggestions.

[wRAR]

https://gcc.gnu.org/wiki/Visibility

[dbaarda]

That's C++, not C. It also looks terrifyingly compiler dependent.

[wRAR]

It's not C++- specific, and other compilers have other ways to do that (like __declspec(dllexport) for MSVC).

[michihenning]

https://stackoverflow.com/questions/19418908/creating-a-portable-library-to-run-on-both-linux-and-windows

The #defines suggested in some of the answer there are widely used.

[dbaarda]

I had a bit of a read, and IMHO if we are going to do this right, using the CMake support for it would be the best approach to address the compiler/platform differences;

https://cmake.org/cmake/help/v3.0/module/GenerateExportHeader.html

I would still like to avoid any significant changes to upstream sources like blake2, so I would prefer not to have to annotate it with special LIBRSYNC_NO_EXPORT macro's everywhere. However, perhaps there is a way to make it not export by default so we only have to add LIBRSYNC_EXPORT to the public bits of librsync?

I think its still also worth doing a cleanup pass first to tag everything possible as "static", perhaps doing some re-arrangements to enable more of that, and make sure that everything is consistently named with rs_* prefixes.

[wRAR]

I suppose set(CMAKE_CXX_VISIBILITY_PRESET hidden) (from the GenerateExportHeader docs) does precisely "make it not export by default" (i.e. -fvisibility=hidden).

[dbaarda]

wRAR: I see that v2.0.2 has made it into Debian testing, and I'm pleased to see how many other packages are already using/depending on it. Thank you very much for all your work there.

Can you have a quick look at #156 and comment from a Debian packaging point of view to make sure this doesn't cause any headaches for you? I'm keen to release v2.0.3 with this included to address this and the memory leak bug that have been fixed since v2.0.2 was released.