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

Discussion in 'C Programming' started by sujeet, Sep 14, 2007.

  1. sujeet

    sujeet Guest

    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
     
    sujeet, Sep 14, 2007
    #1
    1. Advertising

  2. sujeet

    Jack Klein Guest

    On Fri, 14 Sep 2007 06:02:37 -0700, sujeet <>
    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
     
    Jack Klein, Sep 15, 2007
    #2
    1. Advertising

  3. sujeet

    Ark Khasin Guest

    Re: unable to compile and link application in Debug mode with libraryin Release mode

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

    <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)
     
    Ark Khasin, Sep 15, 2007
    #3
  4. 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.
    >>

    > <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
    #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/
     
    Bart van Ingen Schenau, Sep 15, 2007
    #4
  5. sujeet

    Ark Khasin Guest

    Re: unable to compile and link application in Debug mode with libraryin Release mode

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

    >> <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
    > #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
     
    Ark Khasin, Sep 16, 2007
    #5
  6. 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/
     
    Bart van Ingen Schenau, Sep 16, 2007
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave
    Replies:
    0
    Views:
    664
  2. =?Utf-8?B?TWF4?=
    Replies:
    0
    Views:
    472
    =?Utf-8?B?TWF4?=
    Feb 11, 2006
  3. rbg
    Replies:
    0
    Views:
    440
  4. Replies:
    1
    Views:
    253
    Peter Zolja
    Jan 31, 2007
  5. Replies:
    1
    Views:
    212
    Peter Zolja
    Jan 31, 2007
Loading...

Share This Page