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!!
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.
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, thank you for your replies and efforts. Do you think that the next version (of header files and libs) will work with VS 2005?
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.
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
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).
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
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.
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.
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.
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.
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!
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 _WIN32
# include "config_win.h"
# include "brlcad_config.h"
#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.
Forgot to mention that I put back the #include "tclPlatDecs.h" in tcl.h. So tcl.h can stay untouched.
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.
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"
// 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",
// 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
// 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
// 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.
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.
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
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>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.
TYPO! The project I propose to delete is
tclpipe, NOT tclstub!
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
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
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.