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

[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

[Jack Klein]

On Fri, 14 Sep 2007 06:02:37 -0700, sujeet <su********@gmail.com>
wrote in comp.lang.c:

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
news:comp.os.ms-windows.programmer.win32, or Microsoft's groups in the
news:microsoft.public.vc.* 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

[Ark Khasin]

Jack Klein wrote:

>
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.

<pedantNDEBUG 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)

[Bart van Ingen Schenau]

Ark Khasin wrote:

Jack Klein wrote:

>>
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.

<pedantNDEBUG 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
#include <assert.h>. In all other respects, NDEBUG is just a regular
macro that C programmers can use.

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.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Ark Khasin]

Bart van Ingen Schenau wrote:

Ark Khasin wrote:

>Jack Klein wrote:

>>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.

<pedantNDEBUG 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
#include <assert.h>. In all other respects, NDEBUG is just a regular
macro that C programmers can use.

>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.

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.

>

>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.

I meant of course
lib.c
int ndebug = ...
lib.h
extern int ndebug;

--
Ark

[Bart van Ingen Schenau]

Ark Khasin wrote:

Bart van Ingen Schenau wrote:

>Ark Khasin wrote:

>>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.

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.

>
--
Ark

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/