Fix exported symbols

[SpaceIm]

closes #217

[MaxKellermann]

Are these symbols really meant to be exported? They look like internal functions that are not supposed to be used by applications. Of course, they shouldn't be in the public headers.

[SpaceIm]

Maybe these headers should be private, but it's worth noting that jpeg2000 driver in GDAL assumes that several of these functions are part of Jasper API: https://github.com/OSGeo/gdal/blob/f87673d2ac225e117fd6f6d5b32443cab1c7460b/gdal/frmts/jpeg2000/jpeg2000dataset.cpp#L1196
This is why I've proposed this PR.

[mdadams]

Are these symbols really meant to be exported? They look like internal functions that are not supposed to be used by applications. Of course, they shouldn't be in the public headers.

It might be possible to make the main entry points for the individual codecs private (i.e., not exported by the library). I suspect that this would break things for a number of projects, however. I don't think it would be a good idea to simply make these interfaces private without someone warning the users of the library. If one really wanted to make these functions private, it would be best to mark them as deprecated and then only much later make them private (i.e., stop exporting them).

[MaxKellermann]

It might be possible to make the main entry points for the individual codecs private

They are currently private, because they are not marked with dllexport! As such, they are not (and were never) usable on Windows.

This is about a mistake somebody made long ago, but we're not sure if...

• he forgot to add JAS_DLLEXPORT, or...
• he put private functions in a public header by mistake

On many other operating systems (including Linux), however, all symbols are exported by default. Even those which are not declared in any public header. This may be why nobody ever noticed the mistake. And it means that nobody has ever used JasPer on Windows (with an application requiring those symbols).

only much later make them private

This requires updating JasPer's SO version, breaking (binary) compatibility with all applications using JasPer, even those which never used those symbols. Because you must never change the ABI without changing the SO version.

[mdadams]

It might be possible to make the main entry points for the individual codecs private

They are currently private, because they are not marked with dllexport! As such, they are not (and were never) usable on Windows.

This is about a mistake somebody made long ago, but we're not sure if...

* he forgot to add `JAS_DLLEXPORT`, or...

* he put private functions in a public header by mistake

On many other operating systems (including Linux), however, all symbols are exported by default. Even those which are not declared in any public header. This may be why nobody ever noticed the mistake. And it means that nobody has ever used JasPer on Windows (with an application requiring those symbols).

only much later make them private

This requires updating JasPer's SO version, breaking (binary) compatibility with all applications using JasPer, even those which never used those symbols. Because you must never change the ABI without changing the SO version.

I'm sorry, but I meant private on Linux/Unix. As you noted, things are exported on Linux/Unix unless you explicitly say otherwise. So, on Linux/Unix (which is a very large number of users of JasPer), code could be relying on these (implicitly) exported symbols, right? This is the point that I was trying to make.

[jubalh]

This requires updating JasPer's SO version, breaking (binary) compatibility with all applications using JasPer, even those which never used those symbols. Because you must never change the ABI without changing the SO version.

Yep, I think this should be done only after a binary compatible release to the last version. A release that mainly fixes the CVEs and other cleanup Max and I did.

[MaxKellermann]

I merged this now (and fixed the conflicts), because my interpretation of @mdadams's reply is that applications may rely on these symbols and they should be exported.

Many symbols declared in the public headers should never have been declared publically, however. And we should minimize the public API/ABI in the next major release. Exposing so much of JasPer's internals makes it hard to improve JasPer.