when I run ./configure --enable-debug on FreeBSD it doesn't use the -g flag for gcc:
CFLAGS: -Wall -Wno-unused -DDEBUG
CXX: /usr/bin/c++
CXXFLAGS: -Wall -Wno-unused -DDEBUG
CPP: /usr/bin/c++
It works fine on Linux and Mac OS X:
CFLAGS: -Wall -Wno-unused -DDEBUG -g
CXX: /usr/bin/c++
CXXFLAGS: -Wall -Wno-unused -DDEBUG -g
CPP: /usr/bin/c++
Both my Mac OS and the Free BSD have gcc 4.2.1 and cmake 2.8.4. Any ideas what's wrong?
(and BTW, just wondering whether -O0 should be added as well (I know it's the default))
I guess that's to for making port builds work better but it obviously breaks other source builds. Somebody more involved / knowledgeable about ports might want to flag that with the port maintainer...
This change is from Apr 2011 so eventually it will be a problem we'll be facing on all FreeBSD systems. So we might have to work around it. Grrrr.
(If you're desperate, a temporary workaround would be: `CFLAGS=-g CXXFLAGS=-g ./configure --enable-debug`)
I guess that's to for making port builds work better but it obviously breaks other source builds. Somebody more involved / knowledgeable about ports might want to flag that with the port maintainer...
This change is from Apr 2011 so eventually it will be a problem we'll be facing on all FreeBSD systems. So we might have to work around it. Grrrr.
I'd like to keep Bro's use of use of CMAKE_BUILD_TYPE profiles to automatically determine the right flags for the job based on the compiler being used. Adding a hack, exclusive to FreeBSD, to set default compiler flags isn't great since this isn't a general platform problem, just a problem with the port of CMake.
I think I understand why they did it -- it makes it easier for port maintainers to arrest full control of compile flags without patching upstream sources of projects that use build profiles. But that approach doesn't seem to play nice when users are trying to build software outside the port system. Taking the issue up with the CMake port maintainer might be best for now.
FreeBSD can be a pain in this regard. For the autotools, they used to
have their own version for the ports, which however didn't work well
for external software. As a work-around they offered an additional
port gnu-autotools that would install an unmodified version into
/usr/local/gnu/bin/ ... Sigh.
This seems to be along the same lines: optimizing for the ports, but
not considering external software using the same tools.
That said, I think it would be good for us to work around this. While
it's easy to fix once one knows what's going on, it's of these little
things that will be annoying every single time; and everybody on
recent FreeBSD will have that problem.
Can we just generally add a "-g" to debug builds if it's not there yet
(or even if it may be, if we can't check easily?). Seem there's not
much harm to that?
Can we just generally add a "-g" to debug builds if it's not there yet
(or even if it may be, if we can't check easily?). Seem there's not
much harm to that?
Ok. I'm imagining that a Bro port might have to workaround my workaround. But I guess that would be fine since we'd be back where we started before the CMake port did their workaround.