unable to compile and link application in Debug mode with library in Release mode

S

sujeet

Dear friends,


I'm facing a strange problem...

My Application is in Debug mode, and the third party static library
i'm using is in release mode.

When i compile and try to link my application ...
I get a linker error from the third party library as.

Debug information corrupt, recompile the module..... ( from third
party static library)

Is is that using one application in Debug mode and using static
library in release mode gives such type of problems.?

Here actually i'm trying to Debug my application......with third party
library in release mode.....

Any detailed explanation on this would be much helpful.....

Environment: Visual C++ 6.0
Library: static library in release mode......( third party library )
Programming Language: C
 
J

Jack Klein

Dear friends,


I'm facing a strange problem...

My Application is in Debug mode, and the third party static library
i'm using is in release mode.

[snip]

You're asking in the wrong place, none of this has anything at all to
do with the C language, which doesn't define "debug mode", "release
mode", or "static library". This is all Windows specific.
Environment: Visual C++ 6.0
Library: static library in release mode......( third party library )
Programming Language: C

Good general purpose Windows programming group
or Microsoft's groups in the
family.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
A

Ark Khasin

Jack said:
You're asking in the wrong place, none of this has anything at all to
do with the C language, which doesn't define "debug mode", "release
mode", or "static library". This is all Windows specific.
<pedant> NDEBUG is in the standard, so the OP is not 100% OT </pedant>
Out of curiosity, can anyone think of why a hosted application would
care if NDEBUG was defined or not (I suppose, across the board) in the
library? E.g, is it legal to write something like this:
extern int foo(int x
#ifdef NDEBUG
, ...
#endif
);
in a library header?
Or can a library implement something like this:
int ndebug =
#ifdef NDEBUG
1
#else
0
#endif
;
and an evil API
extern int bar();
extern int baz();
#define foo (ndebug?bar:baz)
 
B

Bart van Ingen Schenau

Ark said:
<pedant> NDEBUG is in the standard, so the OP is not 100% OT </pedant>

But the question of the OP did not have any relation to the NDEBUG
macro.
Defining or undefining the NDEBUG macro only affects which
implementation of the assert() macro will be used when you next
Out of curiosity, can anyone think of why a hosted application would
care if NDEBUG was defined or not (I suppose, across the board) in the
library? E.g, is it legal to write something like this:
extern int foo(int x
#ifdef NDEBUG
, ...
#endif
);
in a library header?

Yes, that is legal. And it would cause UB if there is a mismatch between
the presence of NDEBUG in the implementation of foo and the use of foo.
Or can a library implement something like this:
int ndebug =
#ifdef NDEBUG
1
#else
0
#endif
;
and an evil API
extern int bar();
extern int baz();
#define foo (ndebug?bar:baz)

Except for the possible multiple definitions of the int ndebug, that
code is perfectly legal.

Bart v Ingen Schenau
 
A

Ark Khasin

Bart said:
But the question of the OP did not have any relation to the NDEBUG
macro.
Defining or undefining the NDEBUG macro only affects which
implementation of the assert() macro will be used when you next


Yes, that is legal. And it would cause UB if there is a mismatch between
the presence of NDEBUG in the implementation of foo and the use of foo.

Great. This UB often stops nowadays at the link phase: decent linkers
detect the difference in the function signatures at the use and
definition points. That could be a reason of the OP's link failure,
which is of course a valid form of UB.
So the OP was not *at all* OT, as it turns out. Or, rather, since he
only gave an incomplete definition of the problem by the end of the
posting unit, the posting caused UB in replies.
Except for the possible multiple definitions of the int ndebug, that
code is perfectly legal.
I meant of course
lib.c
int ndebug = ...
lib.h
extern int ndebug;
 
B

Bart van Ingen Schenau

Ark said:
Great. This UB often stops nowadays at the link phase: decent linkers
detect the difference in the function signatures at the use and
definition points.

Linkers, decent or not, are only able to do that if the compiler encodes
information about function arguments into the name that the linker is
asked to resolve.
Traditionally, C compilers do not perform such encoding, so it is not
guaranteed that a linker (even a decent one) can detect a mismatch in
used and expected parameters.
That could be a reason of the OP's link failure,
which is of course a valid form of UB.
So the OP was not *at all* OT, as it turns out. Or, rather, since he
only gave an incomplete definition of the problem by the end of the
posting unit, the posting caused UB in replies.

The OP asked about a compiler/linker complaint that mentioned the
term 'debug information'.
If a compiler generates debug information or not is not governed by the
use of the NDEBUG macro, but rather by the options provided to the
compiler itself.
Therefor, the question was not about the C language but rather about how
to operate a particular compiler. This makes the question OT for clc.

Bart v Ingen Schenau
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top