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
Related
BASIC INFO:
OS = Windows 7 - 64 bit.
Code::Blocks installed using codeblocks-13.12mingw-setup.exe
wxWidgets installed using wxMSW-3.0.2-Setup.exe
New project created using the following options:
wxWidgets project
wxWidgets 3.0.x
Name: wxHelloWorld
Preferred GUI builder: wxSmith
Application type: Frame based
wxWidgets' location: C:\wxWidgets-3.0.2
Compiler: GNU GCC Complier
wxWidgets Library Settings (checked):
Use wxWidgets DLL
wxWidgets is built as a monolithic library
Enable unicode
Configure Advanced Options
Debug Target:
GUI Mode Application
Release Target:
GUI Mode Application
From this point, I click on build and get the following Build messages:
File Line Message
=== Build: Debug in wxHelloWorld (compiler: GNU GCC Compiler) ===
C:\wxWidgets-3.0.2\include\wx\iosfwrap.h 17 fatal error: iosfwd: No such file or directory
preprocessing failed.
=== Build failed: 2 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===
The code displayed is:
#if wxUSE_STD_IOSTREAM
#if wxUSE_IOSTREAMH
// There is no pre-ANSI iosfwd header so we include the full declarations.
# include <iostream.h>
#else
# include <iosfwd>
#endif
#ifdef __WINDOWS__
# include "wx/msw/winundef.h"
#endif
#endif // wxUSE_STD_IOSTREAM
The file in question is in:C:\Program Files (x86)\CodeBlocks\MinGW\lib\gcc\mingw32\4.7.1\include\c++
I have tried:
Under Settings/Compiler/Search directories: Compiler and Linker and Resource Compiler:
Adding the above file path. This moved the problem to other 'missing' files in similar locations, which I remedied, and eventually lead to a syntax error...
I have also tried installing Code::Blocks directly in C:\ and also copying the MinGW 'include' folder (above) to C:\ (to remove spaces in the file path) this didn't help.
The source files are named wxHelloWorldApp.cpp and wxHelloWorldMain.cpp
Can anyone please advise what is wrong?
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).
I've copied the FL folder into the project.
and it show me this:
1>------ Build started: Project: Client, Configuration: Debug Win32
------ 1> Main.cpp 1>c:\users\user\documents\visual studio 2012\projects\talktome\talktome\fl\xutf8.h(33): fatal error C1083:
Cannot open include file: 'X11/X.h': No such file or directory
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
my source code is
using namespace std;
#include "FL\Fl.H"
#include "FL\Fl_Window.H"
#define WIDTH 700
#define HEIGHT 500
int main()
{
Fl_Window win(WIDTH, HEIGHT, "TalkToMe");
win.begin();
win.end();
win.show();
return Fl::run();
}
You should check if there is "#define WIN32" before your FLTK includes. will help you. It should. Simular problem here:
FLTK in MSVC needs x11 headers?
Do not use the \ in the include statements. Use the forward slash / .
The problems you refer to in your comment to Mycotoxin clearly indicate you have linking problems. You have to tell your compiler where to find the fltk library and the header files. Unresolved external symbols mean only one thing you know... :)
You do not have to define WIN32 as described in Mycotoxin's text. The compiler does that for you, and FLTK uses this fact. Even if it does not, you typically give it as a parameter to the compiler (something like -DWIN32 in the case of GCC or similar for CL).
Watch Greg's video tutorial at http://seriss.com/people/erco/fltk-videos/ where he explains how to configure FLTK and build a small app using Microsoft Visual Studio 7.
Finally, get the source package, and read the README.MSWindows.txt file. It explains everything you need to know in order to build your FLTK-based application on Windows.
Recently my gnu makefile stopped linking my C++ project. I had made some changes. I have copied the link line out and run it from a batch file. It builds fine. But the same line strangely fails when I run make. The error it gives is:
LINK : fatal error LNK1181: cannot open input file 'user32.lib'
which has to be a red herring because from the same command line prompt, running the link command succeeds. I am beginning to suspect GNU make. This used to work from within make but I made a few additions and changes to the makefile to get it building on Linux which seemed to introduce the problem.
I am using :
GNU Make 3.80
MS Visual C++ Linker 10.00.40219.01
on Windows XP.
My LIB and LIBPATH both include the path to the SDK directory which contains the libraries. My link command is as follows:
link C:\SDL-1.2.14\lib\SDL.lib C:\SDL-1.2.14\lib\SDLmain.lib C:\SDL-1.2.14\lib\SDL_image.lib C:\SDL-1.2.14\lib\SDL_ttf.lib C:\SDL-1.2.14\lib\SDL_mixer.lib C:\SDL-1.2.14\lib\SDL_net.lib ../../build/lib/sdlhal.lib user32.lib gdi32.lib kernel32.lib oldnames.lib wsock32.lib advapi32.lib comdlg32.lib comctl32.lib wsock32.lib winmm.lib netapi32.lib OpenGL32.lib glu32.lib /nologo /incremental:no -subsystem:console /PDB:../../build/bin/Prog.pdb /OUT:../../build/bin/Prog.exe /MAP:../../build/bin/Prog.map ../../build/Prog/intr/util.obj ../../build/Prog/intr/objwithvel.obj ../../build/Prog/intr/rock.obj ../../build/Prog/intr/explosion.obj ../../build/Prog/intr/ship.obj ../../build/Prog/intr/photon.obj ../../build/Prog/intr/world.obj ../../build/Prog/intr/test.obj ../../build/Prog/intr/main.obj
EDIT: Bit of progress with C++ program below. My Environment variables were:
LIB=C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;C:\Program Files\Microsoft SDKs\Windows\v7.0A\lib;
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;
But when printed out by program run from within make, they are:
LIB=.lib
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\WINDOWS\Microsoft.NETFramework\v3.5;C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;
Based on your description of the value of LIB, I suspect that you have simply set the "LIB" variable in your makefile (to ".lib"). In standard GNU make (actually, all versions of make) all the environment variables are imported into make as make variables when make starts up (there are exceptions, such as SHELL, which are handled differently).
Whenever make invokes a command, all the current values of variables that were imported are written out to the environment of the child process.
Put another way, any variable that make read from its environment is considered to be marked for export when make runs any command from a recipe.
So if you have a makefile like this:
LIB = .lib
all: ; #echo "LIB = %LIB%"
and you run it like this:
> set LIB=C:\foo;C:\bar
> make
then the output will be "LIB = .lib", not "LIB = C:\foo;C:\bar"
I suspect that your LIB and LIBPATH variables aren't set the way you think they are when link is invoked from make.
Try creating your own link.exe program that gets invoked from make and dumps the command line and environment. That'll tell you for certain whether or not the variables are set correctly by the makefile.
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char** argv, char** env)
{
int i = 0;
for (i = 0; i < argc; ++i, ++argv) {
if (!(*argv)) {
*argv = "(null)";
}
printf( "arg[%d]: \"%s\"\n", i, *argv);
}
puts("\nENVIRONMENT...\n");
while (*env) {
printf( "%s\n", *env);
++env;
}
return 0;
}
Also check that there aren't unquoted spaces in the wrong place in the link command line. While it would seem to be unrelated to the error you mention in the question (and is probably really just a cut/paste error), the link command line you gave has a space in the middle of the path/file name for explosion.obj.
This is likely to be a path issue. Are you using the mingw version of GNU make, or the Cygwin version?
One way to debug this is to put an echo $LIB and echo $LIBPATH command into the make recipe to confirm that these are getting set as you expect.
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.