Can anyone suggest a multiple precision library that comes with pre-built windows binaries. I need to use it use with an existing Visual Studio 2010 project (or where I can get pre-built binaries for win7 64bit for GMP).
I have tried and failed to compile GMP and MPIR and other projects none of them work with various frustrating and ambiguous errors. Unfortunately time pressures are getting to me and what I need to implement is simple if I can get the library built/downloaded.
I need floating point support so a bigint library is not enough.
Thanks,
http://www.cs.nyu.edu/exact/core/gmp/ has the following package with dlls:
dynamic GMP library and header file for Visual C++: gmp-dynamic-vc-4.1.2.zip
They also have the source project files if you want to try recompiling with a different version at some point.
Your best bet is MPIR. I've built MPIR and MPFR using VS 2010 so it is possible. My Windows system is down at the moment but here are some notes I made.
Download MPIR, unpack, and rename directory to just be "mpir" - remove any version numbers.
Find and follow the readme file that documents installing VSYASM.
Run "mpir_config.py" with Python 3.x to create the project files.
Change the number of parallel builds to 1.
Select a particular target (say "lib_mpir_k8") and it should build.
MPIR also includes a couple of batch files so you can do a command line build using configure.bat and make.bat. I find it is easier than the GUI builds.
IIRC, to build MPFR, I had to modify some of the Include directories but my notes are a little too cryptic.
The MPIR mailing list is quite helpful, too.
Related
I'm attempting to add Oauth2 to an existing program. The program uses C, and is compiled on a Windows machine using Visual Studio 2010. I believe I need the Iddawc library, recommended by Okta, but they do not provide pre-built libraries, and the code is designed to be built on various flavors of Linux.
I tried downloading Make for Windows, but despite there being a Makefile, when I run it, I get this message:
make: *** No targets specified and no makefile found. Stop.
I've also attempted to include the library files in the existing project (an ugly, temporary solution at best), but this sends me down a seemingly unending chain of other libraries that are required and does not appear to be a feasible option.
Is there a (hopefully simple) way to get this library to build on Windows?
For iddawc, you could try building with MinGW-w64. The easiest way to do that is by installing MSYS2.
An alternative that might work for you is liboauth2. At a glance, there's some Windows code in their codebase.
I have a tool in C that needs libpng, zlib and lcms libraries. On unix I get these dependencies via pkg-config, but on Windows I can't rely on it, so for users building the library it's a massive hassle to obtain and build these dependencies manually.
How can I automate obtaining these dependencies in the most Windows-native way? I know MinGW helps, but that's a bit of a cop-out. I'd like to learn how to do it with the Microsoft toolchain.
Is there any point in searching for shared non-Microsoft libraries on Windows, or should I go straight for statically linking my own?
If I were to download and build the libraries as part of my build script, what should I use? (nuget? curl? ftp.exe?)
It seems like Microsoft is discouraging use of NuGet for C? https://github.com/Microsoft/vcpkg/blob/master/docs/about/faq.md#why-not-nuget
I recommend looking into Nuget. It's fast becoming the Microsoft standard for these sort of things. A lot of people think Nuget is just for .NET, but it works great for VC++ too. I have had a great deal of success setting up Nuget servers in my company to serve headers and compiled libs, and I've gotten all of our automated build systems to create these things automatically. I'm not going to spell out all the details here, but it basically comes down to performing your build, creating an MSBuild XML snippet to set up the precompiler and link options automatically, and then packaging all those bits (headers, libs, XML) in the correct way. When done correctly, it's just a two step process to use an existing package in a new project -- establish the Nuget reference and then add the #includes into your code. You don't even need a server -- you can source them directly from a directory of your own control.
https://learn.microsoft.com/en-us/nuget/create-packages/native-packages
I want to create native C extensions to PostgreSQL 9.5 64bit on Windows.
I would love to build them with MinGW-w64 if that's possible, to get my build chain as clean as possible. But I am using the EnterpriseDB build of PostgreSQL, and MinGW build crashes it.
It would also be okay if there is another free compiler that I can use in this commercial project.
I know how to get this to work with Visual Studio 2003 Express but that doesn't seem to be a solution because of License issues.
Addition to the Main Answer
In the article linked below, you can read that it is possible to write C modules using Mingw or Cygwin, and some guidelines regarding the same. However I highly discourage doing so, mostly because of the reasons listed below, and also because that page mentions that those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems
Here is the full excerpt on Unix-like Platform:
Unix-like Platforms
PGXS originated on Unix-like systems, and it is easy to use there. Unpack the extension module archive and run these commands in the resulting directory:
make PG_CONFIG=path_to_postgresql_installation/bin/pg_config
make PG_CONFIG=path_to_postgresql_installation/bin/pg_config install
You may omit the PG_CONFIG overrides if running type pg_config in your shell locates the correct PostgreSQL installation. Subject to the ownership of the existing PostgreSQL installation directories, the second command will often require root privileges. These instructions also apply when building for Windows using the MinGW or Cygwin compilers. However, those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems.
A common mistake is to specify the PG_CONFIG=... on the command line before the 'make', which does not work as the value is then overridden by the inner workings of makefiles.
It's important to know that different compilers are not compatible with each other. Each of them have different runtime libraries. So it is very risky to compile extensions with a different compiler other than the one used to build the software you are using.
Postgresql's Windows build uses Visual Studio, same with EnterpriseDB (as far as I know). You will need to use the same compiler to build your extensions.
(For more information please refer: Building and Installing PostgreSQL Extension Modules and Postgres Enterprise Manager Installation Guide - EnterpriseDB (PDF))
This should explain why your extensions compiled with Mingw-w64 crash.
Luckily, there are two solutions you could choose:
Use Microsoft Visual Studio Community. It is completely free for individual developers, however there are restrictions for businesses. It should compile proper modules for your Postgresql build.
Rebuild the compleat Postgresql binary with Mingw-w64 or any other compiler of your choice (LLVM/Clang maybe), and then compile extensions with the same.
Doing either of these should help you. And this applies to all platforms, languages, and other softwares too. If you want to build extensions for a software, you need the same compiler, on the same platform used to build the software being used.
So, if you want to build extensions for Postgresql on Linux, you need the same compiler (probably GCC) to build extensions.
Happy coding =)
#Swith give you link to docs how to build PostgreSQL Extension Modules with Visual Studio and as you can read:
These instructions also apply when building for Windows using the MinGW or Cygwin compilers. However, those Windows configurations have special needs and receive lighter testing than most; expect a greater incidence of build problems.
A common mistake is to specify the PG_CONFIG=... on the command line before the 'make', which does not work as the value is then overridden by the inner workings of makefiles.
Did you check this ?
Also you can read other docs Building PostgreSQL With MinGW - maybe this help you more.
It would also be okay if there is another free compiler that I can use in this commercial project.
Did you check C compliers list on wiki - in particular, you can check Cygwin compiler - it's mentioned in docs above and it's free.
I know how to get this to work with Visual Studio 2003 Express but that doesn't seem to be a solution because of License issues.
What kind of issues do you see ?
Maybe check Visual Studio 2015 Community Edition (not Express) like #Simon Mourier suggest.
There is quite different licencing between Express and Community editions - I'm not sure about details, but as far I know Community Edition is more flexible for using in commercial projects:
For organizations:
An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.
For all other usage scenarios:
In non-enterprise organizations, up to five users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.
For more information, see the Visual Studio Community license terms.
i want to compile a 'c' code and create an executable from my application. as of now i do it by specifying the path of my compilation .exe (c++) present in the bin folder of my Dev-Cpp folder.
it works fine but i need to pack the compiler along with the application so i wanted to know what files and folders are needed so that i can compile it directly from the application.
what are the files needed exactly i.e. headers,the compilation application, libs and what else...
any help?
If you're asking how to create and distribute a project which is able to build upon an existing compiler for its functionality, there are packages you can find which are just the compiler portion without the IDE. Minimalist GNU for Windows is such a package:
http://en.wikipedia.org/wiki/MinGW
(In fact, when the people who put together Dev-C++ wrote their integrated development environment, they get the actual compilation functionality from MinGW...which they bundled into their package for good measure. So if you were going to write an IDE of your own, you would start from the MinGW distribution...not by trying to hand-pick files out of Dev-C++.)
One issue to be sensitive to is licensing. While there are not generally any legal issues out of the box regarding distributing executables built with a system like MinGW, when you go as far as to include the compiler in your own "product", it might be tricky. Dev-C++ is under the same license as MinGW (GPL) but I'd imagine there'd be issues if it were not.
If you only need a subset of the full functionality (let's say you only compile C and not C++) there will be a lot of header files and such that you could cut out. But you have to trade off the difficulty of maintaining this sort of optimization vs. just having your program ask users to install MinGW and then tell your program where they installed it. It might take up more space and lead installation to be a two-step process...but frees you from a large number of concerns.
So that's what I would suggest: Have a setting in your program (much like Dev-C++ does) which lets people specify where the MinGW binaries are installed on their system. But let them install it independently.
We have a large C project with development happening on Linux, Mac OS and Windows. Most of our Windows developers use MSVC -- for example, the free edition of Visual C. Oftentimes .c source files are added, renamed or deleted, and we find it very frustrating to keep the Visual C project in sync with these changes to directories.
Developer A might add newfile.c, check it in to Subversion and happily continue work.
Developers B, C, etc. update to the latest revision. Then when they compile in MSVC they get an error (buried somewhere in the huge compile output) saying the linker can't find such-and-such symbol. They then need to look to see what files have changed and manually add that to the project tree in MSVC.
(Developer A might be on Unix where build scripts tend to automatically find the right files to compile, and not realise how much work they've just created for B and C!)
My question is, is there a way to tell MSVC to consider every .c file in a directory as part of the project?
Update We have build scripts that can create initial MSVC project files. But there's a signicifant amount of customisation that gets done after this (pointing to libraries, etc.) which would be blown away each time the scripts were rerun merely to add a new file.
Given how many large projects there are out there, I'm kind of surprised Visual Studio requires such manual work by each developer just to pick up new files added by others.
I'm going to optimistically hold out for a better solution for now...
I don't think Visual Studio can do what you want (but would be glad if I'm proved wrong!).
What works for me is to use cross platform project files. Take a look at CMake, which allows you to define the structure of your project in a platform independent text based format. Then on each platform these project files are processed with a tool that then automatically generates the appropriate thing, which could be Makefiles, Visual Studio solution and project files, etc.
If this is really a serious problem, I would recommend writing a script which updates VS project file accordingly with directory contents.