I spent the whole day setting up GCC as per
http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0
On the gcc make step, it told me it needed a c++ compiler to continue for whatever reason,
So I updated Cygwin in the usual fashion and got gcc-c++.
After that, cgywin did me the courtesy of deleting the 3 prereq libraries that I had installed previously,
So I went about remaking them. GMP worked fine, and then I got to MPFR. For whatever reason MPFR is throwing this error:
configure: error: libgmp not found or uses a different ABI.
The resources mention this error here.
I’m pretty sure its finding GMP alright as cygcheck shows it up no problem, and the config even mentions it finds it.
When I try:
./configure --with-gmp-build=/gmp/,
it throws:
error: header files gmp-impl.h and longlong.h not found
So far I have not been able to get MPFR working, despite googling and trying for hours.
MPC also fails to find GMP in the usual manner.
I've also tried just handing the libraries to GCC in a subdirectory and letting it compile them.
When I try that, it gets to the make step, then throws a stage1-bubble error and fails. No description of the error or anything.
I have no idea what else to try.
After compiling and installing gmp, I had the same problem building mpfr until I set correctly the library search path:
export LD_LIBRARY_PATH=/usr/local/lib
export LIBRARY_PATH=/usr/local/lib
export CPATH=/usr/local/include
as it is explained in the http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0
Instead of this:
./configure --with-gmp-build=/gmp/
USE THIS:
./configure --with-gmp-build=/gmp
It doesn't like having the "/" at the end.
I know this post is a bit dated, but I was looking for an answer or results to a similar situation but with much more current versions of the same libraries. While reading this post as for some suggestions as well as other online material I was able to piece everything together. So for anyone who may be working with the newest releases here it goes:
First you will probably want to configure, make and install GMP first for both C and C++ as static libs; also make note of the architecture x86 or x64. Once you run make, make check, make install; and you are confidant that you have no errors, then when you go to configure MPFR you will want to run it as such:
./configure --with-gmp-build=/path/to/gmp --enable-static --disable-shared
and if the paths are set properly this should give you the needed generated make file.
I'm brand new to Unix-Posix environments and commands and new to Cygwin. I've mostly used Windows platforms and very few Macs or Apples. Matter of fact I've only been working at this for a little less than a week as I'm trying to do the same thing. So now I'm venturing into a whole new world of Unix... but it's sort of simulated through Cygwin as I'm still running windows.
I'm trying to build GMP, MPIR, MPFR & MPFRC++ all from the latest original distributions and eventually will try to integrate them into Visual Studio 2017.
I had actually found this post because I was able to build MPIR through visual studio with the help of python and vyasm, but as for GMP I needed Cygwin with GCC. It took me a little while to figure out how to get GMP to build properly but once I did and ran the tests I was able to have all pass with 0 failures. I then started to work with MPFR the same as you.
My similar issue was after I ran ./configure as default, it was giving me the message that the libgmp wasn't found. Also if I tried to call make, it would do nothing as the make file didn't exist. This led me back to doing google searches... While searching for tips, suggestions etc. I came across this Q/A. While I was reading this Q/A, the install files, some other FAQ and even another website, I was kind of able to piece everything together and what I have found that works is what I suggested above.
Not only do you need to set the flag --with-gmp-build but you also need to set the appropriate library types that gmp was built as and you need to make sure that the architecture types match too. They need to have the same matching ABIs.
Ah, just as I was about to finish up typing this answer, make check just finished running through Cygwin and I have a result of:
Testsuite summary for MPFR 4.0.1
============================================================================
# TOTAL: 180
# PASS: 180
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
I hope this helps you out. The only thing is for myself; I'll have to go back and probably run all of this again from the beginning including GMP only because I believe I only did GCC and not G++ and my next step is to try and build MPFRC++.
Then I might try to do some related libraries from here afterwards. My first phase is to try to build them all through Cygwin and GCC/G++. The next step will be to try and port them over to Visual Studio 2017.
You might want to use --with-gmp-lib=/path/to/gmp/lib/dir
Related
I am trying to compile "xz-5.2.1" in MinGW/MSYS environment. I see the following errors:
#error UINT32_C is not defined and unsigned int is not 32-bit.
error: #error size_t is not 32-bit or 64-bit
I am not familiar with MinGW, could anyone shed some light on this? It looks like some macro definition are missing. Some header file missing?
ADD 1
The commands I used to compile the xz-5.2.1 are:
./configure
./make
The error screenshot:
Some background, I am following this link to compile the Tesseract-OCR library. And this is just one of the steps.
ADD 2
Based on the error message, I checked the sysdefs.h file. It contains the following content:
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
The above make output contains the -DHAVE_CONFIG_H, so I think the system header file <config.h> should be included.
But strange enough, I searched the C:\MinGW\include, there's no such file. So I GUESS this may have caused the undefined UINT_MAX warning at line 57. And then the UINT32_C is not defined error at line 58.
But I don't know why the system header file config.h is missing and where to get it.
ADD 3
I dig a bit about the GNU autotools. And luckily enough I find that the following commands can carry on my build process: (Though I am still not very sure why it works. All I know is that it may be related to portability.)
autoheader (this generates the config.h.in file)
./Configure (this generates the config.h file from the config.h.in file)
And now, my build process is blocked by another issue as below:
It seems this is a known issue. And another thread has addressed it.
(I will continue update with my progress.)
If you care for an easier way to handle this kind of dependency management or a general update on toolchain functionality, I strongly suggest switching to MSYS2 with MinGW-w64.
Both projects aim (and succeed) in bringing a better version of the original. MSYS2 comes with a large number of 3rd party libraries that you can easily install. MinGW-w64 allows for GCC with full C++11/14/... support and extended Windows API availability, along with some useful extensions and more up to date headers. You'll notice that most problems originating from system headers will have already been solved, either by the MinGW-Packages scripts below, or upstream (of either MinGW-w64 or the projects themselves).
For you specifically, I suggest the following steps:
Install and update MSYS2.
Open an MSYS2 command prompt (or the 32-bit or 64-bit command prompts if you plan on building 32-bit or 64-bit things) from the start menu entries. Install {32-bit,64-bit} MinGW-w64 GCC:
pacman -S mingw-w64-{i686,x86_64}-gcc
Install tesseract-OCR:
pacman -S mingw-w64-{i686,x86_64}-tesseract-ocr
and optionally the data files:
pacman -S mingw-w64-tesseract-ocr-osd mingw-w64-{i686,x86_64}-tesseract-ocr-eng
And you're done. Of course, you can still compile the various dependencies yourself, but why bother? If you really want to, you can start from the build scripts for the packages you can install in MSYS2, which are located here:
https://github.com/Alexpux/MINGW-packages
Just open the PKGBUILD files and you can see the build steps required. Note that all these scripts assume the dependencies have been installed within MSYS2.
Also note that the installed packages and compilers are all independent of MSYS2 as you'd expect: you can use it only as a tool to keep your development tree up to date, and build from any other Windows environment.
I am using msys2 Mingw (gcc 4.8.2 for i686 32-bit) for building Ghostscript 9.10. After running make, gs.exe was created successfully. Followed by that I ran "make so" for creating libgs library. Libgs.so, Libgs.so.9.10 were created which are of the same file size. But I found both of them to be PE executables. After renaming extension to .exe, they produced the same output as done by gs.exe. What I require is libgs.dll, libgs.a to be created, but instead "make so" creates libgs.so which is in fact a PE executable. I also tried using patch found on site:https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-ghostscript/mingw-build.patch, but still the output remains the same. Has anyone been successful in this? Kindly help me.
I presume if you follow the steps taken in the build script connected to the patch you linked, everything will work out fine. I think most of it is just to make it use the "system"'s 3rd party libraries instead of those in the GS source. I'd guess running the configure command would do.
Alternatively, you could just download the MSYS2 base system from here, and do a pacman -Syu mingw-w64-i686-ghostscript. It should download and install the binary package without you having to build it yourself.
If you really want to build it yourself, download the PKGBUILD and patch, and run makepkg from the aforementioned MSYS2 shell and have that build it for you.
Have just completed testing of gs 9.15 built executables using the a patch
MINGW-packages-master.zip from https://github.com/Alexpux/MINGW-packages
Without implementing the zlib patch and PKGBUILD and using a MINGW 4.7.3 32/64
without by ghostscript used libs installed.
They did not work as is while using msys1 pathe'd up ahead of Windoze.
I simply edited the the MINGW Build and 32/64 bit type in makefile in
and set them to =1 there. and as i built without GTK defined in ./configure
SOC_LOADER_PLAIN manually to gs.c
Check the makefile after ./configure ahead of make or make so though , , .
All went well except for the COMPILE_INITS
mkromfs build that failed so I had to set that to =0 and build without that
feature. For me personally preferred as one can patch the gs fonts and libs
much easier.
The builds run as charm with full cpu optimisers implemented
only disabling gcse and guess-branch-probability, easily outperforming
the binaries provided by http://www.ghostscript.com/ by all means.
HPC !
I am trying to build xmlsec on Windows... I am not an experienced C/C++ developer and not really familiar with the build process if something along the lines of "make ... make install" doesn't do the trick.
xmlsec comes with a Win32 subdirectory, a nice ECMAScript configure.js that takes an optional bunch of parameters and a readme which explains that after running the configure, "nmake ... nmake install" should do the trick. (Obviously it isn't quite that easy or I wouldn't be posting here!)
xmlsec also depends on a number of other libraries (see here for a graphic). I have downloaded the sources for those libraries.
My problem is that I don't know how to arrange those sources, or what to tell the configure.js script, in order to get a build to work.
For instance, the nmake process complains that it can't find "iconv.h" (iconv is one of the required libraries), which is not surprising because there isn't one. Instead there is an "iconv.h.in" and an "iconv.h.build.in"... which I don't know what to do with to produce the required 'iconv.h".
(I am using MS Visual Studio 2010 at the command prompt (which I think is the recommended approach.)
Does anybody out there know how to do this? Any help at all would be very much appreciated.
TIA
Mike Peat
You don't need to build xmlsec, you can directly download the wheel file from this link
https://github.com/mehcode/python-xmlsec/releases
It has all the dependencies installed with it.
have you tried the Msys with Mingw32 compiler? In Msys, you can do make and make install trick. I have successful with Msys in compile xmlsec. If you want to use Msys and have difficulties, I can help.
Anyway, in general, there must be a iconv.h file in the pre-compile folder provided by Zlatkovic (i.e C:\iconv\include\iconv.h). You may want to download again the folder. After figure out where all the dependencies are, put the path in environment path. For your information, I once tried with the configure.js but not successful. Hope that you are luckier than me :D
Hi Kristine (#Kristine T) - (and thanks for getting back to me!)
I had not been doing "make clean", but have now done so ("make clean", followed by "make" - no change in the result though).
The problem I get with the "make" is that it throws an error on compiling "dl.c" saying that "PACKAGE" is undefined (line 295).
I have also had problems using the compiled version of libxml2 - "configure" always says it can't find it (it is there, but...), so I have been using the --with-libxml-src=... parameter to configure, giving it the full source of libxml2 to work with, getting configure to at least finish OK.
I don't have the same problems with openssl or libxslt where I can either tell configure about the compiled version (using --with-XXX={path-to-dir}, or just omit ={path} bit, in which case it seems to find MinGW's own versions, but that doesn't work with libxml2.
Mike
So this is after having dropped $30 for Mac OS 10.7 and having downloaded XCode 4.3.2. After installing the command line tools, the installed version of gcc is still 4.2.4. I need 4.7. I've installed it and set the g++ link in /usr/bin to it. But when I try to compile any program via QtCreator, I get
unrecognized command line option -Xarch_x86_64
I found this discussed in a 3-year-old bug report here, but I really couldn't follow all the different shell commands etc. and my attempt to install liblastfm failed with the same error. The comment here,
The problem is that the GCC/G++ that is normally used to compile stuff
on Macs is actually just a wrapper.
And this wrapper has Mac-Only arguments like -Xarch_x86_64, which then
get converted into the correct args.
Seems like it might be hitting the nail on the head. Aaargh! Surely there has to be some way to get around this?
I created a custom makespec - in QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs, I copied the macx-g++ folder to macx-g++47. I then removed the "include(../common/g++macx.conf)" from that and included it's contents, except for the part that generates the error (i.e. the -X... thing).
I also finished with
QMAKE_CC = gcc-mp-4.7
QMAKE_CXX = g++-mp-4.7
QMAKE_LINK = $$QMAKE_CXX
QMAKE_LINK_SHLIB = $$QMAKE_CXX
QMAKE_LINK_C = $$QMAKE_CC
QMAKE_LINK_C_SHLIB = $$QMAKE_CC
...which is similar to the spec for macx-g++42.
Now, if I add '-spec macx-g++47' to the qmake args, it works.
A lot of effort for something simple...would love to know a better way.
There are several sources for newer gcc versions for OSX. Here is a small selection:
http://hpc.sourceforge.net/ (currently gcc 4.8, previous versions might also be available)
http://gcc.gnu.org/wiki/GFortranBinaries (has gcc 4.7.0 binary installer)
I assume that you did install the command line tools from within Xcode. Apple/Xcode is not always up to date with gcc, stability is more important here than bleeding edge.
I'm trying to build a cross-compiler (x86->64) on my windows system, with the aim of targetting windows 64, however my software currently relies on open source libraries which also have open source dependencies for which there are no prebuilt binaries available with which I can compile. This means that if I want the 64 bit versions I need to compile them.
I've installed MSYS and mingw, I'm also in the process of adding mingw-w64 to the mix so that I can finally compile the libraries in 64 bit form for use with my software. I'm following the steps as closely as I can using these instructions and in the order listed on that page, I'm currently at the step titled "Building the GCC core cross-compiler(s)", but when I try to compile with the line:
$ ../gcc-4.6.1/configure --target=x86_64-w64-mingw32 --enable-targets=all && make -j 6 all-gcc && make -j 6 install-gcc
I get the output pasted here. I should note that I of course snipped the previously executed commands and that last command was the last one listed before all the errors were displayed. Also, I have no idea if it's the cause of all the errors due to the '-j 6' argument, but everything prior to it at least looked successful.
What's the problem and how can I fix it?
Oh, in anticipation of one potential suggestion; no I can't just switch to cygwin.
Edit: Okay after executing them individually, here's the output of the configure command, the output produced by make all-gcc (no -j argument), and config.log. Note, I didn't run a make clean beforehand which may explain the different ending, I didn't do it in the interest of time to write this update, but I suppose I'll just make a different compile folder and re-execute it cleanly to hopefully see the same error as before while I wait for a response.
Edit 2: The make all-gcc failed again as expected, this time the output should help a little more I hope.
Thanks very much for your help.
Your config.log shows that the build process will use the binaries in x86_64-w64-mingw32/bin for stuff like ar, as etc... These are for internal compiler use only, and they should all be available in your /mingw/bin directory. I would strongly suggest asking on the mingw-w64-public mailing list for help.