Am 10.03.2020 um 10:04 schrieb Michael Osipov:
Chris,
Am 2020-03-09 um 22:22 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Michael,
On 3/9/20 10:20, Michael Osipov wrote:
Folks,
I have been recently reviewing some downstream changes in
tomcat-native. Can someone explain me why we install headers files
along with .pc file?
. ├── bin ├── include │ ├── ssl_private.h │ ├── tcn_api.h │
├── tcn_version.h │ └── tcn.h └── lib ├── libtcnative-1.a ├──
libtcnative-1.la ├── libtcnative-1.so -> libtcnative-1.so.0.2.23
├── libtcnative-1.so.0 -> libtcnative-1.so.0.2.23 ├──
libtcnative-1.so.0.2.23 └── pkgconfig └── tcnative-1.pc
Why is bin dir created although we don't install anything into
it?!
ssl_private.h shouldn't definitively be there. What about the rest?
Does it really make sense to install them at all? Can/Are there
(be) any C users who compile and link against libtcnative?
It seems strange, but yes, we do have downstream libtcnative users. I
have no idea why they are using our wrappers.
Occasionally, we get a bug report about some basically-never-used
function in libtcnative, like the File API [1].
you are confusing downstream Java users with C users. If you look
closely at those headers, they all define internal structs. There isn't
a single prototype for public functions, yet no JNIEXPORT. All export is
done in C code. None of these headers are intended to be used in an
external C program and being linked with -ltcnative-1. In fact, they
even require either OpenSSL and/or APR header files which breaks the
abstraction from both.
Maybe someone else with more C knowledge can look into, Rainer?
I'd open a ticket to drastically reduce the install target to the
libraries only.
Java users aren't affected at all because they load the dynamic library
and access all symbols marked with JNIEXPORT.
I agree that our installation set (make install) looks mostly like
unfinished work. I think we don't actually have a stable C API, so
indeed the provided header, pkgconfig and libtool la files are not worth
installing and might even be confusing for users who try "make install".
People who want to work on tcnative itself, need to use the source
distribution and all people only using it via JNI only need the library.
I think the state of "make install" mostly reflext an original bigger
plan for the library. Maybe Mladen has some more insight.
We should probably formally deprecate like 50% of libtcnative with an
eye toward throwing out all that code.
Even better, we should drop the APR connectors which would discard
even more code.
Even better than THAT, we should look at how to direct-call
OpenSSL/LibeSSL without having to use our own wrappers and completely
throw-away libtcnative entirely. I think this is "Project Panama" and
is something that evidently is actually arriving. Java 12 had some of
the initial work shipped with it, and Java 13 has continued that effort.
The only viable alternative I see at the moment is
https://github.com/wildfly-security/wildfly-openssl.
Panama is too early and consider that Tomcat 10 is still Java 8, so
unless Tomcat 11 isn't Java 17 this won't happen anytime soon.
Michael
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
