When I enable debugging informations in the build
options the following is executed when linking:
g++.exe -DDEBUG debug/wxtemplatefrm.o
debug/wxtemplateapp.o debug/wxTemplate_private.res -o
"debug\wxTemplate.exe" -L"C:/Dev/wx/lib/gcc_lib"
-mwindows -lwxmsw25d_core -lwxbase25d -lcomctl32
-lrpcrt4 -lwsock32 -lole32 -loleaut32 -lwinmm -luuid -g3
As you can see the DEBUG flag is given to the
linker which sometimes causes strange errors about
unresolved symbols.I can´t exactly figure out why (and
whether this is a MingW bug) but I´m sure that this
flag shouldn´t be given to the linker as it is for
compilation only.
Logged In: YES
user_id=609236
I'm not sure how this is a bug in dev-c++?
dev-c++ is just an ide over mingw, so it doesn't include any
own code during compilation - all the libraries and includes
are from mingw project. But you should get errors just by
including DEBUG - this is a problem with a library
you're using or your code.
Logged In: YES
user_id=392303
No it is not. This flag is actually a preprocessor
definition and has no sense in the linker call (as I said
above). Its misplaced there. It just confuses gcc so that it
spits out linker errors.If I compile without that flag Ill
get a correctly built executable with debug informations.
This is a gcc bug but its actually Dev-C++ which issues
invalid options to gcc.
Logged In: YES
user_id=609236
with -DDEBUG is just a define you can use in your code
it's not a gcc option. what exectly do you mean by invalid
options?
Logged In: NO
The DEBUG flag is added into the makefile automatically
by Dev-C++ if I specify "generate debug info". I DON`T have
that option set in my "additional command-line options".
The top of the generated makefile looks like this:
Project: wxTemplate
Makefile created by Dev-C++ 4.9.9.1
CPP = g++.exe -DDEBUG
CC = gcc.exe -DDEBUG
WINDRES = windres.exe
So everywhere the c++ compiler is invoked this flag is
added. This is correct at compiling but as the linking step
also invokes $CPP this is also given to the linker.
Logged In: YES
user_id=609236
true - it is given to the linker as well. does it cause a
problem?
Logged In: YES
user_id=392303
Yes, although usuallly it should on my MingW (latest
version) it does (as described above). It would be great if
you could fix this incorrect behaviour.
Logged In: YES
user_id=609236
actually linker is not called with -DDEBUG . it links
the files compiled with -DDEBUG . It's been this way in
dev-c++ since jan 2003. I think people now depend on this
being defined in their projects now. it's not defined in any
of the default header files. it should cause any problem if
the code is bug free.
Logged In: YES
user_id=609236
dev-c++ 4991 uses the latest stable version of mingw. and
I'm sorry - I was wrong before - it is being provided to the
linker. what errors exactly are you getting?
Logged In: YES
user_id=609236
I meant "it should NOT cause any problem if the code is bug
free"
Logged In: YES
user_id=392303
I sometimes get errors about unresolved symbols with
wxWidgets apps. I think this is a compiler bug because
sometimes it works, sometimes not.
You said "actually linker is not called with -DDEBUG". I
dont understand this correctly, what is the -DDEBUG in
the linker call good for?
Logged In: YES
user_id=609236
I'm sorry - I was wrong before - it is being provided to the
linker.
I understand you that it's not neccessary for debugging, but
it's been this way longer than I'm with this project. I'm
not going to make the decision right now. I understand
people actually refer to this within ifdefs in their projects...
Logged In: YES
user_id=392303
Ah OK I understood.
Of course I never remove it if it has any side-effects or
users relying on it.
But could you explain what the linker will actually do with
this flag. The linker cant do anything with this flag
because it just links the object files together.
So what about changing the makefile generation so that this
flag is given to the compiler as usual but not to the
linker. This wouldnt break the code of anyone, regardless
whether he is relying on the flag or not.
Logged In: YES
user_id=392303
Is something about this going to change?
This interests me because you said "I'm sorry - I was wrong
before - it is being provided to the
linker."
You also said "I understand you that it's not neccessary for
debugging, but
it's been this way longer than I'm with this project. I'm
not going to make the decision right now. I understand
people actually refer to this within ifdefs in their
projects..."
If the linker completely ignores this flag because it
shouldnt be there (preprocessor definitions are not for the
linker) why cant you remove it.
Logged In: YES
user_id=609236
If the linker completely ignores it, you shouldn't be
getting any errors. If you do than it's probably a problem
with linker. I'm leaving the bug report open. I'm not going
to decide on changing it.