I did a quick test building with RelWithDebInfo. Unfortunately the arrow-java github runners ran out of space for the unix builds.
Instead I built locally and for Arm64 Linux the gandiva .so file is 573mb vs 94mb for a release build. On Tue, Mar 11, 2025 at 6:19 PM Sutou Kouhei <k...@clear-code.com> wrote: > Hi, > > It seems that deb (dh_strip) uses objcopy for this. > > See also the "--only-keep-debug" option section in > objcopy(1): > > https://man7.org/linux/man-pages/man1/objcopy.1.html > > > --only-keep-debug > > Strip a file, removing contents of any sections that would not > > be stripped by --strip-debug and leaving the debugging > > sections intact. In ELF files, this preserves all note > > sections in the output. > > > > Note - the section headers of the stripped sections are > > preserved, including their sizes, but the contents of the > > section are discarded. The section headers are preserved so > > that other tools can match up the debuginfo file with the real > > executable, even if that executable has been relocated to a > > different address space. > > > > The intention is that this option will be used in conjunction > > with --add-gnu-debuglink to create a two part executable. One > > a stripped binary which will occupy less space in RAM and in a > > distribution and the second a debugging information file which > > is only needed if debugging abilities are required. The > > suggested procedure to create these files is as follows: > > > > 1.<Link the executable as normal. Assuming that it is called> > > "foo" then... > > > > 1.<Run "objcopy --only-keep-debug foo foo.dbg" to> > > create a file containing the debugging info. > > > > 1.<Run "objcopy --strip-debug foo" to create a> > > stripped executable. > > > > 1.<Run "objcopy --add-gnu-debuglink=foo.dbg foo"> > > to add a link to the debugging info into the stripped > > executable. > > > > Note---the choice of ".dbg" as an extension for the debug info > > file is arbitrary. Also the "--only-keep-debug" step is > > optional. You could instead do this: > > > > 1.<Link the executable as normal.> > > 1.<Copy "foo" to "foo.full"> > > 1.<Run "objcopy --strip-debug foo"> > > 1.<Run "objcopy --add-gnu-debuglink=foo.full foo"> > > > > i.e., the file pointed to by the --add-gnu-debuglink can be > > the full executable. It does not have to be a file created by > > the --only-keep-debug switch. > > > > Note---this switch is only intended for use on fully linked > > files. It does not make sense to use it on object files where > > the debugging information may be incomplete. Besides the > > gnu_debuglink feature currently only supports the presence of > > one filename containing debugging information, not multiple > > filenames on a one-per-object-file basis. > > I'm not sure whether there is a similar tool for macOS or not... > > We can use .pdb on Windows. We can install .pdb something > like the following: > > ---- > diff --git a/cpp/cmake_modules/BuildUtils.cmake > b/cpp/cmake_modules/BuildUtils.cmake > index 90839cb446..0757e3cf81 100644 > --- a/cpp/cmake_modules/BuildUtils.cmake > +++ b/cpp/cmake_modules/BuildUtils.cmake > @@ -424,6 +424,11 @@ function(ADD_ARROW_LIB LIB_NAME) > RUNTIME DESTINATION ${INSTALL_RUNTIME_DIR} > INCLUDES > DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}) > + if(MSVC) > + install(FILES $<TARGET_PDB_FILE:${LIB_NAME}_shared> > + DESTINATION "${INSTALL_RUNTIME_DIR}" > + OPTIONAL) > + endif() > endif() > > if(BUILD_STATIC) > ---- > > > Thanks, > -- > kou > > In <CAB8EV3TYN=d-+guwjddnmjaqkokrtm6aa5mtpmv8zqqclrk...@mail.gmail.com> > "[DISCUSS] Arrow Java: add RelWithDebInfo builds support" on Tue, 11 Mar > 2025 09:47:07 +0100, > Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > > 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 >
