Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

two macros are incorrect in bu.h in windows

Help
autoeagle
2006-06-21
2013-04-22
  • autoeagle
    autoeagle
    2006-06-21

    It is seem that two macros are set incorrect in the bu.h : "HAVE_STDARG_H" and" USE_PROTOTYPES" .
    They lead  most of errors in   Compiling an BRLCAD application in Windows.

    such as jim_monte said:
    "Nearly all of them were either due to incomplete function declarations, unused variables, or implicit type conversion. "And the root of those errors is the two macros.

    Once I set those two macros and let follow definiens work.Everything is Ok.

    #    define    BU_EXTERN(type_and_name,args)    extern type_and_name args
    #    define    BU_ARGS(args)    args
    BU_EXPORT BU_EXTERN(void bu_log,
                (char *, ... ));
    BU_EXPORT BU_EXTERN(void bu_flog,
                (FILE *, char *, ... ));

    Plus:
    1.The common dll file could not be debug according MSDN Library.
    “Debugging a Dynamic-Link Library (DLL) in Windows”(Q85221)。

    “Problems Loading a Debuggee That Uses a DLL”(Q119518)。

    2.Be careful the the lib and include file set in
    vs2003.And the output must be the release file(no debug). Copy the release file to brlcad/bin directory or copy those dll files to windows/system32.

     
    • plus 3:
      include <windows.h>
      which define the DWORD and HANDLE

      In short , Compiling an BRLCAD application in Windows(use brlcad as a SDK)is easy.But BRLCAD lack HOWTO , API reference and example project in Windows , which are very importent for some non-Unix programers.    

       
    • Sean Morrison
      Sean Morrison
      2006-06-21

      Thanks for looking into the problem.  It is known that there are some issues in the public headers..  In particular for external/new codes, there are problems due to things that are either not defined or defined incorrectly as you encountered.

      The macros get to the wrong case due to issues related to the common.h header.  If you define the HAVE_CONFIG_H or maybe even _WIN32 as a preprocessor symbol, then it will include the (private) config header that includes the missing symbols needed to provide HAVE_STDARG_H and USE_PROTOTYPES among a couple dozen other defines.  That's of course not "correct" behavior but it should get things working for the time being until the headers themselves are fixed.

      Cheers!

       
    • autoeagle
      autoeagle
      2006-06-22

      Thank you for your answer.That is very useful for me.