Being somebody who actually digs into stack traces and core dumps, I
would be extremely leery about loosing the -g flag. When something goes
wrong, having the additional debugging information available is nice.
I think there's precedence for keeping it. Most of the Linux
distributions I believe build it in by default. For example, here's a
build log for Subversion on Ubuntu Dapper Drake:
http://www-devel.orcaware.com/packages/ubuntu/dapper/subversion/log-build-subversion-1.3.2-3zajac1.txt
Lots of -g's in there.
Disk is pretty cheap these days, so I say keep it in.
Regards,
Blair
Kevin Ballard wrote:
I'm still trying to figure out why everybody keeps suggesting to pass
-g. Even if autoconf does it by default (which I don't think it should),
that doesn't mean we should. As Daniel Luke demonstrated in the "Why -O
and -g in universal variants?" thread, debug information greatly
increases the size of the binary.
The other day, Elias Pipping asked me on IRC why his universal build of
gettext was half the size of the non-universal build, when it should be
the other way around. I pointed out that his non-universal build used -g.
I'm personally in favor of passing either -O or -Os when building
universal. I would also consider setting this as the default value for
CFLAGS to prevent autoconf from using -g by default, but I don't know if
there are any projects out there that would normally add other switches
that this would override, to a detrimental effect.
On Feb 26, 2007, at 7:34 AM, Vincent Lefevre wrote:
On 2007-02-26 07:14:31 -0500, Salvatore Domenick Desiano wrote:
I guess it's unclear to me as well why we wouldn't follow TN2137 by
default.
This would be a good idea, but other CFLAGS options may be needed
for some ports, in particular a different optimization option. So,
it is important that CFLAGS is built in a consistent order.
IMHO, to avoid problems, MacPorts should have a default CFLAGS value,
e.g. "-O -g" (as suggested by Apple). Then there should be a command
to append options to CFLAGS before calling configure, e.g.
configure.cflags-append. The universal variant should have
configure.cflags-append \
"-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
and the portfile could add other options if need be. Perhaps ditto
for LDFLAGS. This way, there shouldn't be any problem with overridden
CFLAGS/LDFLAGS.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
