Thanks for testing this Logan! We probably have to clear some more disk space on the runner, this is a problem we have had before, they keep adding things to the image.
A 5x increase seems a bit much to integrate into the normal builds, so Kou's approach is probably best? Am Mi., 12. März 2025 um 05:48 Uhr schrieb Logan Riggs <logan.ri...@dremio.com.invalid>: > > 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 > >
