I think that our default configure and make rules should be tailored towards
developers
deliberately building Qt from source, so IMHO it should not strip by default.
When you build
Qt from source I'm not sure you care about the binary size (you're installing
on your local
drive) and you might appreciate getting some useful backtraces when they happen.
I think in automake this is usually solved by make install _not_ stripping and
then there being also
a "make install-strip" target that installs and strips.
Quote from the automake manual:
"
make install
Install what needs to be installed, copying the files from the package's
tree to system-wide directories.
make install-strip
Same as make install, then strip debugging symbols. Some users like to
trade space for useful bug reports...
"
Just my two øre :)
Simon
________________________________________
From: [email protected]
[[email protected]] on behalf of ext
Thiago Macieira [[email protected]]
Sent: Thursday, September 13, 2012 22:21
To: [email protected]; [email protected]
Subject: [Development] Not stripping our binaries by default
I was trying to make Qt 5 packages for Tizen when I realised that the
automated build scripts that generate debuginfo packages were failing, saying
that our libraries are already stripped.
Turns out that qmake generates "strip --strip-unneeded" commands when in
release mode. There's a way to turn it off by passing an extra CONFIG to qmake,
but that is not accessible from the configure command-line.
Either way, stripping by default sounds wrong to me. Distributions already
have their own tools to strip. So I'm proposing that we stop doing that. See
https://codereview.qt-project.org/34835
For our own SDK, we might need to add the stripping at the appropriate
place(s).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
