Problem with header files in VS2005

Help
2006-05-03
2013-04-22
  • Wim Bokkers

    Wim Bokkers - 2006-05-03

    When trying to compile my source that uses the header files of BRL-CAD 7.8.0 on Windows, I get the following error:

    Error    1    error C2732: linkage specification contradicts earlier specification for '_mbschr'    C:\Program Files\Microsoft Visual Studio 8\VC\include\mbstring.h    211   

    It probably has to do with the use of extern "C" or extern "C++" that conflicts with the one used in mbstring.h.

    I did not have problems with an earlier Windows version of BRL-CAD.

    Any help appreciated!!

     
    • jim_monte

      jim_monte - 2006-05-03

      Hi,

      I had tried compiling using VS2003 and do not
      recall that error.  But there are many other
      problems with the project files in the post-build
      step where they copy files to common directories.

      I have fixed the VS7 files and also made a
      VS6 workspace for brlcad that is equivalent to
      the VS7 one except that it does not have the
      all project since it seems easier to select
      build all or rebuild all.

      If you would be interested in a copy of either,
      let me know which, and I will upload them to a
      file sharing site.  But it will have to wait a
      while.  I have been cleaning out the hundreds
      of warnings generated during the build, and am
      in the middle of that right now.  There have
      been many changes required, on the order of
      1000+, many to satisfy the const char **argv
      of Tcl 8.4.  Most have been simply adding a
      const in function declarations and definitions,
      but some instances required more work.

      Just to forewarn you, after you do successfully
      build, it will not work anyhow.  It will fail
      in the initialization phase.  I had just about
      worked that out, but I got detoured for a while
      with the compiler warnings.

      Jim Monte

       
    • jim_monte

      jim_monte - 2006-05-11

      Just as an update, I have completed the warning
      message cleanup.  Actually, there are 4 remaining
      that are things I want to look at in detail
      at some time since they look more serious, and
      it was not obvious how they should be fixed.
      But I want to get back to looking into the
      error messages that are output by the program
      when it is run after it is built.

      Jim

       
    • Wim Bokkers

      Wim Bokkers - 2006-05-11

      Jim, thank you for your replies and efforts. Do you think that the next version (of header files and libs) will work with VS 2005?

       
      • jim_monte

        jim_monte - 2006-05-11

        Hi,

        Using older project files in a newer version of
        VS has never been a problem for me, except that
        the old files are conveted to the new form and
        become unreadable to the old version.  It appears
        that this is even true within major versions.
        The VS7 project files I got here were internally
        labeled as version 7.10, and the original .NET
        (VS 7.00) would not accept them.  At some point
        I will test the VS7 I modified and the VS6 I wrote
        on VS2005 to see if there are any problems.

        Jim

         
        • jim_monte

          jim_monte - 2006-05-19

          Hi,

          I didn't want to keep you waiting too long if
          you really wanted to play with the code, so
          "at some point" was today, with the results
          mixed.  I added my VC6 project files to the
          unaltered 7.8.0 source distribution and opened
          the workspace in VS2005.  After accepting the
          prompts to convert the files to the new version,
          I tried to rebuild all of the projects in a
          batch build.  That quickly generated screen upon
          screen of error messages before I terminated the
          build.  Then it was time to see what went wrong.

          One bit of good news is that the project files
          do appear to have been converted properly.  But
          that means that the problem is with the source
          code and more difficult to fix.  I focused on
          libtcl since it had no dependencies that had
          to be built first.  There were many warnings
          about depricated functions (VS2005 thinks
          sprintf() and other common functions are
          depricated, so you can probably imagine the
          volume), but these could be suppressed by
          adding a macro _CRT_SECURE_NO_DEPRECATE.
          A more serious problem remains that I do
          not have a quick answer for.  The old-style
          K&R function prototypes with the parameter
          types supplied after the closing ')' for the
          prototype are not recognized by the compiler!
          I could not find an option to make the compiler
          accept them.  The option to disable language
          extensions (/Za) did not help and nothing else
          stood out as a reasonable thing to try.
          So to use VS2005, either the flag has to be
          found if it exists, or all of the prototyes
          need to be converted in all of the BRL-CAD
          distribution.  I have done many of these as
          part of the const char **argv fix I have been
          working on, but I have tried to leave external
          libraries such as Tcl/Tk, Zlib, etc. alone
          since the will be evolving on their own
          independent from BRL-CAD.  As a result, there
          is a lot of work required to use VS2005 to
          compile BRL-CAD.

          Jim

           
          • Sean Morrison

            Sean Morrison - 2006-05-19

            That's rather interesting to hear about VS2005 not supporting K&R-style function declarations.  I'm not quite sure I believe it though... :-)  I tested some simple K&R code samples and it had no problem.  What I suspect is going on (with DTR's help, thx) is that it's compiling in C++ mode.  That's pretty much guaranteed to fail on K&R C code.  This should also be a selectable project setting.

            For single files, it's under file properties -> C/C++ -> Advanced -> Compile As...  Similar option for project properties I believe too.  I'd suspect that's the same reason why it's complaining about standard library functions too.

            Otherwise, the vast bulk of the code was updated to ANSI (aiming for strict c89 compliance for now) a couple years ago.  It should be all of "our" code, but there were some stragglers that automation tools and manual updates missed.  That said, we try not to touch code that is not ours unless it's absolutely required as it becomes a maintenance burden.

            There are a few packages where that doesn't hold true since we effectively own the external codes now (e.g. jove, URT) but in general, it's nice to keep the mods minimal for when it comes time to update that code.  Especially for the behemoth Tcl/Tk .. since they are actively maintained, the worst we do is replace their build system (as theirs was broken on several of our platforms last time we updated).

            Cheers!
            Sean

             
            • jim_monte

              jim_monte - 2006-05-19

              Strange, but true... in the one and only case
              that I had tried to date.  I thought it was
              a little odd, especially when I saw no
              mention of this "feature" on the web, but I saw
              the compile that failed with K&R work after I
              updated the prototype.  The compiler was
              already set to compile as C, but there was
              something unusual.  Try compiling
              7.8.0/src/other/libtcl/generic/regerror.c
              and you should see the messages, 19 errors
              and 8 warnings from a 100 line file.  It
              turned out that the first prototype variable,
              errcode, was already defined in a system
              header file.  Adding the /Za flag gives
              a warning about this.  After renaming errcode
              but leaving the K&R style, the file compiled OK.
              So this would probably fall under the category
              of compiler bugs.  I will add the macro I had
              mentioned before and see if that and some
              renaming fixes everything.

              Jim

               
          • Wim Bokkers

            Wim Bokkers - 2006-05-19

            Well, I had no problems with VS2005 with the previous Windows version of BRL-CAD. So it can't be a problem with the K&R style.
            Note that I'm not interested in compiling BRL-CAD using VS2005. All I want is to use the (compiled) libs and the appropriate header files in my C++ projects.

             
      • jim_monte

        jim_monte - 2006-05-15

        Hi,

        Just as a test, I made a simple VS5 workspace
        with a few small projects to see if this would
        be understood by VS2005.  Yes, that is VS5
        which was also known as VS(19)97, not VS6.  It
        was the oldest VS that I had installed anywhere.
        VS2005 was able to understand and convert the
        workspace file and project files to the versions
        used by VS2005.  So either of the project file
        sets for BRL-CAD should be OK in VS2005.

        Incidentally, I found an "interesting" (read
        as "took a long time to figure out what was going
        on and then turned out to be something strange")problem with the dependencies given with source
        for 7.8.0.  Project tclstub was made dependent
        on libtcl.  It should not have been because
        libtcl is a static library and did not need to
        resolve anything using libtcl.  But adding this
        dependency caused a LNK4006 warning about a
        duplicate reference because this dependency added
        the output of project libtcl to the link
        command.  Fixing as the warning suggested
        caused a strange run-time linking problem.
        I finally fixed the problem, but it was memorable.

        Jim Monte

         
    • Sean Morrison

      Sean Morrison - 2006-05-19

      Wim,

      Is there no other diagnostic output other than mbstring.h?  There was quite a lot of header clean-up and restructuring that went into 7.8.0 actually to try and *ahem* help some of the C++ linkage problems you'd mentioned earlier.  There's still more than has to happen, I'm sure, and from your message this is apparently quite true.  If you have a simple test linkage + header usage that fails I can look into the problem more closely.

      Cheers!
      Sean

       
      • Wim Bokkers

        Wim Bokkers - 2006-05-19

        Next week I will try to make an as simple as possible C++ project and let you know what messages I get when including the BRL-CAD headers.

        Have a nice weekend!
        Wim

         
    • Wim Bokkers

      Wim Bokkers - 2006-05-22

      As promised I tried to compile a simple project.

      At first I thought that I found the problem. After removing #include "tlcPlatDecls.h" from tcl.h everyting compiled ok, until I used some STL functionality.

      It turned out that the problem is in common.h in the following part:

      #ifdef HAVE_CONFIG_H
      #  ifdef _WIN32
      #    include "config_win.h"
      #  else
      #    include "brlcad_config.h"
      #  endif
      #endif  /* _WIN32 */

      HAVE_CONFIG_H was not defined. As a result config_win.h was not included.

      I removed the check for HAVE_CONFIG_H and now everyting compiles and links without problems.

       
      • Wim Bokkers

        Wim Bokkers - 2006-05-22

        Forgot to mention that I put back the #include "tclPlatDecs.h" in tcl.h. So tcl.h can stay untouched.

         
      • Sean Morrison

        Sean Morrison - 2006-05-22

        That's rather interesting and useful to know, though it implies there is "some other problem" as neither of the config headers is supposed to be required by any header or by an external code in order to function.  At some point in the near future after these problems are sorted out, those headers will not even be installed and will be considered private headers.

        The problem and reality, however, is that there must be several (or at least one) header that is reliant upon some symbol being provided in the config header.  In particular since you are on Windows, there must be something in config_win.h that must be defined in order for some other header to work.

        As you noted, including the config header causes other problems (_close, _open, etc) but that's because it's not supposed to be included.  That said, even in config_win.h there should probably be __cplusplus language protections on the C-specific defines.

         
        • Wim Bokkers

          Wim Bokkers - 2006-05-23

          Hi Sean,

          I removed as much from config_win.h as possible.
          What remains is needed by my project to compile and link:

          --------------

          #define __STDC__ 1
          // If not defined:
          // Error    2    error C2535: '_Result std::binder1st<_Fn2>::operator ()(_Arg &)' : member function already defined or declared    C:\Program Files\Microsoft Visual Studio 8\VC\include\functional    282   
          // Error    3    error C2535: '_Result std::binder2nd<_Fn2>::operator ()(_Arg &)' : member function already defined or declared    C:\Program Files\Microsoft Visual Studio 8\VC\include\functional    324   
          // Error    4    error C2733: second C linkage of overloaded function 'memmove' not allowed    C:\Program Files\Microsoft Visual Studio 8\VC\include\wchar.h    1186   
          // NOTE 1: probably there are defines in BRL-CAD libs that conflict with VS2005 when
          //         __STDC__ is not defined.

          /* Ensure that Project Settings / Project Options includes
          *    /Za        for ANSI C
          */
          # if !__STDC__
          #    error "STDC is not properly set on WIN32 build, add /Za to Project Settings / Project Options"
          # endif
          // NOTE 1: The /Za project settings does not set this flag!
          // NOTE 2: I can't use the /Za flag, since language extensions are being used.

          #define HAVE_STDARG_H    1
          // If not defined:
          // Errors are detected in usages of bu_log (in fixed routine: rt_generic_xform_fixed):
          // Error    10    error C2660: 'bu_log' : function does not take 2 arguments    j:\develop\app\tarvac6projects\common\BRLModel.cpp    63   
          //           bu_log("rt_generic_xform():  %s export failure\n",
          //              rt_functab[id].ft_name);
          // Error    11    error C2660: 'bu_log' : function does not take 1 arguments    j:\develop\app\tarvac6projects\common\BRLModel.cpp    70   
          //           bu_log("rt_generic_xform():  solid import failure\n");
          // Question: is the fixed routine rt_generic_xform_fixed still needed outside BRL-CAD?

          #define USE_PROTOTYPES    1
          // If not defined:
          // Error    1    error C2660: 'rt_dirbuild' : function does not take 3 arguments    j:\develop\app\tarvac6projects\common\BRLRayTracer.cpp    43   
          // Error    2    error C2660: 'rt_gettree' : function does not take 2 arguments    j:\develop\app\tarvac6projects\common\BRLRayTracer.cpp    50   
          // Error    3    error C2660: 'rt_prep' : function does not take 1 arguments    j:\develop\app\tarvac6projects\common\BRLRayTracer.cpp    57   

          #include <windows.h>
          // If not included:
          //Error    1    error C2733: second C linkage of overloaded function '_mbschr' not allowed    C:\Program Files\Microsoft Visual Studio 8\VC\include\mbstring.h    211   
          //Error    2    error C2733: second C linkage of overloaded function '_mbschr_l' not allowed    C:\Program Files\Microsoft Visual Studio 8\VC\include\mbstring.h    216   
          //Error    3    error C2733: second C linkage of overloaded function '_mbspbrk' not allowed    C:\Program Files\Microsoft Visual Studio 8\VC\include\mbstring.h    221   

          #undef rad1
          #undef rad2
          // If not undefined:
          // Error    8    error C2143: syntax error : missing ')' before 'constant'    c:\program files\brl-cad\include\wdb.h    171   
          //           WDB_EXPORT WDB_EXTERN(int mk_cone, (struct rt_wdb *fp, const char *name, const point_t base,
          //               const vect_t dirv, fastf_t height, fastf_t rad1,
          //               fastf_t rad2) );
          // NOTE: These defines (rad1 and rad2) are from dlgs.h and conflict with the parameters used in wdb.h

          -------

          I added error messages and some notes on what goes wrong when leaving the code out.

           
    • Wim Bokkers

      Wim Bokkers - 2006-05-22

      Including config_win solves the above compiler problems, but also introduces some problems.

      When using C++ classes with methods close and open (like STL streams), calls to these methods are replaced by _close and _open, due to the defines in config_win.h.

       
    • jim_monte

      jim_monte - 2006-05-22

      Progress...

      Starting with the the VC6 workspace and project
      files I made based on the VC7 version included
      in the 7.8.0 zip file and adding the macro
      _CRT_SECURE_NO_DEPRECATE, I was able to compile
      5 of the 44 projects successfully.  That was
      not as bad as it may appear since there was
      a common error regarding an undefined structure
      that accounted for much of the problem.
      VS2005 is making many things 64 bit by
      default, such as time_t but offering a 32-bit
      version by defining a macro.  As a result, what
      was previously a structure name is now a macro
      for the real structure name.  In our case, the
      structure of interest is struct _stati64 used
      in tcl.h (and others?) as
      typedef struct _stati64 Tcl_StatBuf;
      In earlier versions of the header files,
      there was a struct stati64 in say
      VC98\Include\SYS\STAT.H,
      but now _stati64 is defined in wchar.h as either
      _stat32i64 or _stat64 depending on the
      presence/absence of macro _USE_32BIT_TIME_T.
      And each of these definitions has its
      own structure.  So wchar.h must be included
      somehow before the typedef is reached.
      Including the header file changed the
      build success to 42 of 44.  There are
      many warnings, and probably adding the
      _USE_32BIT_TIME_T would be a good thing to
      do for the next few decades since it was
      responsible for some of these.

      Of the two remaining failures, one is tclstub.
      A lib file was not created during linking which
      generated an error when a copy was attempted.
      Looking at its only source file,
      /src/other/libtcl/win/stub16.c, it was clear
      that the new linker version suppressed the
      creation of this file because there were no
      exported symbols.  Looking at the file a
      little bit more, it seemed that there is
      no purpose in even including it in BRL-CAD.
      According to a header comment:

      *    Entry point for the 32-bit console mode app used by Windows 95 to
      *    help run the 16-bit program specified on the command line.

      So that project should be deleted.  Agreed?

      The last remaing failure is in wish.  This
      one was a strange one:

      1>Linking...
      1>CVTRES : fatal error CVT1100: duplicate resource.  type:MANIFEST, name:1, language:0x0409
      1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
      1>Build log was saved at "file://f:\jim\temp\BRL-CAD_temp\brlcad-7.8.0\misc\win32-mscvc6\wish\Debug\BuildLog.htm"
      1>wish - 2 error(s), 0 warning(s)

      I tried a different resource number with no
      better results.  Then I tried suppressing
      the manifest file using the linker option
      /MANIFEST:NO.  With that change, it linked OK.
      I do not know all that much about manifest
      files, but I think it is not needed.  So if
      that is the case and if tclpipe can be deleted,
      it looks like the build in VS2005 is OK.

      Jim

       
    • jim_monte

      jim_monte - 2006-05-22

      TYPO!  The project I propose to delete is
      tclpipe, NOT tclstub!

      Jim

       
    • jim_monte

      jim_monte - 2006-05-24

      Wim,

      I somehow missed your very important comment that
      you did not wish to compile the BRL-CAD project
      itself using VS8!  I think the information I have
      gained by doing so may perhaps be of help to you
      anyhow, at least a little bit.  As I mentioned
      earlier, tcl.h needs to be modified to include
      wchar.h.  I believe this may be necessary for
      you as well.  My addition, right after the
      #include "common.h", is

      #ifdef _WIN32
      #include <wchar.h>
      #endif

      The BRL-CAD source distribution has 2 tcl.h files,
      one in /include and the other in
      /src/other/libtcl/generic.  So make sure that
      you update whichever you are using as a header.
      I found out the hard way that there were two
      since when building BRL-CAD different ones are
      used for different compiles.

      Another possibly big problem still exists in
      VS8's enlargement of many data types.  If you
      are linking against libraries that think these
      are a different size, there will be "problems"
      if they occur in an exported function you use.
      To reduce this possiblity, use the
      _USE_32BIT_TIME_T macro and anything you find
      that may look close in your projects.  Adding
      _CRT_SECURE_NO_DEPRECATE may possibly be helpful
      since it seems to make VS8 behave more like older
      versions.

      Jim

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks