On 2024/07/18 12:41:22 Rainer Jung wrote: > Am 18.07.24 um 14:15 schrieb Michael Osipov: > > On 2024/07/17 15:33:02 Mark Thomas wrote: > >> All, > >> > >> I've spent some time today trying to build Tomcat Native with Visual > >> Studio 2022 rather then the current, more involved process without success. > >> > >> Therefore, my short-term plan for Tomcat Native is to get the next 2.0.x > >> and 1.3.x releases completed using the existing build process. I'll be > >> starting that shortly. > >> > >> Longer term, thinking about Tomcat Native and FFM I have the following > >> rough plan in mind: > >> > >> - stop providing x86 binaries for Windows > >> - require Windows 10 onwards > >> - provide: > >> - libssl.dll > >> - libcrypto.dll > >> - tomcat-native-2.dll > >> - openssl.exe > >> > >> along with appropriate debug symbols. > > > > This sounds reasonable...but did you rename tcnative on purpose? > > > >> I'm not sure if we'd need an apr.dll in there as well. > >> > >> The idea is that users can then use either the AprLifecycleListener or > >> OpenSSLLifecycleListener. > >> > >> This would probably require moving Tomcat Native to 2.1.x and 1.4.x > >> > >> This really needs someone more familiar with building C libraries > >> generally and these libraries in particular - i.e. Mladen - to say > >> whether the above is possible and to provide some pointers on how to do it. > > > > I would prefer that all APR-related stuff in the build is also removed in > > 2.1.x. Why does one need it if it is not used? That is weird. > > I'll try to clarify a few things: we have a few different cases where > native libraries are used. Please correct me where I am wrong: > > - the APR connector; only supported in TC 9.0. Implemented via tcnative > 1.3. Needs code from tcnative and the APR libraries. > > - doing OpenSSL crypto instead of JSSE crypto in a connector using > tcnative. supported in TC 9+; Implemented via tcnative 1.3 and 2.0. > Needs code from tcnative, the APR library and the OpenSSL library. The > APR library is needed, because tcnative uses the memory pool > implementation of APR for its own memory management. > > - doing OpenSSL crypto instead of JSSE crypto in a connector using the > new Java 22+ foreign function interface. Supported in TC 10.1+; > Implemented via FFM plus OpenSSL library. Only needs code from the > OpenSSL library. > > Concerning the existence of explicit separate libapr, libcrypto and > libssl dll files in the tcnative binary distribution for Windows: I > expect one can decide during copilation, which of these libraries will > be kept separate as dynmic library files and linked in dynamically and > which of them get linked in statically, so that no separate file needs > to be shipped. > > It seems until 2.0.7 (8?) and 1.3.0 (1?) we link in the apr, crypto and > ssl libs statically, so no separate dll files are shipped. > > Marks suggestion indicates that he suggests to link the two OpenSSL libs > dynamically and ship the crypto and ssl libs them bundled but keep the > apr lib linked statically, so no separate dll file for it.
Very decent explanation, all correct. I have totally forgotten that we use APR also for memory pools. APR would be an implementation detail (thus static). Makes sense to me. M --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
