Compiling Pdftk for Snow Leopard
Posted: September 20th, 2010 | Author: Remi | Filed under: OS X | 1 Comment »I decided to look into different types of PDF software hoping to find some awesome PDF utility from linux that would be equally as awesome when I ran it on OS X. Eventually I came across Pdftk. It was a command-line utility that was based on a pdf libraries written in Java. It seemed very interesting, and I couldn’t wait to try it out. So I fired up good ol’ macports and ‘sudo port install pdftk’ and…
.../usr/bin/ranlib: file: .libs/libgfortran.a(_dim_r16.o) has no symbols /usr/bin/ranlib: file: .libs/libgfortran.a(_atan2_r16.o) has no symbols /usr/bin/ranlib: file: .libs/libgfortran.a(_mod_r16.o) has no symbols creating libgfortran.la (cd .libs && rm -f libgfortran.la && ln -s ../libgfortran.la libgfortran.la) make: *** [all] Error 2 |
arghh.. It fails to build gcc42 which is need for GCJ (A handy part of GCC that turns java class files into native machine code). It seems to make sense that this utility would need it, being based on libraries written in Java? Okay, so I’ll just download GCC (it includes GCJ) and compile it myself. I subversion’ed myself the newest copy of GCC’s source
svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc |
I configured it to tell it where all my libraries were and where to install to (for me since I use macports this would be /opt/local), but not before installing its dependencies (libiconv, and mpfr), luckily these installed fine using macports. Then I ran make and waited…and waited..and waited for almost 3 HOURS!. sheesh. Apparently compilers are complicated or something. Anyway.. it was time to remember what I was doing and download Pdftk’s source. I configured it to the correct paths once again, (so it can find the libraries it needs for GCJ and so forth). I’m ready to make… and
gcj: error trying to exec 'ecj1': execvp: No such file or directory |
What?? Okay after some googling I find out that actually GCJ doesn’t do the actual compiling of the java files into class files, it relies on some jar from eclipse that you can download the latest one here (warning ftp site) (Another pitfall here is that when downloading jar files your browser might append a .zip on the end, just delete the .zip, don’t try to unzip the file). You can place that file anywhere (I put it in /opt/local/share/gcc-4.6.0/ and renamed it ecj.jar for simplicities sake). It also needs a script called ecj1 with the contents as follows:
#!/bin/sh gij -cp /opt/local/share/gcc-4.6.0/ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain ${1+"$@"} |
Of course change the path in the script to point to your ecj.jar file. I put this script in /opt/local/bin, but you can put it in any folder in your PATH. Okay now, back to pdftk…but things still aren’t going well. Another make, although goes further, reveals that there is a problem with the makefile’s calling of gcjh, aww man. Okay more googling produces a patch for this problem. I apply the patch with “patch -p0 < patch-filename”. The patch doesn’t apply without errors of course. I had to fix these manually, which isn’t too difficult, you just look at the .rej files and you can understand fairly easily the change they are indicating, if not read up on patch files a bit. Okay so things are looking good now, another make and the thing builds all the way to the end…. almost.
multiple definition of `java resource .dummy' |
It fails to link all the compiled files together… Argh… Okay so at least this is a know bug so there must be a fix right? Well there is a temporary fix, that is to use the objcopy command from binutils to force the dummy resource to be local, but alas objcopy doesn’t seem to work on OS X, I even built it from the newest version of the source and it still doesn’t work. The only way I found to fix this was to use a hex or text editor to rename the dummy resource. That’s exactly what I ended up doing after failing to write a script to do it (all of the scripts I wrote ended up corrupting the file somehow). I opened up all the .o files in the project with smultron and did a find and replace on each one (find: dummy replace: random 5-character string). This is not the desired way of doing this since there are literally hundreds of them (I may be exaggerating).
Holy crap, that was a lot of work to compile pdftk. If you’re planning to do the same I sympathise with you, (and let me know if you need any help since I’ve already done it.) Although, for those of you out there with a 64-bit snow leopard system you can download this package I made of my binaries. (they install to /usr/local/).
Download the Package
I hope this helps someone not go through the same frustration I did. If you have any issues with the package or compiling it. Let me know I can lend a hand.
Thanks a lot for this post. I had been having problems
building swingwt with gcj for days . Your link to the ecj.jar and
the ecj1 script seem is the only help I’ve been able to find on the
matter. Steve