I have just started a project c++ with Panda3D. ( Visual Studio 2010 )
With a simple HelloWorld, I add paths etc. No compile error except :
an error just appeared :
error LNK1104: cannot open file 'python27_d.lib'
And I have no idea how to fix it.
Plz help !
Thanks !
There's a few things you can do.
1) just build in release mode (not a good solution, since you can't debug too well this way)
2) add another build configuration based on "Release" but with debug symbols and without the _DEBUG preprocessor definition (can mess up some libraries)
3) find or build a Python 2.7 version with debug and release libraries build in Visual Studio 2010
4) just change this one section in the pyconfig.h where it actually links to the *.lib file to just use the python27.lib for both configurations.
/* For an MSVC DLL, we can nominate the .lib files used by extensions */
#ifdef MS_COREDLL
# ifndef Py_BUILD_CORE /* not building the core - must be an ext */
# if defined(_MSC_VER)
/* So MSVC users need not specify the .lib file in
their Makefile (other compilers are generally
taken care of by distutils.) */
# ifdef _DEBUG
# //-----------------------change the next line-------------//
# pragma comment(lib,"python27_d.lib")
# else
# pragma comment(lib,"python27.lib")
# endif /* _DEBUG */
# endif /* _MSC_VER */
# endif /* Py_BUILD_CORE */
#endif /* MS_COREDLL */
1) 2) and 4) are hacky solutions, so I'd suggest you try to use 3).
Related
I am trying to use sqlite3 on a program written by C++ 2003.
I have downloaded sqlite-amalgamation-3360000.zip from download page and add sqlite3.h to header files, shell.c & sqlite3.c to resources file.
then I write a simple code in test.cpp to test the connection:
#include "sqlite3.h"
#include <iostream>
int main()
{
sqlite3 *db;
sqlite3_open("test.sqlite", &db);
return 0;
}
however when I compiled it always show error:
sqlite3.c(27474): error C2692: '_ReadWriteBarrier' : fully prototyped functions required in C compiler with the '/clr' option
I dont know what I did wrong. Please can someone help?
_ReadWriteBarrier is a compiler intrinsic function: the compiler is programmed to handle it specially. This is declared in the intrin.h header file.
From sqlite3.c:
/*
** Make sure that the compiler intrinsics we desire are enabled when
** compiling with an appropriate version of MSVC unless prevented by
** the SQLITE_DISABLE_INTRINSIC define.
*/
#if !defined(SQLITE_DISABLE_INTRINSIC)
# if defined(_MSC_VER) && _MSC_VER>=1400
# if !defined(_WIN32_WCE)
# include <intrin.h>
# pragma intrinsic(_byteswap_ushort)
# pragma intrinsic(_byteswap_ulong)
# pragma intrinsic(_byteswap_uint64)
# pragma intrinsic(_ReadWriteBarrier)
# else
# include <cmnintrin.h>
# endif
# endif
#endif
Since you are compiling on an ancient version of MSVC, I suggest disabling this by defining the SQLITE_DISABLE_INTRINSIC preprocessor symbol.
My problem is very much related the post
Defined macro not recognized
I wrote a CMakeLists file to be able to build my project for OS X (Eclipse mostly but sometimes used Xcode) and Windows (Visual Studio). The issue showed up today when creating my project for Windows + MinGW. I was using the defined _WIN32 to enable some functions when I was in windows, i.e.
bool Normal::HasNaNs() const
{
#ifdef _WIN32
return _isnan(x) || _isnan(y) || _isnan(z);
#else
return isnan(x) || isnan(y) || isnan(z);
#endif
}
However, with the combo Eclipse+MinGW the code is entering the ifdef part instead of (what I was hoping/thinking should be correct) entering the else part. I think Visual is the only one having the _isnan() function.
So, what would be a more robust way to check for Windows+VS, Windows+MinGW, OSX ?
_MSC_VER is the best way to check if you're being compiled by Visual Studio:
https://msdn.microsoft.com/en-us/library/b0084kay.aspx
For checking for MinGW (please see comment for more info), you can use:
#ifdef __GNUC__
#ifdef __MINGW32__
as per this answer:
https://stackoverflow.com/a/17493838/493106
and then __APPLE__ for os x.
https://stackoverflow.com/a/2166491/493106
I'm trying to build gnuplot with Visual Studio 2015. To this end I run the Makefile located in the config\msvc :
Start the Microsoft Visual C++ command shell
change to the config\msvc
Run nmake -f Makefile
but I obtain the following fatal error :
c:\.......\gnuplot\src\gnuplot-5.0.1\gnuplot-5.0.1\src\syscfg.h(377): error C2632: 'char' ne peut pas être suivi de 'bool'
Is it the correct way to build the 5.0.1 version of gnuplot for windows ? Have you already seen this error ?
The problem is with bool type: Microsoft Visual Studio (since version 2013) package includes a library with bool as a type. Somewhy, HAVE_STDBOOL_H is not defined on your system. The issue has already been faced when compiling other software.
I can suggest you two possibilities:
1) write #define HAVE_STDBOOL_H in gnuplot-5.0.1\src\syscfg.h just above line 370
2) Open Makefile, add /DHAVE_STDBOOL_H to CFLAGS, or, even to CBASEFLAGS.
gnuplot-5.0.1\src\syscfg.h (370-384):
#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# if ! HAVE__BOOL
# ifdef __cplusplus
typedef bool _Bool;
# else
typedef unsigned char _Bool;
# endif
# endif
# define bool _Bool
# define false 0
# define true 1
# define __bool_true_false_are_defined 1
#endif
The way you build it is believed to be correct, it agrees with the original guide provided in Makefile:
Start the Microsoft Visual C++ command shell (e.g. via link installed
setup)
Change to the gnuplot\config\msvc directory
Edit the Makefile to match your setup. (If you don't have the optional libraries, you will probably have to disable some parts.)
Now run:
nmake
I installed zlib 1.2.8 and built the miniunzip and minizip projects to test creating and opening a zip.
I built as debug on visual studio 2010 32 bit, with the debug dll zlibwapid .
Minizip worked fine to create a zip file however miniunzip failed to open the zipfile created, and looking in miniunz.c the failure is because:
uf = unzOpen2_64(zipfilename,&ffunc); returns 0.
I saw the code is wrapped as follows in defines:
#ifdef USEWIN32IOAPI
fill_win32_filefunc64A(&ffunc);
uf = unzOpen2_64(zipfilename,&ffunc);
#else
uf = unzOpen64(zipfilename);
#endif
On a hunch I changed the define at the top to:
#ifdef _WIN32
//#define USEWIN32IOAPI //disabled this
#include "iowin32.h"
#endif
Now mininunzip works fine but I dont really know why. Anyone know if this is a known bug , I couldnt find any information about it.
Thanks
I am trying to compile Boost 1.47 for x86 Windows CE using Visual Studio 2008 and STLPort 5.2.1. I can successfully compile for x86 Windows and ARMV4I Windows Mobile 6.5.
When I run bjam, I get this error in most every module:
stlport\ctype.h(42) : fatal error C1083: Cannot open include file: '../1/ctype.h': No such file or directory
That line of code the error refers to in STLPort's ctype.h is:
#include _STLP_NATIVE_C_HEADER(ctype.h)
If I create a new Visual Studio project and add the lines:
#define STR1(x) #x
#define STRINGIZE(x) STR1(x)
#pragma message (STRINGIZE(_STLP_NATIVE_C_HEADER(ctype.h)))
I see: <../X86/ctype.h> as I would expect.
Why is boost replacing "X86" with "1"? It does not have this issue when compiling for ARMV4I Windows Mobile or x86 Windows.
Edit
More information. Something is very deliberately doing a string replace on "X86".
In stlport\stl\config_evc.h I added the pragma messages to this code:
# if !defined (_STLP_NATIVE_INCLUDE_PATH)
# if defined (_X86_)
# if defined (_STLP_WCE_TARGET_PROC_SUBTYPE_EMULATOR)
# define _STLP_NATIVE_INCLUDE_PATH ../Emulator
# else
# define _STLP_NATIVE_INCLUDE_PATH ../X86
# pragma message (STRINGIZE(../abcdefg))
# pragma message (STRINGIZE(../X86))
# pragma message (STRINGIZE(_STLP_NATIVE_INCLUDE_PATH))
# endif
The output is:
../abcdefg
../1
../1
You have X86 macro defined (either by one of the earlier-included headers, or from a command line) and set to 1, so it gets expanded, like macros tend to do. #undef X86 will get rid of it.