Feb 152017
 

GCC on CygWin logoStill using my aging XP x64, I recently tried to compile a newer version of the GNU compiler collection (GCC) on my equally aging installation of [CygWin], v1.7.35(0.287/5/3). Reason is that I can no longer update CygWin itself, because the project did away with NT5.x compatibility, so now you need Windows Vista or 7 for the latest version. Given that CygWin uses a rolling release model, you can’t get any “in between” versions later on. Also, despite my best efforts to make use of the great work of Peter Castros’ [CygWin Timemachine], I still haven’t managed to get a later version of CygWin that still supports XP. The later versions all have some kind of massive problem with the bash/sh permanently crashing and coredumping. No idea what the reason is.

And even if it would work, I’d still be stuck with GCC 5.3.0 or 5.4.0 or something. It’s not that I absolutely need a fresh C/C++ compiler right now, but it’s good to be prepared, especially when it comes to the adoption of modern C++ standards. Since I’m doing my own Windows builds of libav and ffmpeg (also: For a new x265-based benchmark project similar to my old [x264 benchmark]), I wanted to be able to use a current version.

On Linux and BSD UNIX, compiling and using a new version of GCC is surprisingly simple! On CygWin however, it bombed for me trying to build the JNI (Java Native Interface), and after disabling it, it stumbled over some mysteriously missing files while I was following [this guide].

Luckily, a commenter named Joaquin provided a [solution] for this: CygWin seems to be missing some prerequisites that need to be downloaded. A script for doing that is included in the ./contrib/ folder of the unpacked GCC source tree, ./contrib/download_prerequisites! Let’s have a look inside:

  1. # Download some prerequisites needed by gcc.
  2. # Run this from the top level of the gcc source tree and the gcc
  3. # build will do the right thing.

Sounds useful… and:

  1. # Necessary to build GCC.
  2. MPFR=mpfr-2.4.2
  3. GMP=gmp-4.3.2
  4. MPC=mpc-0.8.1

Aha! So we’re missing “mpfr”, “gmp” and “mpc”. [mpfr] is a floating-point math library, [gmp] is another arithmetic library, and [mpc]… well, a math library as well. I have no idea why my CygWin would be missing those, or maybe it just doesn’t have the required versions? Uhm, and the following:

  1. # Necessary to build GCC with the Graphite loop optimizations.
  2. if [ "$GRAPHITE_LOOP_OPT" = "yes" ] ; then
  3.   ISL=isl-0.15

[ISL] is optional, but I guess it’s useful? I’m not actually sure what it really does though. Whatever it is, just call that helper script before the configuration stage, and everything should be fine. While sitting inside the root of the unpacked source tree, for GCC version 6.3.0 in my case (make SURE to choose a --program-suffix, or installation might effectively annihilate your platform compiler!), do something like this on your CygWin terminal:

./contrib/download_prerequisites
./configure --program-suffix=-6.3.0 --enable-languages=c,c++ --disable-shared 
make -j12
make install

I’m limiting myself to C/C++ here. I don’t need Fortran (I think) and the JNI component of the Java stuff breaks on CygWin anyway, so we’ll leave Java out. Also, we’ll have no link-time optimization (lto), but the important stuff will be there. The C++ shared library is disabled and I built the thing with -j12 to spawn 12 threads (or is it processes?) for speeding up the build, since I have 12 logical CPUs.

And that’s it!

To test things, I recompiled ffmpeg-3.2.4 with the new GCC 6.3.0 + yasm 1.3.0, and everything turned out just fine after rolling out the resulting ffmpeg.exe including some necessary CygWin libraries (cygwin1.dll and cygiconv-2.dll):

.\ffmpeg.exe -version | find /V "configuration"
ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)
libavutil      55. 34.101 / 55. 34.101
libavcodec     57. 64.101 / 57. 64.101
libavformat    57. 56.101 / 57. 56.101
libavdevice    57.  1.100 / 57.  1.100
libavfilter     6. 65.100 /  6. 65.100
libswscale      4.  2.100 /  4.  2.100
libswresample   2.  3.100 /  2.  3.100
libpostproc    54.  1.100 / 54.  1.100

