I have some code here that we used to use to call a Python script from our (very large) application. It worked fine when we used VS2008 (compiler v90), which is what the default version of python27 was compiled with.
In the last year we've upgraded our application to VS2010, and I was looking to update the Python-calling dll, thinking it would be a morning's work. Unfortunately, after wrestling with the linker and missing dlls for ages, most of my colleagues agree that our application and python27.dll are using incompatible versions of Windows CRT.
I thought it would be simple enough to find a version of python27.dll (or indeed another version would be fine) compiled with VS2010 (v100) - but I can't.
Is there a way to call a Python script from an application compiled in VS2010?
An answer may be: Download the python sources - compile a custom python.dll and link against that.
I have the same problem. The solution is indeed to build python from the sources. But there is a big drawback: all extra 3rd party python modules pre-build for Windows that you download from internet will not work! This is because all of those modules will be prebuild with VS 2008 and you get again in trouble with incompatible runtimes. The solution is that all such extra modules needs to be again rebuild from sources, but the task is not easy in all cases. The modules are ususally tested in VS2008 and you get a lot of troubles trying to run them with VS2010. I got this mostly with database connectors for MySQL, MSSQL and others.
Related
I'd really appreciate some help getting HElib to work on Windows 10 x64 using the MSVC 2017 compiler. I successfully managed to compile its dependency, NTL, using the same compiler by following this tutorial and also ran its tests, so it seems to work well.
However, in the case of HElib I tried generating Visual Studio projects using cmake and then compiled it successfully (see NOTE below), but running it fails. For example, I ran the Test_binaryCompare.cpp_exe test (has its own vcproj generated by cmake), but it fails because it reaches a part of code I doubt it's supposed to (it attempts to do an operation called bootstrapping and it is disabled for that test). However, on Linux it works.
LINUX: The reason I'd really like to run this on Windows is because I find it a lot easier to debug using Visual Studio. I'm also more used to Windows overall..
NOTE: Compiling HElib successfully required some modifications like fixing broken tr1 includes (e.g it was trying to include <tr1/memory> instead of just memory although the latter was actually available), suppressing the 4146 error (I also had to do this for NTL) and fixing two instances of variable-length arrays which Microsoft's compiler sadly does not support.
Without any error messages I can't really help you figure out your exact issues but I ported HElib to Windows some time ago: https://github.com/AlexanderViand/HElib/tree/Windows
It's a bit out of date but if the tests works in that version you can check the changes I made against your changes.
There's also the option that you're simply running into this issue: https://github.com/shaih/HElib/issues/228
If your linux version of NTL is slightly older, it might just be that your windows version of NTL is the buggy one.
Finally, I'd very much recommend against running HElib on Windows because without GMP it seems painfully slow.
Instead I ended up setting up a docker virtual machine and SSH'd into that from visual studio: https://hub.docker.com/r/alexanderviand/visual-studio-linux-build-box-with-helib/
Currently I'm using WSL and CLion (which supports WSL quite well) when I'm working with HElib on Windows.
I need to configure Thrift for Eclipse project with MinGW compiler. I googled for it. I couldn't find proper instructions to do that? Can somebody suggest any suitable way or proper link to do that?
There are several partial answers to this.
The Windows build is made by means of MinGW cross compiler on a Linux machine.
Since (at least) 0.9.2 it is no longer necessary to use MinGW to build the Thrift compiler on a Windows machine.1) Aside from the fact, that you don't need to do that at all, because a precompiled EXE is available on the download pages, there is a nice Visual Studio project to build the Windows Thrift compiler EXE. The project has only two dependencies: Bison and Lexx/Yacc, which are both available elsewhere as precompiled Setups as well.
In either case MinGW is only used to build the compiler. If you want to build the libraries with MinGW, I'm not sure if that even works. This way of doing things is not implemented or supported, simply because nobody needs it.
Which brings us back to the question, why you think you "need" it this way.
1)To my knowledge, numerous severe problems exist with the autotools and all the stuff needed to build Thrift under MinGW on a Windows machine. You will have to patch things, build some from source, spend a lot of time and do some strange things with your file system to make it work. At least that was the case when I stopped using MinGW to build Thrift about two years ago. And even if you get it to work, you still only get the compiler (which you could easily download in a fraction of that time), not the libraries.
I am supposed to build existing Windows 32bit project for Windows 64bit. (and probably linux 64bit too).
The project uses log4cplus library. That one only contains 32bit .lib files at the moment and is shining example of why I hate using libraries in C++ - there's just a bunch of source files and linux bash scripts. The INSTALL help file is entirely about the configure bash script which doesn't work on Windows. The configure probably just passes some arguments to GCC, but I don't known which ones.
I downloaded MinGW in hope I'll be able to use mingw32-make on the project and it will work, but no such thing happened.
So does anyone have any experience making those Linux projects on Windows? This is not the first time I tackle this problem - my third most viewed question is about broken Boost build. Judging from the view count, I'm not the only one who has problems building Linux project on widnows.
log4cplus maintainer here.
The master branch of log4cplug GIT repository is C++11 only. Because of this, it requires Visual Studio 2015 and thus the msvc14 directory is there.
Branch 1.2.x and its releases come with Visual Studio project files for version 2010. However, you might be able to build it using CMake for even older Visual Studio.
However, both of them, in any configuration, should have no problem building for AMD64 platform.
I also suggest that you read the README.md file. It documents many things, some of which might be useful to you, too.
I am trying to modify a current MFC application running on Windows NT4 to use boost libraries for ethernet communcications (originally, it used CommX for serial) and general increased performance, effieciency, and clarity of code.
I started out modifying it in VS2010, but I found that I was unable to produce a valid NT4 app with VS2010. I googled the issue and found that VS2005 was the last version able to create an NT4 app. I got everything to compile in VS2005, but found that I had to change certain #define statements in stdafx.h in order to get the app to run on NT4. However, even after doing that, when I execute the program on NT4, it immediately quits with no error. It doesn't show anything. I even checked the Task Manager processes while executing it. It is like it never executed at all.
I got desperate and tried compiling the app in VS2003, but I got so many errors that I gave that up.
My last attempt was VC6, but again, I got 262 errors and started wondering whether it was even possible for boost to run in VB6 or on an NT4 machine.
Is it even possible to compile and run an MFC app with boost libraries on an NT4 machine? If so, which environment/compiler do I need and how do I configure it to work correctly?
This is a very tight-schedule project, so any (prompt) help would be very appreciated! Thank you!
If you're trying to use VC6 to compile code that uses Boost, you may need an older version of Boost. Try 1.34.1.
You might try using STLport as the standard library implementation instead of the built-in STL that comes with VC6. I'm using boost 1.32 and STLport 4.6.2 successfully in VC6 with an MFC project. I haven't tried moving up to newer versions of boost or STLport, but STLport might be enough to get you going.
I'm involved in C++ project targeted for Windows and Linux (RHEL) platforms. Till now the development was purely done on Visual Studio 2008. For Linux compilation we used 3rd party Visual Studio plugin, which read VS solution/perojects files and remotely compiled on Linux machine.
Recently the decision was to abandon the 3rd party plugin.
Now my big concern is a build system. I was looking around for cross platform build tools. This way I don't need to maintain two set of build files (e.g. vcproj/solution for Windows and make files for Linux).
I found the following candidates:
a. Scons
b. cmake
What do you think about the tools for cross-platfrom development?
Yet another point that bothers me is that Visual Studio (+ Visual Assist) will loose a lot functionality without vcproj files - how you handle the issue with the tools?
Thanks
Dima
PS 1: Something that I like about Scons is that it
(a) uses python and hence it's flexible, while cmake uses propriety language (I understand that it's not a winner feature for a build-system) (b) self contained (no need to generate makefiles on Linux as with cmake).
So why not Scons? Why in your projects the decision was to use cmake?
CMake will allow you to still use Visual Studio solutions and project files. Cmake doesn't build the source code itself, rather it generated build-files for you. For Linux this can be Code::Blocks, KDevelop or plain makefiles or still other more esoteric choices . For Windows it can be among others Visual Studio project files and still others for MacOS.
So Visual Studio solutions and projects are created from your CMakeLists.txt. This works for big projects just fine. E.g. current Ogre3d uses CMake for all platforms (Windows, Linux, MacOS and IPhone) and it works really well.
I don't know much about scons in that regard though, I only used to build one library and only in Linux. So I can't compare these two on fair ground. But for our multi-platform projects CMake is strong enough.
I haven't used Scons before, so can't say how that works, but CMake works pretty well.
It works by producing the build files needed for the platform you're targeting.
When used to target VC++, it produces solution and project files so from VS, it appears as if they were native VS projects. The only difference is, of course, that if you edit the project or solution directly through VS, the changes will be erased the next time you run CMake, as it overwrites your project/solution files.
So any changes have to be made to the CMake files instead.
We have a big number of core libraries and applications based on those libraries. We maintain a Makefile based build system on Linux and on Windows using the Visual Studio solution for each project or library.
We find it works well for our needs, each library or app is developed either on linux or windows with cross compilation in mind (e.g. don't use platform specific api's). We use boost for stuff like file paths, threads and so on. In specific cases we use templates/#defines to select platform specific solution (for example events). When is ready we move to the other system (linux or windows), recompile, fix warnings/errors and test.
Instead of spending time figuring out tools that can cross compile on both platforms we use system that is best for each platform and spend time fixing specific issues and making the software better.
We have GUI apps only on Windows atm. so there's no GUI to cross compile. Most of our development that is shared between Windows and Linux is server side networking (sockets, TCP/IP, UDP ...) and then client side tools on Linux and GUI apps on Windows.
Using with perforce for source code version management we find in quite many cases that the Linux Makefile system is much more flexible for what we need then Windows VS. Especially for using multiple workspaces (views of source code versions) where we need to point to common directories and so on. On Linux this can be done automatically running a script to update environment variables, on Visual Studio referencing environment variables is very inflexible because it's hard to update automatically between views/branches.
Re sync question:
I assume you are asking how to make sure that the two build systems get synchronized between linux and windows. We are actually using Hudson on Linux and CruiseControl on Windows (we had windows first with cruise control, when I went to setup linux version I figured Hudson is better so now we have mixed environment). Our systems are running all the time. When something is updated it is tested and released (either windows or linux version) so you would know right away if it does not work. During testing we make sure all the latest features are there and fully functional. I guess that's it, no dark magic involved.
Oh you mean build scripts ... Each application has it's own solution, in solution you setup up dependencies. On Linux side I have a makefile for each project and a build script in project directory that takes care of all dependencies, this mostly means build core libraries and couple of specific frameworks required for given app. As you can see this is different for each platform, it is easy to add line to build script that changes to directory and makes required project.
It helps to have projects setup in consistent way.
On Windows you open project and add dependency project. Again no magic involved. I see this kind of tasks as development related, for example you added new functionality to a project and have to link in the frameworks and headers. So from my point of view there is no reason to automate these - as they are part of what developers do when they implement features.
Another options is premake. It's like cmake in that it generates solutions from definition files. It's open source and the latest version is very highly customizable using Lua scripting. We were able to add custom platform support without too much trouble. For your situation it has support for both Visual Studio and GNU makefiles standard.
See Premake 4.0 Homepage
CruiseControl is a good choice for continuous integration. We have it running on Linux using Mono with success.
Here is an article about the decision made by KDE developers to choose CMake over SCons. However I've to point that this article is almost three years old, so scons should have improved.
Here is comparison of SCons with other building tools.
Had to do this a lot in the past. What we did is use gnu make for virtually everything including windows at times.
You can use the project files under windows if you prefer and use gnu make for Linux.
There isn't really a nice way to write cross platform makefiles because the target file will
be different among other things (and pathname issues, \ vs / etc). In general, you'll probably be tweaking the code across the various platforms to take subtle differences into account, so a tweak to a make file and checking on the other platforms would have to happen
anyway.
Many OS projects maintain Makefiles for different platforms such as zlib where they are named like Makefile.win, Makefile.linux etc. You could follow their lead.