This page contains patches, compiling and building tips and work-arounds to use when building Open Source software on various platforms. I used to just send the patches back to the original authors. However, there are now so many abandoned Open Source projects out there and quite a few projects where authors do not support certain platforms, that there is really no place to send some of these patches and work-arounds. I have tried sending information to related wikis or mailing lists or to the authors whenever possible. I am placing it here as well for my own reference. It's offered as is, unsupported and may or may not work on your particular system. In the spirit of Open Source I wanted to share it so others would not have to repeat the same work I did when trying to get some of these applications to build. I will be switching over to offering build scripts along with these packages as time allows in order to make it easier to reproduce these changes. See my mingw information on package management and build tools if your curious about a few more details on the switch.
My latest build scripts using the LM BLD system including related patches and sed commands are being added to an archive.
Before you try to compile and build Open Source programs on your system it is important to have the proper setup. If you're building these on Linux, odds are you already have a C/C++ compiler and many of the basic libraries you'll need. If you are on Windows, you can download and install the MinGW compiler. Follow the instructions in My MinGW FAQ to install. You can download basic needed libraries from the mingw site, gnuwin32 site and other sites mentioned in the FAQ. On either system, you'll probably want to set up a .profile file with some basic compiler settings. You can use the one in My MinGW FAQ on Linux as well as long as you fix any paths to reflect the ones on your own system.
The system most Open Source programs use for building requires that you
run ./configure, make, make install. Most programs have INSTALL and README files that will tell you if you need to do anything else special. Some programs only require a Makefile, so you only need to run make. A few programs I ran into needed imake (only supplied Imakefile not Makefile). I had to use the command xmkmf to create the makefile before I could run make on them. Some programs use special, non-standard make programs to install. You may need to download those programs to build successfully. Hopefully, the documentation with the programs covers these special cases.
In a few cases on Linux, I needed the XML::Parser library for Perl in order to get configure to work. If you need it, you'll see it ask for that dependency when you run ./configure on a program. You can download the compressed tar file for it from the web. Once uncompressed, you can install using perl Makefile.pl, make, make install. Windows users, if a program needs Perl for any reason, you can download and install a copy of Activestate Perl. It's very easy to install and use on Windows.
One way to categorize programs is by what GUI libraries they require. Often the GUI libraries are a good portion of the program's code. If you're trying to save hard drive space on Linux (or with portable windows applications), it's important to judiciously choose which GUI libraries you want to install and which you'll need to run the applications you want.
Had no trouble compiling ftlk version 1.1.9 on Windows and Absolute Linux. However, on DeLi Linux which has an older gnu compiler and uses uclibc instead of glibc, I had to make a change to get fltk to compile. I had to edit the file Fl-BMPimage.cxx file in the src directory and change line 375 to:
uchar b=getc(fp); uchar a = getc(fp);
I was able to get glib for GTK+ 3 to build on Windows. However when I reported the issues I was having that I had to patch to get it working properly, I got a very negative response from GTK+ support. I had hoped to share my efforts so that other developers did not need to hit the same problems I did. Unfortunately, this did not work out. I do not want to expend my time and effort to support communities that are hostile to certain developers (such as Windows owners). I, therefore, will not be sharing any patches for GTK+ unless this situation changes. I do not recommend GTK+ as a cross platform GUI at this time. I highly recommend other GUI libraries in its place. I will be switching over to applications that use other libraries and recommending them instead.
Utilities like zip, unzip, gzip, tar, bzip2 appear to build on the systems I've tried with no problem. For p7zip on Posix systems, I downloaded the latest version and ran ./configure all3, make and make install. It worked without a hitch. You may also find pre-built executables available. If your mahcine is using BusyBox (usually on Linux) to supply some of the system utilities, you may want to install Info-zip's zip and unzip utilities. The BusyBox version of unzip didn't seem to be able to handle typical zip files when I tried it.
I attempted to compile gsar which is a command line general search and replace program on some Posix systems. You can find a copy of the source and a Windows executable at the gnuwin32 site on Sourceforge. On Linux, it builds fine as long as the .res file (can't compile an .rc file into a .res file on this system) is left out.
First thing to get working once you have your basic tools in place is some kind of text editor or programming editor. I've used nano on several systems and if you need a very basic editor, it works well.
SciTE is my current programming editor. I use it most of the time for text processing. It's slowly been replacing my word processor for most tasks involving documents. On Windows, you can just download the executable for SciTE and use it. The program is extremely customizable, so chances are you'll need to edit the User Options file (SciTEUser.properties) and get it to a point where you're comfortable with it before you can make full use of it. One of things I look for in a word processor is the ability to customize key mapping and SciTE on Windows provides that along with many, many other features. You can check my article on SciTE tips for more information on how to customize the program.
For DeLi Linux, I downloaded version 1.76 along with the Scintilla library. I had to change a line in SciTEGTK.cxx which can be found in the SciTE source code under the GTK subdirectory. This is most likely because DeLi Linux was not using the most up to date versions of the GTK libraries. I commented out lines 850-852 and line 854 because earlier versions of the gtk libraries did not include gtk_window_present_with_time.
// if (end != timestamp && errno == 0) {
// gtk_window_present_with_time(GTK_WINDOW(PWidget(wSciTE)), ts);
// } else {
gtk_window_present(GTK_WINDOW(PWidget(wSciTE)));
// }
After that change, SciTE compiled, but it still wouldn't run. I was getting an error regarding the pango library. To fix that, try the following:
pango-querymodules > /etc/pango/pango.modules gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules
You may not need to run all three of these. They generate (possibly) missing files that you'll need to get the pango library to work properly. (Some other systems have pango-querymodules-32 (or 64) instead.)
Older versions of Scite have a configure option so that it can build with GTK+1 or GTK+2. If you're on a distribution where you're trying to stay with GTK+1 programs only, you can look for an older version that will still build with that library.
On Absolute Linux, SciTE compiled, built and came up with no issues. SciTE comes up much faster on my Windows machines (even on my laptop running Windows) than it does on my laptop running Linux. All Linux and FreeBSD systems I tried SciTE on had issues with the key mapping feature (user.shortcut settings). On DeLi Linux, key mapping didn't work at all. On Absolute Linux, it works but not if you're using the Alt key. Since I have the source, I've edited the SciTEGTK.cxx file in the gtk directory and changed some of the default menu keys to some of my favorite shortcuts wherever possible. If someone knows of a better work-around, please share it.
SciTE on Linux appears to print to a2ps. However, this is also customizable. I saw a mention on the web of someone using enscript with SciTE in place of a2ps as an alternative program to render files to Postscript format for printing. Also on Linux, the default at one point was to bring the help up in the Netscape browser. You're probably going to want to change this too. Some alternatives may be lynx or links -g.
If you want an integrated spell-checker for Scite, read the next section about aspellstdout.
I created a program called aspellstdout to output spelling errors for a file to stdout using the GNU gcc compiler error format. The purpose of the program was to provide easy integration of spell-checking abilities within programming editors. It uses the aspell spelling library. I have since switched to Hunspell for its superior cross-platform support and easier use. Also, the maintainers have been nice enough to integrate my patches directly into the program.
If you still want to build aspellstdout, here are the steps. I used aspell-0.60.6.tar.gz and aspell6-en-6.0.0.tar.bz2. If you're building it on Windows, you can check my patches to aspell for a list of steps I had to take to get this to work.
Once all the files are installed, you can create the spelling program. You'll need the source code for aspellstdout.c. Download it and save as aspellstdout.c. I compiled the program straight from a command prompt and didn't even use msys. Compile aspellout.c with mingw using the following command (typed all on one line):
g++ -o aspellstdout.exe aspellstdout.c -I\mingw\msys\local\include -L \mingw\msys\lib -L \mingw\msys\local\lib -ldl -laspell -lintl -lgettextlib.dll -ldl.dll
If you're on Linux, the procedures is very similar. At the command line, type (all on one line):
g++ -o aspellstdout aspellstdout.c -I/usr/local/include -L /usr/lib -L /usr/local/lib -ldl -laspell -lintl
That should give you a working spell-checker that you can integrate with a programming editor or use from a command line. You can run it using a command similar to:
aspellstdout filename
I now recommed Hunspell over Aspell for, among other things, its superior cross-platform portability. You may also be able to find a fork of Aspell from the Abiword or Lyx developers if they're still using the library. Both applications work cross-platform and need the tools they use to do so as well. The original Aspell has no support for Windows. However, the fork is supposed to support this platform. The other option is to use the patches below to build aspell on Windows using mingw. On Linux, aspell appears to build okay as is.
Download aspell source code and dictionary files. I'm using aspell-0.60.6.tar.gz and aspell6-en-6.0.0.tar.bz2. When building it on Windows, you'll need mingw and msys. Check out My MinGW FAQ for details. You'll also require the following libraries which can be installed from prepared developer packages or you can build and install them from source code. You'll need the latest copy of PDCurses from Sourceforge. You'll need basic libraries like libiconv and libintl from the gnuwin32 project on Sourceforge and you'll need the latest version of libdl from Google's code library.
You need to build and install aspell and the dictionary files you want (using ./configure, make, make install). I had to apply the following patches to the aspell code on Windows before I could get aspell to make:
\mingw\msys\bin\diff \mingw\msys\home\old\aspell-0.60.6\common\config.hpp \mingw\msys\home\new\aspell-0.60.6\common\config.hpp 15a16,19 > #ifdef __MINGW32__ > #define libintl_printf printf > #endif > \mingw\msys\bin\diff \mingw\msys\home\old\aspell-0.60.6\common\file_util.cpp \mingw\msys\home\new\aspell-0.60.6\common\file_util.cpp 15a16 > #include "asc_ctype.hpp" \mingw\msys\bin\diff \mingw\msys\home\old\aspell-0.60.6\modules\speller\default\language.cpp \mingw\msys\home\michaelsl\new\aspell-0.60.6\modules\speller\default\language.cpp 23d22 < #ifndef __MINGW32__ 26d24 < #endif
There are several versions of StarDict, so you can usually find one version that will build and work on your system. There's an executable available for Windows, but there are also two portable apps versions available for Windows. I happen to prefer the portable versions. There's a command line version sdcv which I've been able to get to compile on DeLi Linux and Windows. You can also use the configure directives to compile with or without the Gnome dependencies. I personally prefer without since it's more lightweight. There are alternatives to StarDict and sdcv that don't require GTK+ libraries and I highly recommend using an alternative at this time.
You'll need the GTK+ libraries to build this. Even with them installed, I was still having problems. I finally fixed the issue with the configure file by using export PKG_CONFIG='/usr/bin/pkg-config'. Depending on what system you're on, be sure to set this to the proper path to find pkg-config. You can type and enter it on the command line before compiling or add it to your .profile file.
Timidity is a midi player and records midi files to wave. I've managed to build it on Windows and it doesn't require too many special libraries to do so. The one trick about building Timidity is to specify the proper options when you configure. On Linux, I used
./configure --enable-interface=ncurses,motif,emacs,vt100,xaw,gtk --enable-spectogram --enable-wrd. On Windows, specify the ncurses, windows and possibly the gtk options instead. Timidity uses pdcurses, my favorite curses library on Windows in place of ncurses. If you're on a POSIX system be sure to include the xaw version if you want the best Karaoke midi support. That particular interface had the most work done on timing of lyric displays last time I checked. The other tricky thing about Timidity is that you need to customize it to get the most out of it. You can download quality soundfont files from the Freepats web site or some of the Timidity web sites. There's more information on that in my article, Recipes for Music on your PC. You have to set the .cfg file(s) properly or you won't hear the instruments from the soundfont files. You also have to specify on the command line or in a shell or batch file what settings you want to use to run Timidity. Certain settings change the interface or the sound quality or slow down or speed up parts of the execution so that you can see the words for Karaoke midi file lyrics display better. Check Tim Brechbill's Timidity site for a Timidity configuration tool, some sample batch files and links to soundfont files. The site is geared to Windows users, but the information and soundfont files are useful even if you're on another operating system. You can always use the configuration tool and fix the directory paths to be compatible with your system.
If you're going to be playing Karaoke midi files (especially those created by ABC notation), there is a patch available for timidity to better handle these files. I posted to the timidity-talk mailing list on Sourceforge asking about patches for displaying Karaoke midi files and someone was nice enough to create one and post it to the mailing list. For ages, the latest version visible at Sourceforge was dated back at around 2004. However, the program was being actively maintained and patched. Luckily for us, there's now a later version tarball available at Sourceforge. So, you no longer need cvs tools to download a version that's been patched for Karaoke midi. The Karaoke midi patch for ABC files was listed in the April 2008 archives of timidity-talk if you need more information on it. However, it should hopefully now be integrated in the latest tarball at Sourceforge.
I got gramofile to compile on DeLi Linux without any issues. To build it properly, I needed to add -lm to the list of libraries on line 16 of the makefile in order to add the math library in when gramofile builds. There is no install file, but I copied, gramofile and the two programs it works with to a bin directory. All three need to be in your path when you run them. This program has tools to help move phonograph records over to your PC including a pop filter for audio files.
I managed to get rezound to compile and build on DeLi Linux after much effort. This takes a long time to build on older operating systems even if there are no errors. I don't recommend using it on older machines unless you don't mind that it comes up slowly. Rezound is a wave editor using the Fox Toolkit for a user interface. To get it to build with DeLi Linux or a Linux distribution that uses uclibc, make the following changes in files. In the subdirectory src/frontend_fox in files CMainWindow.cpp, CMetersWindow.cpp, drawPortion.cpp FXConstantParamValue.cpp, replace the function round with rint. Don't do a global search and replace without checking what you're changing or you'll replace some foreground/background commands too. At line 50 of FXWaveCanvas.cpp I added:
#include <math.h>
Go to the subdirectory src/backend. In the file CSound_defs.h, change line 55 from #define sample_FPOS_ROUND(C) (nearbyintl(a)) to
#define sample_FPOS_ROUND(C) (rintl(a)). Change line 73 from
#define sample_FPOS_ROUND(C) (nearbyint(a)) to
#define sample_FPOS_ROUND(C) (rint(a)). Add the following line
in both CGraphParamValue.cpp at line 222 and in the subdirectory src/misc/CNestedDataFile in the file anytype.h line 144:
#define isnan(x) ((x) != (x))
This is a program that can quickly display a graphic from the command line. It requires both the SDL library and the SDL_Image library to build. If you're on Windows, just download the executable. Otherwise, you'll need Cygwin to try to get this one to build. For Linux, I downloaded version 1.2.6 of that library and I'm using picaxo-27.03-2008-20.41. Go to the directory where you unpack the picaxo program and cd to the src directory. Type make. Then cd to the bin directory and run it with the name of the picture via the command line. There's no help or command line help and there's no install. You need to move this to your path (such as /usr/local/bin) if you want to access it from another directory. I added the viewer to my File Manager so I could call up and view pictures with it quickly.
At one point, the imlib2 library (from the Enlightment project) was strictly for Linux machines or machines that support standard Posix libraries. I've read that there has been a port to MinGW and msys on Windows, but haven't had a chance to test it out. There are some graphics tools built on the imlib2 library that look interesting. They include feh, gozer and scrot. They need the giblib library also at that site in order to compile. Both scrot and gozer are command line tools. One is for image capture and the other for text rendering. The feh program is an image viewer. It can also set background images for your desktop (window manager). To build imlib2-1.40 on DeLi Linux, cd to the src directory and edit color_helpers.c. For every instance of round that your text editor finds, replace with (long int)rint. Other versions of Linux should just be able to build as is. To build giblib, make sure the following environment variables are set:
export LD_RUN_PATH='/usr/local/lib' export LD_LIBRARY_PATH='/usr/local/lib'
Once the libraries are built, the programs should compile without incident.
The program flphoto compiles without issues on the Linux systems I've tried. For Windows users, I was able to compile and build flphoto (and espmsg, fldcraw, testexif) on Windows using mingw32 and msys. I did have to make a few changes though. The slideshow part had X Windows specific code, so was unable to get testslideshow to build. I did test out the picture clipping and red eye filter options in flphoto.exe in Windows and they work beautifully. That's all I've tested so far. Below are diffs created using msys's diff program.
Made a change to fldcraw.c:
61a62 > #define getc_unlocked(s) getc(s)
Since there's no fork command for mingw, I replaced it with a spawnlp in Fl_CRW_Image.cxx as follows:
35a36,39
35a36,39
> #ifdef WIN32
> #include <process.h>
> #define waitpid(a,b,c) cwait(b,a,c)
> #else
36a41
> #endif
59a65,72
> #ifdef WIN32
> if ((pid= spawnlp (P_NOWAIT, "fldcraw", "fldcraw", name, (const char*) 0)) < 0)
> {
> return;
> }
> else
> {
> #else
72a86
> #endif
74c88
< if (waitpid(pid, &status, 0) < 0)
---
> if (waitpid(pid, &status, WAIT_CHILD) < 0)
Vstrip is a command line program to pull VOB files off a DVD and demux them. I found version 0.8e at Sourceforge. There's a later version, available from Gentoo portage. Using the supplied makefile, vstrip compiles with errors on DeLi Linux. Took me a while to find out I could safely ignore the errors. To create the executable, edit the makefile and add -lm to the line that builds the program from the object (.o) files. It needs the math library to build. (That was part of what it was complaining about during the compile.) There's a prebuilt copy of vstrip 0.8f available for Windows.
I wanted to get DVDStyler to compile. This would be tricky because I like and am still using an older version on Windows. The newer versions aren't backwards compatible. Turns out the older versions use netpbm and the newer ones use wxSVG. I guess that's why my XML configuration files from DVDStyler 1.4 don't work with later versions. If anyone knows a work-around to update the XML configuration files to the later versions, please let me know about it. I haven't been able to convert the projects I've created to date, so I haven't wanted to switch over to later versions. Turns out, that's good news on the DeLi Linux front, because I can't get the latest version of wxwidgets to build as a useable library on DeLi anyway. I compromised by getting an older version of wxwidgets (2.6) that still works with DVD Styler 1.4. Despite the fact that DVDStyler is built on top of GTK+ 2 and wxWidgets, it still comes up fast on my machine and on its own (not counting all the libraries) is a somewhat small program. There are now versions of wxWidgets for Linux that build directly on X Windows or on SDL that will work even more efficiently than the version built on top of GTK+ 2. DVDStyler is based on the command line authoring tool dvdauthor, so you'll need that tool in order to get DVDStyler to work. It did also require mpgtx, but be sure that you use the latest copy of it (at the time, 1.3.1) or you will be unable to get it to build on Linux. Version 1.3 would not build at all. Besides mpgtx, mjpegtools and cdrtools, you'll also need netpbm (or wxSVG for later versions), the GTK+ 2 libraries and wxwidgets 2.6 (I used 2.6.3.2.1.4 source from another distro) to get DVDStyler up and running. On Absolute Linux, it already has wxWidgets 2.8.7 intalled by default, so my favorite version of DVDStyler will not run. You can download a prebuilt slackware package for a later version of DVDStyler. Windows users can find the latest executables (and possibly earlier ones like 1.4) at the DVDStyler Sourceforge site. The Windows version comes with all the tools such as mpgtx, mjpegtools and dvdauthor prebuilt and included. You don't want to try to build this one all by yourself on Windows unless you have Cygwin installed. Many of the supporting tools require building them with Cygwin in order for them to work properly.
I compiled Xine, a multimedia player. There are a few ports of older versions of the library to Windows. However, the port I tried didn't seem to work well with my video card. I got libxine to build (from the same Windows source) on DeLi Linux. Two out of the many GUI options available for Xine are toxine (command line) and flxine (fltk). The toxine GUI builds without incident and only requires curses library for the interface, but is not very user friendly. The flxine option uses fltk as its GUI library but also includes some X Windows specific graphics functionality, making a port to Windows without Cygwin difficult. When building xine on a machine that uses the uclibc library instead of the more standard glibc, there's a library issue between uclibc and the xine library. There's an error message that says it can't resolve lrintf. Xine compiles and builds fine separately, but not when you try to use it with the GUI front end, you get an error after the fact. Information at the site that supports uclibc indicates that they're aware of the bug and that this issues is closed. I'm guessing (hoping) it's fixed in later versions of uclibc. However, I didn't see any real work-arounds mentioned at the site. To get xine to work with flxine, I went into the xine library directory. I'm using xine-lib-1-rc7 which is a version that's supposed to compile with mingw on Windows as well. I ran ./configure. I went into config.h and changed line
275 to undefine lrintf:
/* #undef HAVE_LRINTF */
The library that has the lrintf issue is libfaad. I went to the src/libfaad directory and edited the common.h file. Since I've undefined lrintf, I have to define it. There's already a definition in common.h, but it does not agree with the one in uclibc in the bits/mathinline.h file. I needed to copy the definition of lrintf from there so that when everything builds together, there wouldn't be any
discrepancies in the definition. So starting at line 312, comment out from static INLINE int lrintf (float f) to the }.
Add in its place:
static INLINE long int lrintf (float __x) __THROW
{
__lrintf _code;
}
It's easiest to copy it from bits/mathinline.h so that you avoid any typos. Now you can compile xine and if you compile and build the front ends about that, everything should work.
The flxine program isn't the easiest to find on the Internet, but I did manage to find a copy of the 0.6.1 source. You should be able to find an updated link to it at the FLTK wiki. flxine is no longer supported by anyone, but I saw a post at the CinePaint Glasgow site mentioning a possible newer version called flixine based on the flxine source code. I'd be very interested to hear if anything comes of it. I had to make the following changes on DeLi Linux to get flxine to compile. In main.cxx from the src subdirectory, add the following after line 6:
#include <unistd.h>
In the xine_interface.cxx file, add the following after line 8:
#include <unistd.h>
In the gui_functions.cxx file, add the following after line 4:
#include <FL/x.H>
In the gui_functions.cxx file, add the following at line 12:
#define _tolower(x) tolower(x)
With those changes, flxine should compile. It builds on FreeBSD as well, but with different patches.
By the way, I was very impressed with the Xine player and specifically flxine on Linux once I got it up and running. Definitely worth the effort. Check out some of the visual special effects you can run while listening to music.
Ogle is a DVD player. It's a command line program. Goggles is a GUI front end for it using Fox Toolkit. Make sure you have the latest copies of the DVD libraries such as libdvdread from the Ogle home page if you're going to build it. Otherwise it may not be able to play certain DVDs. You'll also need a52dec and its libraries for a52 (ac3). Once built, I had to do some linking of library files to the standard lib directory on DeLi Linux to get ogle to run. I did a cd to /usr/local/lib and used ln -s ogle/libmsgevents.so.6.2.0 libmsgevents.so.6 and ln -s ogle/libdvdcontrol.so.9.2.0 libdvdcontrol.so.9. I did not have to do this on Absolute Linux. Had to do some editing of one of the Goggles build files to get it to find the ogle libraries even after the links to the libraries were created. I went ahead and hard-coded the information in the file when I built it on DeLi Linux. For goggles-0.9.1, in the build subdirectory in file ogledetect at line 25, I added the following:
OGLE_PREFIX="/usr/local" LIBDIR="lib" DLLEXT=".so"
When I rebuilt it on Absolute Linux, I used ./gb --ogle-prefix=/usr/local instead of editing the ogledectect file and it built fine. I think either method should work on either version of Linux, but the latter is probably easiest. I had no trouble running Goggles on DeLi Linux. On Absolute Linux, with all the video library extras installed, I was unable to get it to run in the memory I had. Am hoping there may still be a way to get it to run without having to turn off several features in Absolute Linux, but at this time I haven't figured out how yet.
I wanted an Open Source DVD backup tool similar to DVD Rebuilder (a Windows program). There are several Open Source options, but I have not had much luck building any of them so far, except for a command line tool called vamps. It compiles fine for Linux users. The interesting thing is that it can be made to compile on Windows as well with some patching.
For Windows users, I built vamps 0.99.2. I didn't add any #ifdefs in for __MINGW32__, so if you make the following changes, the program may or may not still work when compiling on other machines. You'll need the Win32 pthread libraries for this. In msys, cd to the top level directory where vamps was decompressed and untared and use make to build. I made the following changes (as reported by diff) to requant.c in the vamps directory:
99c99
< //typedef unsigned int uint;
---
> typedef unsigned int uint;
147c147,148
< static int mloka1, mloka2, eof;
---
> static int mloka1, mloka2;
> int eofflag;
276,277c277,278
< { \
< if (!eof)\
---
> { \ eofflag = eof;
>> if (!eoflag)\
284c285
< if (mloka1 <= 0) { eof = 1; break; } \
---
> if (mloka1 <= 0) { eofflag = 1; break; } \
304,305c305,306
< { \
< if (!eof)\
---
> { \ eofflag = eof;
> if (!eofflag)\
312c313
< if (mloka1 <= 0) { eof = 1; break; } \
---
> if (mloka1 <= 0) { eofflag = 1; break; } \
2230c2231
< eof = 0;
---
> eofflag = 0;
2539c2540,2541
< if (!eof)
---
> eofflag = eof;
> if (!eofflag)
2550c2552
< if (mloka1 <= 0) { eof = 1; break; }
---
> if (mloka1 <= 0) { eofflag = 1; break; }
2652c2654,2662
< if (wbuf - owbuf > MIN_WRITE) { WRITE }
---
> // if (wbuf - owbuf > MIN_WRITE) { WRITE }
> if (wbuf - owbuf > MIN_WRITE) { mloka1 = wbuf - owbuf; \
> write(1, owbuf, mloka1); \
> outbytecnt += mloka1; \
> wbuf = owbuf; \
> mloka1 = rbuf - cbuf; if (mloka1) memmove(orbuf, cbuf, mloka1);\
> cbuf = rbuf = orbuf; rbuf += mloka1;
> }
>
I made the following changes to vamps.c in the vamps directory:
120c120 < int eof; // end of file flag --- > int eofflag; // end of file flag 815c815 < eof = 1; --- > eofflag = 1; 1013c1013 < eof = 1; --- > eofflag = 1; 1186c1186 < if (eof) --- > if (eofflag = eof) 1200c1200 < if (eof) --- > if (eofflag = eof)
I made the following changes to the Makefile in the vamps directory:
26c26 < LOADLIBES += -lm -lpthread --- > LOADLIBES += -lm -lpthread /mingw/lib/libiberty.a /mingw/msys/lib/pthreadGC2.dll
I made the following changes to the Makefile in the play_cell directory:
24c24 < LOADLIBES += -ldvdread --- > LOADLIBES += -ldvdread -llibdl /mingw/lib/libiberty.a
Aften is an ac3 audio tool. Aften requires cmake just to build it. Once cmake is downloaded and built, you can decompress and untar aften. I created a default subdirectory in the aften-0.0.8 directory. I deleted CMakeLists.txt in the aften-0.0.8 directory. You only need to do this if it's already in the directory. From the default subdirectory, I ran cmake .. and then make and then make install. Note the .. after the cmake command to tell it the files are in the directory above default. With that, aften and some other tools for wav files built fine.
The ming library compiles on Windows with the changes mentioned below. I assume it compiles fine on Linux as is. Two other swf libraries I've built are libswf and xml2swf. They're for Posix compatible machines, but with patches I had them running successfully on Windows too.
I downloaded ming-0.4.0.beta5.zip from Sourceforge's ming project. There's a precompiled version available from the Dev C++ compiler's DevPak project on Sourceforge too. In the version I downloaded, I had to comment out the following lines in the makefile under the src directory. Once that was done and paths to supporting includes and libraries were okay, I was able to get the ming library to build.
# this is for the php module #all-local: # $(mkdir_p) lib # rm -f lib/libming.so # $(LN_S) ../.libs/libming.so lib/libming.so
For libswf 0.1, you'll need the regex library from gnuwin32 on Sourceforge. Here are the changes I needed to make to libswf:
#include <queue.h>from:
#include <queue>
#include "\mingw\msys\include\regex.h"instead of
<regex.h>void main(void){
to:
int main(void){
and added a return (0); before end of routine.
g++ -s -O2 example.cpp nc_swf_encode.o nc_swf_encode_tag.o typestring.o /mingw/msys/lib/regex.lib -o example
That should be enough to get the example.exe program created. Needed to copy regex2.dll into executable directory before running though.
For xml2swf 0.1, I needed to do the following to get it to build on Windows. I needed to make sure any extra libraries or includes were exported in msys to my include and library paths. I downloaded libintl-0.14.4, zlib-1.2.3, freetype-2.3.5-1, giflib-4.1.6, libpng-1.2.24 from gnuwin32 project on Sourceforge. I copied freetype-2.3.5-1 includes from C:\mingw\msys\include\freetype2\freetype\ to C:\mingw\msys\include\freetype so ming library could find them. I downloaded expat-2.0.1.tar.gz and used ./configure, make and make install commands to build it. There's a precompiled version available from the Dev C++ compiler's DevPak project on Sourceforge too. I downloaded ming-0.4.0.beta5.zip from Sourceforge. See the fixes mentioned above to get it to build. In the xml2swf makefile, I changed the lines at the top of the makefile to the following:
CC = gcc -c -Wall -g -I/include -I/usr/local/include LD = gcc -L/lib -L/usr/local/lib -lexpat -lming -lm -o xml2swf: xml2swf.o hash.o shapes.o frames.o $(LD) xml2swf xml2swf.o hash.o shapes.o frames.o /usr/local/lib/libexpat.a /usr/local/lib/libming.a /usr/local/lib/libz.a /usr/lib/freetype.lib /usr/lib/giflib.lib /usr/lib/libintl.lib /usr/lib/libpng.lib
You'll need the gnuwin32 dlls for freetype6, giflib4, libpng12, zlib1 to get xml2swf.exe to run. The samples built fine.
Dialog is a great tool for adding a user interface to scripting languages. It can be used to create a simple front end for command line tools executed from scripts. It's available on most Linux systems. FreeBSD has freedialog which is a rewrite that has a BSD license rather than the usual GNU LGPL license. For cross-platform use, I felt it would be helpful to get a version of Dialog working on Windows. The only prerequisite it really needs is PDCurses. I've built it using MinGW and OpenWatcom. MinGW requires a few less define additions in the patch_dlg_config.txt file. I'll relate the steps to get it compile with OpenWatcom since it produces one executable that's easy to move to other Windows systems.
If you'd like a compiled and linked copy for Windows using the patches below, you can find a link at http://criticalpressmedia.com/2011/02/mini-repository-for-windows-software-dialog-simple-user-interface/. The owner of the site was nice enough to offer me some space to start a mini repository for some of the Open Source Windows software I've built.
When I built Dialog I used Open Watcom 1.9 and pdcurses 3.4. I used msys for a build environment. Msys was developed with MinGW, but can be used with Open Watcom if a few changes are made. I used dialog_1.1-20080819.orig.tar.gz source from the Ubuntu packages.
Create a file patch.diff with the following:
diff -Naurp src/dialog-1.1-2008081/fselect.c tmp/dialog-1.1-20080819/fselect.c
--- src/dialog-1.1-20080819/fselect.c 2008-03-16 09:04:57 -0400
+++ tmp/dialog-1.1-20080819/fselect.c 2008-03-16 09:04:57 -0400
@@ -31,8 +31,13 @@
# include <dirent.h>
# define NAMLEN(dirent) strlen((dirent)->d_name)
#else
+#if HAVE_DIRECT_H
+# include <direct.h>
+# define NAMLEN(dirent) strlen((dirent)->d_name)
+#else
# define dirent direct
# define NAMLEN(dirent) (dirent)->d_namlen
+#endif
# if HAVE_SYS_NDIR_H
# include <sys/ndir.h>
# endif
diff -Naurp src/dialog-1.1-2008081/ui_getc.c tmp/dialog-1.1-20080819/ui_getc.c
--- src/dialog-1.1-20080819/ui_getc.c 2008-03-16 16:02:20 -0400
+++ tmp/dialog-1.1-20080819/ui_getc.c 2008-03-16 16:02:20 -0400
@@ -24,6 +24,13 @@
#include <dialog.h>
#include <dlg_keys.h>
+#ifdef NEED_FCNTL_H
+#define F_GETFL 3
+#define SIGHUP 1
+#define SIGQUIT 3
+#include <fcntl.h>
+#endif
+
#ifdef NEED_WCHAR_H
#include <wchar.h>
#endif
@@ -102,6 +109,7 @@ dlg_remove_callback(DIALOG_CALLBACK * p)
static int
dlg_getc_ready(DIALOG_CALLBACK * p)
{
+#ifndef HAVE_NO_FD
fd_set read_fds;
int fd = fileno(p->input);
struct timeval test;
@@ -113,6 +121,9 @@ dlg_getc_ready(DIALOG_CALLBACK * p)
test.tv_usec = WTIMEOUT_VAL * 1000; /* Microseconds. */
return (select(fd + 1, &read_fds, (fd_set *) 0, (fd_set *) 0, &test) == 1)
&& (FD_ISSET(fd, &read_fds));
+#else
+ return 0;
+#endif
}
int
@@ -187,9 +198,11 @@ valid_file(FILE *fp)
if (fd >= 0) {
long result = 0;
+#ifndef HAVE_NO_COMPAT_FCNTL
if ((result = fcntl(fd, F_GETFL, 0)) >= 0) {
code = TRUE;
}
+#endif
}
return code;
}
@@ -395,7 +408,7 @@ dlg_killall_bg(int *retval)
}
}
if (dialog_state.getc_callbacks != 0) {
-
+#ifndef HAVE_NO_FORK
refresh();
fflush(stdout);
fflush(stderr);
@@ -445,6 +458,7 @@ dlg_killall_bg(int *retval)
}
}
}
+#endif
}
}
}
diff -Naurp src/dialog-1.1-2008081/util.c tmp/dialog-1.1-20080819/util.c
--- src/dialog-1.1-20080819/util.c 2008-08-19 20:26:37 -0400
+++ tmp/dialog-1.1-20080819/util.c 2008-08-19 20:26:37 -0400
@@ -179,6 +179,7 @@ static int
open_terminal(char **result, int mode)
{
const char *device = TTY_DEVICE;
+#ifndef HAVE_NO_ISATTY
if (!isatty(fileno(stderr))
|| (device = ttyname(fileno(stderr))) == 0) {
if (!isatty(fileno(stdout))
@@ -189,6 +190,7 @@ open_terminal(char **result, int mode)
}
}
}
+#endif
*result = dlg_strclone(device);
return open(device, mode);
}
Apply the following commands before running configure:
perl -i.bk1 -pe 's/MINGW\*:\*/MINGW*:* | *:WATCOM*:*/' config.guess
perl -i.bk2 -pe 's/test \$cf_curs_lib = unknown/test \$cf_curs_lib = notunknown/' configure
perl -i.bk3 -pe 's/test \$cf_result = no && { { echo "\$as_me:9272/test \$cf_result = notno && { { echo "\$as_me:9272/' configure
patch -p2 < patch.diff
Type and enter: ./configure
Create a file patch_dlg_config.txt with the following:
#define HAVE_COLOR 1 #define HAVE_FLUSHINP 1 #define HAVE_GETBEGX 1 #define HAVE_GETBEGY 1 #define HAVE_GETCURX 1 #define HAVE_GETCURY 1 #define HAVE_GETMAXX 1 #define HAVE_GETMAXY 1 #define HAVE_GETPARX 1 #define HAVE_GETPARY 1 #define HAVE_USE_DEFAULT_COLORS 1 #define HAVE_NO_ISATTY 1 #define NEED_FCNTL_H 1 #define HAVE_NO_FD 1 #define HAVE_NO_COMPAT_FCNTL 1 #define HAVE_NO_FORK 1 #define HAVE_DIRECT_H 1
Apply the following commands before running make:
cat patch_dlg_config.txt >>dlg_config.h
perl -i.bk1 -pe 's/LIBS = -lunknown -lx #/#/' makefile
perl -i.bk2 -pe 's/\$(RANLIB) \$@//' makefile
perl -i.bk3 -pe 's/\${AR} -cr/\${AR}/' makefile
perl -i.bk4 -pe 's/-L. -ldialog /-L. pdcurses.lib libdialog.a /' makefile
perl -i.bk5 -pe 's/VERSION//' makefile
Type and enter: make
Type and enter: make install
You can optionally add DESTDIR=path to the make install command in order to set the path where you want the files to be installed. This should create dialog.exe and dialog man pages. If you've created PDCurses for static linking, no other library dependencies should be required. You can take the dialog.exe file to other Windows systems or use on your flash drive whenever you need it.
Xdialog and gxmessage are two GUI alternatives to dialog. Xdialog has already been patched to work with gtk+ 2 instead of gtk+ 1. It really didn't take much to get it working on Windows using MinGW and msys and was even easier to build than dialog. Use the following when you configure:
./configure --with-gtk2 --with-scanf-calls
Then run the make and make install as usual. Gxmessage also compiled without issue and didn't require any special options when using configure.
I had lots of problems trying to build cdrtools on Linux. My biggest problem was that make install put the programs in a place I didn't expect that wasn't in my path (/opt/schily/bin). You need to link over to the files in your standard bin directory or add their installed location to the appropriate environment variables. For example, in /usr/bin type: ln -s /opt/schily/bin/mkisofs. Otherwise, other programs can't find them. When I built cdrtools, I used tar -xpf cdrtools-2.01.01a38.tar to unarchive them as per the instructions. The -p option preserves file permissions. I compiled the tools with make DEFAULTSDIR=DEFAULTS_ENG.
If you want to run cdrtools on Windows, my recommendation is that you pull down a precompiled version. There are various versions (some including spti support specifically for Windows). Most of the ports use Cygwin to build the tools. You can download cdrtools in conjunction with Windows front ends for them such as Infrarecorder.
The wvdial program works on POSIX machines such as Linux. I wanted to get it working on my FreeBSD 7.2 machine. In order to get wvdial working, the wvstreams library needs to be built and installed. With the following patches, I was able to get wvstreams library to build successfully on FreeBSD 7.2. Most of the changes for FreeBSD in wvstreams were very similar to what was set up for the _MACOS and MACOS ifdefs. If those could be enabled for FreeBSD, that would fix many of the issues when compiling.
Build the library using the usual ./configure, gmake, gmake install on FreeBSD. When you finish configuring, you'll need to modify the Makefile before running. Comment out the following lines in the Makefile just like you see below:
ifndef _MACOS
ifneq ("$(with_qt)", "no")
# TARGETS += libwvqt.so
# TESTS += $(patsubst %.cc,%,$(wildcard qt/tests/*.cc))
# libwvqt_OBJS += $(call objects,qt)
# libwvqt.so: $(libwvqt_OBJS) $(LIBWVSTREAMS)
# libwvqt.so-LIBS += $(LIBS_QT)
# qt/tests/%: PRELIBS+=$(LIBWVQT)
# qt/wvqtstreamclone.o: include/wvqtstreamclone.moc
# qt/wvqthook.o: include/wvqthook.moc
endif
endif
The wvstreams 4.6.1 patch file contains the rest of the changes I needed to make to get the library to build. Patch before configure is run or at latest, before gmake.
The wvdial 1.61 patch file contains patches to try to get wvdial to compile and build. Had some difficulties with wvdialmon.cc. Specifically, the struct rtentry looks different on FreeBSD. I attempted to substitute struct route instead. Not sure if it works on FreeBSD, but it does compile and build. Hope others will help debug and test further and the patches will eventually make their way back into the original programs.
The prozilla program compiled fine on Linux. It's a command line tool that helps speed file downloading from the Internet. Had some trouble getting the prozgui front end (which uses fltk) to compile. Had to make the following changes to prozgui-2.0.2. Go to the src directory. In file Fl_Progress.cxx line 76 change inactive to
fl_inactive. In options.cpp, lines 112, 113 and 177, change the following lines from:
filename_expand(abs_out_dir, in_outputdir->value()); filename_absolute(abs_out_dir, abs_out_dir); if (filename_isdir(abs_out_dir) == 0)
to:
fl_filename_expand(abs_out_dir, in_outputdir->value()); fl_filename_absolute(abs_out_dir, abs_out_dir); if (fl_filename_isdir(abs_out_dir) == 0)
In we.cxx, on line 4212 remove \363. The DeLi Linux compiler was unable to handle the special character. This is probably specific to using older versions of the GNU C/C++ compiler. Also, for proper internationalization support, go to the src subdirectory and edit the Makefile.
At line 111, add -lintl so it can find libintl.
LIBS=-lXpm -lXext -lX11 -lm -lintl $(THREAD_LIBS)
Now it should compile and build. You need to do a make install before trying to run it or it will be unable to find its own libprozilla library.
SearchMonkey with GTK+ builds fine on Linux. Latest versions of SearchMonkey have switched to using the QT library. There's a section at Sourceforge with instructions how to build it on Windows using GTK. There is also an older Windows executable using GTK in the Sourceforge archives. When I ran the older GTK Windows executable, it seemed pretty buggy, but the last GTK version if compiled and built for Windows is much more stable and useable. I recommend using the new QT versions instead of the old GTK+ version. Am leaving the information on how to build with GTK+ available purely for reference.
I built SearchMonkey 0.8.1 on Windows from its source code using MinGW. Here's what I did to get it to compile. You'll need MinGW, msys and the GTK+ 2 libraries installed. I had to add the regular expression library to the makefile so it could find the regex functions. I used regex-2.7-lib.zip from the Gnuwin32 project. From the instructions at the Sourceforge site, they used another library, so it looks like it will work with any decent implementation of regex. You don't specifically have to use the one I added. The following line fixed the makefile for me:
perl -i.bk1 -pe 's/LDADD = /LDADD = -lregex.dll /' Makefile
When compiling, it also couldn't find lstat, so I just added it. You can use the following code to patch the issue:
diff -Naurp src/searchmonkey-0.8.1/src/search.c tmp/searchmonkey-0.8.1/src/search.c --- src/searchmonkey-0.8.1/src/search.c 2011-02-09 10:02:13 -0500 +++ tmp/searchmonkey-0.8.1/src/search.c 2011-02-09 10:02:52 -0500 @@ -17,6 +17,10 @@ #include "systemio.h" /* System stuff, file import and export code */ #include "misc.h" /* Everything else */ +#ifdef __WIN32__ +#define lstat stat +#endif + /*mutexes for searchdata and searchControl->cancelSearch */ GStaticMutex mutex_Data = G_STATIC_MUTEX_INIT; /* Global mutex used by savestate.c too */ GStaticMutex mutex_Control = G_STATIC_MUTEX_INIT; /* Global mutex used by savestate.c too*/
Copy the patch code to a file named patch.diff. You can then add the patch to the SearchMonkey source code using a command line like this:
patch -p2 < patch.diff
Was looking for a cbr/cbz viewer and tried several on Windows, but I really liked this one. You can download the executable and it should work fine on Windows. I also have some differences listed under the Linux patches that I used to make a Windows portable apps style version out of the 0.8 code. When I contacted the author, he said there was an update to Comical coming some time in the future. Haven't seen it yet. Was able to get comical 0.8 working on DeLi Linux system using wxWidgets 2.6. However, when trying it on Absolute Linux, which uses wxWidgets 2.8.7, the program didn't compile. Below are some patches I put together to get Comical to compile with wxWidgets 2.8.7. Obviously wxWidgets has changed between 2.6 and 2.8.7. Biggest problem appears to be the change to the wxMenuItem which can be resolved by giving a reference to the menu rather than a NULL when the wxMenuItem is created. The cbr capability was not functioning for me even with version 2.6 of wxWidgets. Now it gives an alert message. I didn't have the time to try to track down and fix the cbr issue. However, the program works fine for cbz files on Linux as is. I've since tried compiling against 2.8.8 and it appears to resolve the menu issues problem. Some distributions substitute a free version of the rar library for the rar code including and that should fix any cbr issues on Linux and FreeBSD.
In order to get Comical to compile, I commented out the following line in src/ComicalApp.cpp:
63c63 < frame->SetIcon(wxICON(comical)); --- > // frame->SetIcon(wxICON(comical));
It was #ifdef'd anyway, so didn't appear to be crucial. A better fix would be to add one's system to the #ifdef
or update the statement to work properly with latest version of wxWidgets.
To fix alert menu alert messages that come up in version 2.8.7 (but no in 2.6), change the following. In src/ComicalFrame.cpp:
66,67c66,69
< wxMenuItem *openMenu = new wxMenuItem(NULL, wxID_OPEN, wxT("&Open\tAlt-O"), wxT("Open a Comic Book."));
< wxMenuItem *exitMenu = new wxMenuItem(NULL, wxID_EXIT, wxT("E&xit\tAlt-X"), wxT("Quit Comical."));
---
> menuFile = new wxMenu();
>
> wxMenuItem *openMenu = new wxMenuItem(menuFile, wxID_OPEN, wxT("&Open\tAlt-O"), wxT("Open a Comic Book."));
> wxMenuItem *exitMenu = new wxMenuItem(menuFile, wxID_EXIT, wxT("E&xit\tAlt-X"), wxT("Quit Comical."));
72d73
< menuFile = new wxMenu();
78,83c79,86
< wxMenuItem *prevMenu = new wxMenuItem(NULL, ID_PrevSlide, wxT("Previous Page"), wxT("Display the previous page."));
< wxMenuItem *nextMenu = new wxMenuItem(NULL, ID_NextSlide, wxT("Next Page"), wxT("Display the next page."));
< wxMenuItem *prevTurnMenu = new wxMenuItem(NULL, ID_PrevTurn, wxT("&Previous Page Turn"), wxT("Display the previous two pages."));
< wxMenuItem *nextTurnMenu = new wxMenuItem(NULL, ID_NextTurn, wxT("&Next Page Turn"), wxT("Display the next two pages."));
< wxMenuItem *firstMenu = new wxMenuItem(NULL, ID_First, wxT("&First Page"), wxT("Display the first page."));
< wxMenuItem *lastMenu = new wxMenuItem(NULL, ID_Last, wxT("&Last Page"), wxT("Display the last page."));
---
> menuGo = new wxMenu();
>
> wxMenuItem *prevMenu = new wxMenuItem(menuGo, ID_PrevSlide, wxT("Previous Page"), wxT("Display the previous page."));
> wxMenuItem *nextMenu = new wxMenuItem(menuGo, ID_NextSlide, wxT("Next Page"), wxT("Display the next page."));
> wxMenuItem *prevTurnMenu = new wxMenuItem(menuGo, ID_PrevTurn, wxT("&Previous Page Turn"), wxT("Display the previous two pages."));
> wxMenuItem *nextTurnMenu = new wxMenuItem(menuGo, ID_NextTurn, wxT("&Next Page Turn"), wxT("Display the next two pages."));
> wxMenuItem *firstMenu = new wxMenuItem(menuGo, ID_First, wxT("&First Page"), wxT("Display the first page."));
> wxMenuItem *lastMenu = new wxMenuItem(menuGo, ID_Last, wxT("&Last Page"), wxT("Display the last page."));
92d94
< menuGo = new wxMenu();
105c107
<
---
>
157c159
< wxMenuItem *fsMenu = new wxMenuItem(NULL, ID_Full, wxT("Full &Screen\tAlt-Return"), wxT("Display Full Screen."));
---
> wxMenuItem *fsMenu = new wxMenuItem(menuView, ID_Full, wxT("Full &Screen\tAlt-Return"), wxT("Display Full Screen."));
In src/ComicalCanvas.cpp:
852,858c852,858
< wxMenuItem *openMenu = new wxMenuItem(NULL, ID_ContextOpen, wxT("Open..."), wxT("Open a comic book."));
< wxMenuItem *prevMenu = new wxMenuItem(NULL, ID_ContextPrevSlide, wxT("Previous Page"), wxT("Display the previous page."));
< wxMenuItem *nextMenu = new wxMenuItem(NULL, ID_ContextNextSlide, wxT("Next Page"), wxT("Display the next page."));
< wxMenuItem *prevTurnMenu = new wxMenuItem(NULL, ID_ContextPrevTurn, wxT("&Previous Page Turn"), wxT("Display the previous two pages."));
< wxMenuItem *nextTurnMenu = new wxMenuItem(NULL, ID_ContextNextTurn, wxT("&Next Page Turn"), wxT("Display the next two pages."));
< wxMenuItem *firstMenu = new wxMenuItem(NULL, ID_ContextFirst, wxT("&First Page"), wxT("Display the first page."));
< wxMenuItem *lastMenu = new wxMenuItem(NULL, ID_ContextLast, wxT("&Last Page"), wxT("Display the last page."));
---
> wxMenuItem *openMenu = new wxMenuItem(contextMenu, ID_ContextOpen, wxT("Open..."), wxT("Open a comic book."));
> wxMenuItem *prevMenu = new wxMenuItem(contextMenu, ID_ContextPrevSlide, wxT("Previous Page"), wxT("Display the previous page."));
> wxMenuItem *nextMenu = new wxMenuItem(contextMenu, ID_ContextNextSlide, wxT("Next Page"), wxT("Display the next page."));
> wxMenuItem *prevTurnMenu = new wxMenuItem(contextMenu, ID_ContextPrevTurn, wxT("&Previous Page Turn"), wxT("Display the previous two pages."));
> wxMenuItem *nextTurnMenu = new wxMenuItem(contextMenu, ID_ContextNextTurn, wxT("&Next Page Turn"), wxT("Display the next two pages."));
> wxMenuItem *firstMenu = new wxMenuItem(contextMenu, ID_ContextFirst, wxT("&First Page"), wxT("Display the first page."));
> wxMenuItem *lastMenu = new wxMenuItem(contextMenu, ID_ContextLast, wxT("&Last Page"), wxT("Display the last page."));
895,896c895,896
< ccwMenu = new wxMenuItem(NULL, ID_ContextLeftCCW, wxT("Rotate Counter-Clockwise"), wxT("Rotate 90 degrees counter-clockwise."));
< cwMenu = new wxMenuItem(NULL, ID_ContextLeftCW, wxT("Rotate Clockwise"), wxT("Rotate 90 degrees clockwise."));
---
> ccwMenu = new wxMenuItem(contextRotate, ID_ContextLeftCCW, wxT("Rotate Counter-Clockwise"), wxT("Rotate 90 degrees counter-clockwise."));
> cwMenu = new wxMenuItem(contextRotate, ID_ContextLeftCW, wxT("Rotate Clockwise"), wxT("Rotate 90 degrees clockwise."));
898,899c898,899
< ccwMenu = new wxMenuItem(NULL, ID_ContextCCW, wxT("Rotate Counter-Clockwise"), wxT("Rotate 90 degrees counter-clockwise."));
< cwMenu = new wxMenuItem(NULL, ID_ContextCW, wxT("Rotate Clockwise"), wxT("Rotate 90 degrees clockwise."));
---
> ccwMenu = new wxMenuItem(contextRotate, ID_ContextCCW, wxT("Rotate Counter-Clockwise"), wxT("Rotate 90 degrees counter-clockwise."));
> cwMenu = new wxMenuItem(contextRotate, ID_ContextCW, wxT("Rotate Clockwise"), wxT("Rotate 90 degrees clockwise."));
909c909
< wxMenuItem *fsMenu = new wxMenuItem(NULL, ID_ContextFull, wxT("Full Screen"));
---
> wxMenuItem *fsMenu = new wxMenuItem(contextMenu, ID_ContextFull, wxT("Full Screen"));
Didn't have the chance to try to debug the rar file code. It brings up an array size exception when you try to open a cbr file. You can comment out call to postCtor in src/ComicBookRAR.cpp and it won't bring up an alert message, but it still won't display cbr files. Am guessing bug is somewhere in src/ComicBook.cpp in void ComicBook::postCtor() function and has to do with array size of a wxString, but haven't been able to get any further with this. Optional change to src/ComicBookRAR.cpp:
48a49 > 86,87c87 < < postCtor(); --- > // postCtor();
To make a more portable version for Windows, I decided to switch the code that stored basic setup properties from using the registry to saving to a file. This was a rather simple change, since wxWidgets already has support for saving settings to a file. The hardest part was managing to get Comical to compile and build. I used a more recent version of wxWidgets. The event declarations were added to work around a bug in wxWidgets 2.8.9.
If you'd like a compiled and linked copy for Windows using the patches below, you can find a link at http://criticalpressmedia.com/2010/09/mini-repository-for-windows-software-comical-cbrcbz-file-reader/. The owner of the site was nice enough to offer me some space to start a mini repository for some of the Open Source Windows software I've built.
When building wxWidgets 2.8.9 using MinGW and msys, I used the following configure command, for the configure, make, make install process:
./configure --with-unicode --with-expat=builtin --with-libjpeg=builtin --with-regex=builtin --with-libpng=builtin --with-libtiff=builtin --with-zlib=builtin --enable-unicode --enable-mslu
For Comical 0.8, there's no configure file, just make -f Makefile.mingw. If the unrar and unzip directories don't compile, go to the top level directory for comical-0.8 where the Makefile.mingw is located and type the following in msys.
make lib -C unrar -f Makefile.mingw make -C unzip -f Makefile.mingw
Then run make -f Makefile.mingw again. Before using the make command when building Comical, make the following patches to create a more portable version.
In makefile.mingw:
3c3 <INCLUDE = -Iunrar -Iunzip -IC:\wxWidgets-2.6.2\include -IC:\wxWidgets-2.6.2\lib\gcc_lib\mswu --- > INCLUDE = -Iunrar -Iunzip -I/usr/local/lib/wx/include/msw-unicode-release-2.8 -I/usr/local/include/wx-2.8 -I/usr/local/include -I/usr/include 5,9c5,9 < CPPFLAGS = $(CFLAGS) -mthreads -DWIN32 -D__WXMSW__ -D_UNICODE -DwxUSE_UNICODE_MSLU=1 $(INCLUDE) < LDFLAGS = -mwindows -mthreads -Lunzip -Lunrar -Lc:\wxWidgets-2.6.2\lib\gcc_lib < LIBS = -lunrar -lminiunzip -lwxmsw26u_core -lwxbase26u -lwxjpeg -lwxpng -lz < WIN32_LIBS = -lunicows -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -loleacc < RESFLAGS = --use-temp-file --define __WXMSW__ --define _UNICODE --include-dir C:/wxWidgets-2.6.2/include --include-dir C:/wxWidgets-2.6.2/lib/gcc_lib/mswu --- > CPPFLAGS = $(CFLAGS) -mthreads -DWIN32 -DWXUSINGDLL -D__WXMSW__ -D_UNICODE -DwxUSE_UNICODE_MSLU=1 $(INCLUDE) > LDFLAGS = -mwindows -mthreads -Lunzip -Lunrar -L/usr/local/lib -L/lib -L/usr/local/lib > LIBS = -L/usr/local/lib -mthreads -Wl,--subsystem,windows -mwindows -lwx_mswu_richtext-2.8 -lwx_mswu_aui-2.8 -lwx_mswu_xrc-2.8 -lwx_mswu_qa-2.8 -lwx_mswu_html-2.8 -lwx_mswu_adv-2.8 -lwx_mswu_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lunrar -lminiunzip -lz > WIN32_LIBS = -lunicows -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -loleacc > RESFLAGS = --use-temp-file --define __WXMSW__ --define _UNICODE --include-dir /usr/local/include/wx-2.8
In unzip/makefile.mingw:
7c7 < CFLAGS = -Os --- > CFLAGS = -Os -I/usr/local/include
In src/makefile.mingw:
diff ../original/comical-0.8/src/makefile makefile 1c1 < INCLUDE = -I../unrar -I../unzip --- > INCLUDE = -I../unrar -I../unzip -I/usr/local/include -I/usr/include
In src/ComicalApp.CPP:
30a31,32
> #include <wx/fileconf.h>
>
48c50,51
< wxConfig *config = new wxConfig(wxT("Comical"));
---
> // wxConfig *config = new wxConfig(wxT("Comical"));
> wxFileConfig *config = new wxFileConfig(wxT("Comical"));
In src/ComicalBrowser.CPP:
29a30,34 > extern const wxEventType EVT_PAGE_THUMBNAILED; > extern const wxEventType EVT_PAGE_CHANGED; > extern const wxEventType EVT_CURRENT_PAGE_CHANGED; > >
In src/ComicalCanvas.CPP:
39a40,42 > extern const wxEventType EVT_PAGE_CHANGED; > extern const wxEventType EVT_PAGE_SCALED; >
In src/ComicalFrame.CPP:
43a44,48 > #include <wx/fileconf.h> > > > extern const wxEventType EVT_PAGE_SHOWN; > extern const wxEventType EVT_PAGE_ERROR; 58c63,64 < config = wxConfig::Get(); --- > // config = wxConfig::Get(); > config = wxFileConfig::Get();
In src/ComicBookRAR.CPP:
290c290 < wcscpy(flags->ArcNameW, filename.c_str()); --- > wcscpy(flags->ArcNameW, (const wchar_t*)(filename.c_str()));
If you want a small desktop style program to run with fluxbox (or another window manager) on Linux, you may want to check out fxdesktop. It built with no issues, but to run it you need to open a terminal in your window manager and type something similar to the the following (or execute the following from a shell script). In this case, I've assumed the window manager used is fluxbox. Change it to the window manager you use.
export "FOX_DESKTOP_WM=fluxbox" fxdesktop