A quick test showed the ffmpeg binary can cleanly decode H.265/HEVC video and also other stuff like FLAC, so it’s looking good! :)

Jan 272016
 

HakuNeko logoJust yesterday I’ve showed you how to modify and compile the [HakuNeko] Manga Ripper so it can work on FreeBSD 10 UNIX, [see here] for some background info. I also mentioned that I couldn’t get it to build on CentOS 6 Linux, something I chose to investigate today. After flying blind for a while trying to fix include paths and other things, I finally got to the core of the problem, which lies in HakuNekos’ src/CurlRequest.cpp, where the code calls CURLOPT_ACCEPT_ENCODING from cURLs typecheck-gcc.h. This is critical stuff, as [cURL] is the software library needed for actually connecting to websites and downloading the image files of Manga/Comics.

It turns out that CURLOPT_ACCEPT_ENCODING wasn’t always called that. With cURL version 7.21.6, it was renamed to that from the former CURLOPT_ENCODING as you can read [here]. And well, CentOS 6 ships with cURL 7.19.7…

When running $ ./configure && make from the unpacked HakuNeko source tree without fixing anything, you’ll run into this problem:

g++ -c -Wall -O2 -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -o obj/CurlRequest.cpp.o src/CurlRequest.cpp
src/CurlRequest.cpp: In member function ‘void CurlRequest::SetCompression(wxString)’:
src/CurlRequest.cpp:122: error: ‘CURLOPT_ACCEPT_ENCODING’ was not declared in this scope
make: *** [obj/CurlRequest.cpp.o] Error 1

So you’ll have to fix the call in src/CurlRequest.cpp! Look for this part:

  1. void CurlRequest::SetCompression(wxString Compression)
  2. {
  3.     if(curl)
  4.     {
  5.         curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, (const char*)Compression.mb_str(wxConvUTF8));
  6.         //curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, (const char*)memcpy(new wxByte[Compression.Len()], Compression.mb_str(wxConvUTF8).data(), Compression.Len()));
  7.     }
  8. }

Change CURLOPT_ACCEPT_ENCODING to CURLOPT_ENCODING. The rest can stay the same, as the name is all that has really changed here. It’s functionally identical as far as I can tell. So it should look like this:

  1. void CurlRequest::SetCompression(wxString Compression)
  2. {
  3.     if(curl)
  4.     {
  5.         curl_easy_setopt(curl, CURLOPT_ENCODING, (const char*)Compression.mb_str(wxConvUTF8));
  6.         //curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, (const char*)memcpy(new wxByte[Compression.Len()], Compression.mb_str(wxConvUTF8).data(), Compression.Len()));
  7.     }
  8. }

Save the file, go back to the main source tree and you can do:

  • $ ./configure && make
  • # make install

And done! Works like a charm:

HakuNeko fetching Haiyore! Nyaruko-san on CentOS 6.7 Linux

HakuNeko fetching Haiyore! Nyaruko-san on CentOS 6.7 Linux!

And now, for your convenience I fixed up the Makefile and rpm/SPECS/specfile.spec a little bit to build proper rpm packages as well. I can provide them for CentOS 6.x Linux in both 32-bit as well as 64-bit x86 flavors:

You need to unzip these first, because I was too lazy to allow the rpm file type in my blogging software.

The naked rpms have also been submitted to the HakuNeko developers as a comment to their [More Linux Packages] support ticket which you’re supposed to use for that purpose, so you can get them from there as well. Not sure if the developers will add the files to the projects’ official downloads.

This build of HakuNeko has been linked against the wxWidgets 2.8.12 GUI libraries, which come from the official CentOS 6.7 package repositories. So you’ll need to install wxGTK to be able to use the white kitty:

  • # yum install wxGTK

After that you can install the .rpm package of your choice. For a 64-bit system for instance, enter the folder where the hakuneko_1.3.12_el6_x86_64.rpm file is, run # yum localinstall ./hakuneko_1.3.12_el6_x86_64.rpm and confirm the installation.

Now it’s time to have fun using HakoNeko on your Enterprise Linux system! Totally what RedHat intended you to use it for! ;) :roll: