Hi JB, Sounds useful to me. As the JNI libarrow binaries are build in arrow-java I don't see an issue with adding this.
Given that RelWithDebInfo has the same optimizations etc. as Release the main deciding factor to drop deb info is binary size. IIRC the java binaries are our largest artifacts anyway so maybe we can check what the deb info impact is and just switch the release builds to it instead of offering both? (Unless there are size sensitive applications of arrow-java?) Best Jacob Am Di., 11. März 2025 um 09:48 Uhr schrieb Jean-Baptiste Onofré <j...@nanthrax.net>: > > Hi folks, > > I discussed on Zulip with some of you about that, but I would like to > bring the discussion on the dev mailing list to get the whole > community involved. > > I propose to add DEBUG symbols to Arrow Java JNI and release/provide > the corresponding artifacts (with specific Maven classifier). > > Today, we don't provide JNI artifacts with DEBUG symbols, meaning > that, if a crash occurs (for any reason), the user is kind of blind to > find the causes. > > The proposal is to provide new artifacts with debug Maven classifier > for instance built with DEBUG symbols (the existing/current artifacts > are still there, nothing changes here). > > We can ship RelWithDebInfo builds instead of Release builds (deb/RPM > split debug symbols to separated files and package them as separated > packages for instance). > We can mimic this for JNI (adding a new CI/tool). > > Thoughts ? > > Thanks ! > Regards > JB
