[PATCH] fdo#39643: Remove --disable-strip-solver configure option

David Ostrovsky david.ostrovsky at gmx.de
Wed Apr 25 23:07:02 PDT 2012

Hello Petr,

thank you for your review and your comments.
Here is a new version with these issues fixed:

1. no strip in solenv/bin/deliver.pl any more
2. solenv/bin/modules/installer preserves striping code
3. there is a new target install-strip that do strip during installation 

Question: i can not see where $strip var in ooinstall is parsed (in 
make_installer.pl call)?

if ($ENV{BUILD_TYPE} =~ m/ODK/) {
     print "Running SDK installer\n";
     system ("cd $ENV{SRC_ROOT}/instsetoo_native/util ; " .
     "perl -w $ENV{SOLARENV}/bin/make_installer.pl " .
     "-f openoffice.lst -l en-US -p LibreOffice_SDK " .
     "-u $tmp_dir " .
     "-buildid $BUILD $destdir $strip $msi " .
     "-simple $path") && die "Failed to install: $!";

For the new param in Makefile ooinstall -strip to be passed to
make_installer.pl I have to parse it myself in ooinstall, right?


On 25.04.2012 16:56, Petr Mladek wrote:
> d.ostrovsky at idaia.de  píše v Út 24. 04. 2012 v 11:33 +0200:
>> Do we agree about to drop the striping code from ooinstaller?
> What do you mean by ooinstaller? Just the single ooinstall script or
> also also the solenv/bin/modules/installer/* stuff?
> It is hard to say until we know what is the benefit of stripping. If it
> makes sense, you need to keep the support for "make install-strip". It
> will call ooinstall as well.
>> As far as I can see the use cases we have are:
>> Use Case (UC) 1: distro maintainer would build without -g, nothing to
>> be stripped.
> This is not true. Many distro maintainers actually build with -g. They
> later use some magic to put the debug information into separate
> packages.
>> UC 2: developer with change, compile, test cycle would build with -g
>> and install LO with make install oder make dev-install. He wants
>> definitely preserve the symbols.
> yup
>> UC 3: developer compiles it with symbols and want provide the build
>> artifacts to somebody to test.
>> It could be the only justification to provide a new make target
>> "strip-and-install". But the tests with stripped
>> artifacts are useless, no deeper analysis is possible.
> Developer might have the symbols to track the code in debugger to
> understand how it works. A backtrace from user is useful only for
> crashes or some other particular problems. It is not useful to check
> that a functionality works as expected. If you have full debug build,
> the stripped binaries can safe a lot for download.
> When I think about it, we want to keep stripping capability in the
> installer stuff for this purpose. Though, we want to disable it in the
> default "make install".
>>   Another
>> argument for not to strip even in this case is a new configure option
>> that was introduced in the last hackfest to selectively specify the
>> list of libraries to build with symbols. With this option not the
>> whole LO but only a couple of libs would be built with symbols.
> Yes, it might be better but I still think that strip might safe a lot
> here on download.
> Please, wait a bit. I am trying to build without -g and without
> stripping to get some data. I am going crazy today because the binaries
> are stripped in solver even when I use --disable-strip-solver. Sigh.
> Best Regards,
> Petr
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

More information about the LibreOffice mailing list