I have no experience with Linux, so this question might seem weird.
I am trying to use a c++ toolbox which has been developed on Debian GNU/Linux Lenny. According to the authors it should work on any recent Linux distribution. However, I need to import it into Visual Studio on Windows.
I have no idea how to get this package configured and built on Visual Studio. I see that there is a "configure" file in the package, but I don't how to use it on Windows. Any help would be appreciated.
You can use either MinGW or Cygwin to mock a *nix system enough to build most *nix software. The configure script is generally a (*nix) shell script which will check to see what interfaces and libraries are available to the application during compilation.
Depending on the library you may not be able to use it outside of a unix library, especially if the library depends on the POSIX (*nix) APIs beyond the very small set which Windows provides.
From your information the package is meant for linux.
This means that if the package contains precompiled code (such as .so or .a - shared libraries / static libraries)you will not be able to run it under windows no matter what (make abstraction of Linux simulated enviroments, I believe you want to run it on a Windows environment).
If the package contains only sources, then you can include the package inside your solution (I would personally go with a static library approach) and try to compile it. You will get some errors when linux specific headers are included (for example linux threading headers).
After finding the windows equivalent for those functions you will be able to compile and use the package on windows as well.
You basically have to do a manual port.
Related
I am attempting to convert the ndn library project found at "https://github.com/named-data/ndn-cpp" into something that can be imported into several existing mfc/wpf/forms Visual Studio Projects (building it as .lib or .dll would work).
As a note, it appears to have previously been converted into c# for windows for a older build of ndn, but is no long supported and will not connect with the current ndn network.(https://github.com/named-data/ndn-dot-net)
I have looked into the using the WSL features that they have added to windows 10, and the Visual studio Linux Cross Platform projects, but these all seem to only be able to make .exes that will run in windows not a .lib or .dll that can be imported into another project.
I have also look into the shared items project but what I was able to find didn't seem like it would work for what I'm trying to do.
Lastly, I tried using cygwin. I was able to compile and generate the linux style libraries(.a) on my windows 10 machine, but when i attempted to generate windows style dlls off the .o files(gcc -shared -o mydll.dll mydll.o) I ran into a large number of reference errors that I was unable to resolve.
Does anyone have any recommendations on which of these methods I should be using or if I should be attempting some other method entirely?
Does anyone have any good references or examples of how to do this for someone with limited Linux experience?
Thanks
Ok. I've tried going about this several ways now, and here's what I've learned that might be useful to someone else trying to do this and also where I stand so far:
If you have a simple Linux dll that you have written it's possible to compile it as a Windows dll using MSYS2 or MINGW, instructions are here: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
If you have something a bit more complicated like the program I'm trying to convert above, there is no quick fix to convert from Linux to windows, however you still might be able to compile your program for windows using Visual Studio.
Here's how you do it:
Download vcpkg from https://github.com/microsoft/vcpkg This is a linux package manager for windows, it will allow you to download windows equivalents to many common Linux packages (for the above I had to download boost and sqlite3)
Create your own unistd.h, here's a link to that: Is there a replacement for unistd.h for Windows (Visual C)?
Get dirent.h for windows, here's a link to that: https://github.com/tronkko/dirent
replace instances of gmtime with _mkgmtime or redefine gmtime as _mkgmtime: timegm cross platform
This got me about 90% of the way there (and from about 13,000 compiler errors to about 30), The rest of the errors so far have been for calls where there is no easy linux to windows conversion and those sections of code have had to be re-written. (In the code above this would be the socket code for the tcp/udp connections in the tranport files, Linux and Windows handle it pretty differently, boost does have a good guide for how to use it's sockets in windows though: https://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html)
So that's it. Hopefully this helps someone else down the line. I'll be adding more to this answer as I discover new things.
I’ve got an app that creates a child process to execute via CLI a compiled C++ library file. What is the best/most portable way of shipping my app with this library? I just need to ensure the compiled C++ code is available on the user’s system and that the executable is compatible with their system.
C++ is compiled for each platform (Windows, macOs, Linux). So you need three different distributions:
Windows - lowest common version (for example Windows 7). You also need to require or include the C++ redistributable for the compiled library.
Linux - most use gcc, so again the lowest common version. No redistributable required.
macOs is similar to Linux.
Each platform supports multiple compilers and IDEs. It’s down to personal choice.
I am trying to build GSL as a library(DLL,lib) to use with my application. I have tested both GSL ports(gladman) to VS and CMake route and I do not want to go that path due to various reasons.
Currently I am using nuget version and I am not too happy about it as some functions are missing. I want to build it myself to be absolutely sure about what I am getting. The objective is to build four set of dll and libs---win32, win32d, win64 and win64d.
I know that from a MinGW library I can build lib file(for VS2015) and thereafter dll using Microsoft LIB tool if I have DEF file available.
My open source experience is very limited. Till now I have successfully built gsl for MinGW using ./config, make, make install. But I am not finding any DEF file generated and I do not know how to utilize this build to generate required DEF and dll to be used with Microsoft Visual Studio 2015.
Thank you
Building and linking has always been a pain for me as well. For mac, I use Homebrew, which downloads frameworks and libraries through a simple one-line-command in the terminal. I would then simply add the library into my program by adding the directory of the libs necessary. In XCode, there was an "add framework/library"-button where I added the directories, but I'm sure there's an analogue in VS.
However, you seem to be using Windows (so Homebrew will not work). I searched the web for Windows versions of Homebrew, and it seems that Scoop is pretty similar. You might want to check that out.
Hope this helped, despite me using different tools :)
I sometimes run into this problem:
1 - I develop a working C++/C program on Ubuntu Linux for Ubuntu, which uses some libraries (which are platform-independent, such as OpenSSL, Boost, GNU Scientific Library, DCMTK, and others: these are generally available from apt-get, and are installed properly).
2 - I would like to also cross-compile the program from Ubuntu to run on Windows, using mingw (x86_64-w64-mingw32-g++).
3 - The libraries are missing from mingw.
Is there a generic way to easily "convert" any library from linux-version (or source-code) into mingw installation so that it can be used to build windows a program? Each library seems to have it's own separate complicated installation instructions for mingw.
You certainly can't convert Linux libraries directly to Windows, since they almost certainly make use of Linux system calls and calling libraries (such as the C runtime library) that are specific to Linux (even if the code doesn't directly call anything else, the compiler may add function calls implicitly, such as memory allocation calls from template functions and such)
You may be able to find "replacement" Windows libraries that you can install, but yes, many probably come with a Windows installer, which makes it hard to install without using either Wine or having a "real" Windows (but then you need that to test your app, so I'm not sure how much hindrance it really is).
Some libraries may be possible to BUILD with the mingw compiler as a cross-compiler under Linux, if they are written in a portable way, which may be an easier choice than installing a ready-made Windows library. But it assumes you can find the sources...
Researching something similar right now and running into issues with libraries like openssl, boost, sqlite, libpcap,...
The best solution have found so far is to utilize WSL2 and Docker.
https://code.visualstudio.com/blogs/2020/03/02/docker-in-wsl2
WSL2 is a Linux environment for Windows (utilizes Hyper-V).
Docker allows you to make containers for both windows and Linux that can talk with each other.
I have the base code I need run under WSL2 in Linux and when I need to access it from windows I utilize docker.
This isn't a perfect solution but I hope it helps.
Some Linux programs can be compiled on Windows via Mingw.
Here is how to set the cross-compiler environment:
How to compile a Linux program with Mingw?
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.