pdftk 1.41 for Mac OS X 10.6
Important update: If you’ve downloaded the package before and you’re experiencing “segmentation fault”s with certain PDF files, please download the updated package below. Thanks to commenter Azhrei, we were able to fix a problem with one of the libraries, and all should work fine now!
Due to my being a remote employee, I get to juggle with PDF files quite a bit. A great tool for common PDF manipulations (changing page order, combining files, rotating pages etc) has proven to be pdftk. Sadly, a current version for Mac OS X is not available on their homepage. In addition, it is annoying (to say the least) to compile, which is why all three third-party package management systems that I know of (MacPorts, fink, as well as homebrew), last time I checked, did not have it at all, or their versions were broken.
Now I wouldn’t be a geek if that kept me from compiling it myself. I took some hints from anoved.net who was nice enough to also provide a compiled binary, but sadly did not include the shared libraries it relies on.
Instead, I made an installer package that’ll install pdftk itself as well as the handful of libraries you need into /usr/local. Once you ran this, you can open Terminal.app, and typing pdftk should greet you as follows:
$ pdftk
SYNOPSIS
pdftk <input PDF files | - | PROMPT>
[input_pw <input PDF owner passwords | PROMPT>]
[<operation> <operation arguments>]
[output <output filename | - | PROMPT>]
[encrypt_40bit | encrypt_128bit]
(...)
You can download the updated package here: pdftk1.41_OSX10.6.dmg
(MD5 hash: ea945c606b356305834edc651ddb893d)
I only tested it on OS X 10.6.2, if you use it on older versions, please let me know in the comments if it worked.
What are the shared libraries that it needs (don’t have my Mac right now to download the dmg and check the installer)?
I made sure to mention that in the README which you also can’t see if you don’t have a Mac handy
But here they are:
Btw, libgcj.8 and libstdc++.6 are symlinks to the respective other file in the list.
How can I trust that this is not a virus?
You could compile it yourself and compare the file hashes
You’re awesome, thanks for this!!
You’re welcome! I hope it works for you.
Fred, I found this with a Google search — EXCELLENT! I was dismayed about the issues with GCC, pdftk, and Snow Leopard and not being able to use MacPorts or fink. I then tried compiling myself and failed miserably. I almost gave up hope of having pdftk with OS X 10.6. Thanks so much for “being a geek” and working through the compiling issues! -JW
Thanks Fred, I’ve been looking for something like this.
However, it’s not working for me.
I’m running the latest 10.6.2 (including the Safari patch that just came out yesterday!) and I’m getting a SIGSEGV when trying to perform a “cat” operation on an input PDF. For example, the following works:
pdftk existing.pdf output new.pdf
But this one fails with a SEGV:
pdftk existing.pdf cat 1-23 output new.pdf
I’m somewhat new to development on OSX and I can’t find anything like the Linux strace(1) utility so I can’t tell what’s causing the SEGV!? I’ll be doing some more Google’ing on this, but I’ll come back here over the next few days as well.
Thanks for your work in putting this together! I built gcj on 10.6.2 but got Abort’s when gcj tried to execute ecj1 so after tinkering with it for a few hours I gave up.
Azhrei: Oh no! I can reproduce. Thanks for the hint! I’ll look into it and see what I can find out. If you find out what the problem is, please let me know as well!
If you find typing “pdftk” doesn’t work after installing you may need to add “/usr/local/bin/” to your PATH.
Do this by changing your path reference in your “.profile” file in your home directory. It’s a hidden file if you can’t find it.
Mine ended up looking like:
PATH=”/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/mysql/bin:/usr/local/bin”
Actually, it might be better to edit ~/.MacOSX/environment.plist because that file is parsed and variables are created by the window manager. That means the PATH variable will always be up to date, even if not executed from a Terminal.
Thank you!! You’re a legend.
It works on my snow leopard (10.6.2)
error on OSX 10.6.2
pdftk f1.pdf f2.pdf cat output f3.pdf
error message:
segmentation fault
Any idea?
No, I am sorry. It seems that pdftk is slowly rotting away, and, when compiled with gcj 4.2.1, there seems to be trouble with some PDF files. I am working on an alternative to pdftk, but it’s not quite ready yet.
I just checked out stapler (the project you mentioned) and while it might suffice for what I need, I really like the watermark and other features of PDFTK.
I might try to revive the PDFTK project by either converting the Java code to C/C++ or perhaps converting the C code into Java? Either of those would eliminate the issues of merging the two languages together…
I’ll look into this more over the weekend and next week and then report back here with a summary.
Woohoo! I think I’ve got a solution!
I found the following in my crash log directory regarding pdftk:
0 dyld 0x8fe11f32 misaligned_stack_error + 0
1 libstdc++.6.dylib 0x05fe6ce3 std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) + 243 (streambuf:341)
2 pdftk 0x00013aa7 std::_Rb_tree<int, int, std::_Identity, std::less, std::allocator >::_M_insert_unique(int const&) + 199
3 pdftk 0x000101c0 TK_Session::TK_Session(int, char**) + 7664
4 pdftk 0×00013253 main + 467
5 pdftk 0x00002c09 _start + 208
6 pdftk 0x00002b38 start + 40
You’ll notice that this crash says that dyld found a misaligned stack (!) and that error occurred in libstdc++.6.dylib. Well, it turns out that the dtruss was waking up the thread that was waiting so that it could handle the SIGBUS error if it chose, not because it was the one with the problem! (The following lines in the crash log show the semwait() thread.)
Anyway, I searched my system for “libstdc++.6.dylib” and found it in the /usr/local/gcj/lib directory — that’s the one provided in your bundle. But I also have one in my /usr/lib directory as well (note that I have the Xcode tools installed). Mine looks like this:
-rwxr-xr-x 1 root wheel 2439888 May 18 2009 /usr/lib/libstdc++.6.0.9.dylib*
This is on OSX 10.6.2. Well, I deleted the one in /usr/local/gcj/lib just to see if the standard system library might not have the bug and sure enough, it worked!
I’ve run some tests on PDFTK using the system library and it looks good so far. I’ve used a 24-page PDF as my test input. This is the one that had failures previously. I’ve used a nested loop to test extracting pages from 1-2, 2-3, 3-4, and so on, all the way to 23-24 without a crash. Then I tried 1-3, 2-4, etc. Each time extending the range of the extracted pages. Never crashed!
I don’t know if /usr/lib/stdc++.6.dylib is part of the base system install or part of Xcode (I suspect it’s part of Xcode because the same library appears under /Developer as well and that’s where Xcode places development libraries).
Very nice, Azhrei! Maybe, if I bundled the system lib with the package instead of my compiled one (both are from the same version of gcc, so I imagine that’d work), the package would be fixed? I’ll do that (though I don’t have a second Mac to try with, so I might have to rely on people’s replies on if it works properly…)
Works for me! I will repackage it, upload it, and update the post. Thanks so much!
Thanks for this. I had a slight hiccup the first time I ran it:
Referenced from: /usr/local/bin/pdftk
Reason: no suitable image found. Did find:
/usr/local/gcj/lib/libgcj.8.dylib: stat() failed with errno=13
Trace/BPT trap
I didn’t know what errno=13 meant, but exploring /usr/local/gcj/lib revealed it was not globally readable. So I ran the command
$ sudo chmod 755 /usr/local/gcj/lib
After that it worked fine!
Hopefully others will have success. And hopefully the library is already included as part of the base install; we’ll need to hear from others whether that’s the case or not.
In any case, thanks for doing this build!
Matthew: Fixed that, thanks for the heads-up!
Hey, Matthew…
Are you running 10.6.2? Did you install the Xcode tools? If you look in your /usr/lib directory do you have a file named libstdc++.6.dylib (or something very similar)?
Thanks.
Azhrei: Yes, yes, and yes. I have these files:
/usr/lib/libstdc++.6.0.9.dylib
/usr/lib/libstdc++.6.dylib
Azhrei, Matthew: FWIW, the rights issue was me making a mistake with the packaging. I fixed it in the meantime, sorry about that.
Hi,
I installed this package, but there was no pdftk in this path:
/usr/local/bin
that means:
$ ls /usr/local/bin/ | grep pdf
dvipdf
pdf2dsc
pdf2ps
pdfopt
ps2pdf
ps2pdf12
ps2pdf13
ps2pdf14
ps2pdfwr
What do I do?
Thanks
alamati: Oh no, I made a typo
I apologize. If you download the package again and reinstall, it should work!
Since you appear to know how to compile pdftk on Snow Leopard, would you please inform those of us with the MacPorts project how you did it, so that I can fix the MacPorts pdftk port? Thanks.
Essentially, compile gcc including gcj, then compile pdftk against it. Curiously, I now seem to be unable to compile the version of gcc anymore that I thought I used the last time (4.2.1)… fail.
Also, the self-compiled version led to some segfaults in libstdc++, while using the library belonging to OS X did not have that problem (see comment 17).
Sadly, I am not sure how easy it’ll be to use that knowledge for MacPorts.
[...] Stop the insanity. Install pdftk without the baggage. – Link [...]
Thanks for the dmg, saved me lots of time.
[...] the blog fredericiana you can find a dmg installer containing a precompiled distribution of pdftk with all libraries [...]
Sweet, merci merci!
Thank you were much! What a relief!
I was really excited to see this package put together – thanks! I’m having a problem, though.
Everything seems to run fine from the command line, but I am getting this error when trying to build a pdf that (I assume) has images in it:
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: _iconv
Referenced from: /usr/local/gcj/lib/libgcj.8.dylib
Expected in: flat namespace
Any ideas??
I get this when I run otool. Notice the second line of output. You might check yours:
$ otool -L /usr/local/bin/pdftk
/usr/local/bin/pdftk:
/usr/local/gcj/lib/libgcj.8.dylib (compatibility version 9.0.0, current version 9.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/local/gcj/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/local/gcj/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)
Thank you for doing this! I just migrated over to Snow Leopard a month ago and have been frustrated in not being able to get pdftk back.
I’ll keep an eye on your Stapler project too — what’s the current level of functionality?
Hey Roger, glad you like it. The Stapler project is pretty functional by now: You can see the current functionality in its README file.
I’d like to compile it into a binary package (.exe file for Windows, or binary for Linux/Mac) but that’s easier said than done with a Python project
Instead, I might add a setup.py, allowing you to install and uninstall it with pip.
Thanks so much!!!
Downloaded and installed without error on 10.6.4. Unfortunately it bombs when run with this command: pdftk SM-2005-0066-NA_CS2100_SE07.pdf dump_data output report.txt
Here is the failure log:
Process: pdftk [14035]
Path: /usr/local/bin/pdftk
Identifier: pdftk
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: bash [13996]
Date/Time: 2010-06-25 16:05:26.597 -0400
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Interval Since Last Report: 505884 sec
Crashes Since Last Report: 10
Per-App Crashes Since Last Report: 2
Anonymous UUID: E4157C0E-0CB2-4450-818F-8775EA2DAECA
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000036ad837f
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libstdc++.6.dylib 0x05ff6c9f std::ostream::flush() + 17
1 libstdc++.6.dylib 0x05ff6d4b std::ostream::sentry::sentry(std::ostream&) + 53
2 libstdc++.6.dylib 0x05ff716f std::basic_ostream<char, std::char_traits >& std::__ostream_insert<char, std::char_traits >(std::basic_ostream<char, std::char_traits >&, char const*, int) + 36
3 pdftk 0x0001b967 ReportOnPdf(std::ostream&, com::lowagie::text::pdf::PdfReader*) + 1527
4 pdftk 0x0000de3b TK_Session::create_output() + 11355
5 pdftk 0x000132c6 main + 582
6 pdftk 0x00002c09 _start + 208
7 pdftk 0x00002b38 start + 40
Thread 1:
0 libSystem.B.dylib 0x985e7066 __semwait_signal + 10
1 libSystem.B.dylib 0x985e6d22 _pthread_cond_wait + 1191
2 libSystem.B.dylib 0x985e89b8 pthread_cond_wait$UNIX2003 + 73
3 libgcj.8.dylib 0x0045bcc2 _Jv_CondWait(_Jv_ConditionVariable_t*, _Jv_Mutex_t*, long long, int) + 626 (PersistenceDelegate.java:60)
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x36ad838b ebx: 0×00160000 ecx: 0×00160000 edx: 0×00000000
edi: 0x062dc858 esi: 0xbfffded8 ebp: 0xbfffde88 esp: 0xbfffde70
ss: 0x0000001f efl: 0×00010282 eip: 0x05ff6c9f cs: 0×00000017
ds: 0x0000001f es: 0x0000001f fs: 0×00000000 gs: 0×00000037
cr2: 0x36ad837f
Binary Images:
0×1000 – 0x2b2fe7 +pdftk ??? (???) /usr/local/bin/pdftk
0×454000 – 0x12a1fff +libgcj.8.dylib 9.0.0 (compatibility 9.0.0) /usr/local/gcj/lib/libgcj.8.dylib
0x5fce000 – 0x6038fe7 +libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) /usr/local/gcj/lib/libstdc++.6.dylib
0×6093000 – 0x609aff3 +libgcc_s.1.dylib ??? (???) /usr/local/gcj/lib/libgcc_s.1.dylib
0x8fe00000 – 0x8fe4162b dyld 132.1 (???) /usr/lib/dyld
0x94b7e000 – 0x94c72ff7 libiconv.2.dylib 7.0.0 (compatibility 7.0.0) /usr/lib/libiconv.2.dylib
0×96466000 – 0x96469fe7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) /usr/lib/system/libmathCommon.A.dylib
0x985b8000 – 0x9875efeb libSystem.B.dylib 125.2.0 (compatibility 1.0.0) /usr/lib/libSystem.B.dylib
0xffff0000 – 0xffff1fff libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
Model: MacPro1,1, BootROM MP11.005C.B08, 4 processors, Dual-Core Intel Xeon, 3 GHz, 6 GB, SMC 1.7f10
Graphics: ATI Radeon X1900 XT, ATY,RadeonX1900, PCIe, 512 MB
Memory Module: global_name
Bluetooth: Version 2.3.3f8, 2 service, 19 devices, 1 incoming serial ports
Network Service: Ethernet 1, Ethernet, en0
PCI Card: ATY,RadeonX1900, Display, Slot-1
Serial ATA Device: ST3500320AS, 465.76 GB
Serial ATA Device: ST31500341AS, 1.36 TB
Serial ATA Device: KINGSTON SNV425S2128GB, 119.24 GB
Serial ATA Device: ST31000333AS, 931.51 GB
Parallel ATA Device: OPTIARC DVD RW AD-7170A
Parallel ATA Device: PIONEER DVD-RW DVR-112D
USB Device: Cinergy HT USB PVR (US), 0x0ccd, 0×0075, 0xfd300000
USB Device: CP2102 USB to UART Bridge Controller, 0x10c4 (Silicon Laboratories, Inc.), 0xea60, 0x3d200000
USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0×8206, 0x5d200000
USB Device: Hub in Apple Pro Keyboard, 0x05ac (Apple Inc.), 0×1003, 0x5d100000
USB Device: Apple Optical USB Mouse, 0x05ac (Apple Inc.), 0×0304, 0x5d120000
USB Device: Apple Pro Keyboard, 0x05ac (Apple Inc.), 0x020b, 0x5d130000
FireWire Device: built-in_hub, Up to 800 Mb/sec
PDFtk is back on the Mac! Thank you.
[...] PDFtk: скачать скомпилированную версию PDFtk, а также сам рабочий процесс. Проверено только в [...]
[...] building pdftk from either MacPorts or Fink is currently broken so there is a precompiled version here. I only tested it on OS X 10.6.2, so if you use it on other versions, please let me know in the [...]
Apologies in advance for a nitpicky question – I am trying to produce and flatten forms (so they can go straight to the iPhone) and the font in the filled in form fields never seems to come out right. It just defaults to Helvetica font, even if I embed the fonts or choose other fonts I know are in the systems. If I load the FDFs in Adobe Reader everything looks good, but if I flatten on my computer the same thing happens. Any ideas on getting the merge to obey the formatting already on the forms fields?
Thanks for your work which has already been a big help!
almost….
Does not run on pre 10.6 versions. Pity, it was a good piece of work. Thanks anyway
Looks like I’m in for a long debug. What a mess eh? Something that “just works” on a Linux distro can be such a pain on a Mac.
“Does not run on pre 10.6 versions.” — not too surprising, the versions are all different, which is why this blog post says the build is for 10.6.
I agree though that it should be easier to build for sure. Would be nice if it was.
It really needs an autoconf configuration built for it. Alas, I don’t know autoconf right now and I’m so busy with another open source project that I can’t spend the time to learn it. In fact, Fred did much better than I as I never got it to build in the first place.
Worst case would at least be a makefile with an “all” target that did everything necessary for a particular version. For example, “all10-6″ could build it for 10.6 and “all10-5″ would build it for 10.5. Then the top-level “all” target could check the OS level and run “$(MAKE) all10-$level” or something similar…
The problem is that a proper build it ridiculously hard to reproduce. At the time of building this I had an “organically grown” macports instance on my Mac (which is long gone, now that I use homebrew), and now I have trouble reproducing the build. I’ll try it again one of these days. In fact, if it was reproducible, we could just submit it to homebrew and call it good.
Note that Fink now has pdftk-1.41 available for 10.6 (it needed gcc45 to provide a gcj that works on 10.6).
Hot, thanks! Might be able to snag that and make a homebrew “Formula” from it.
Yep, that’s great news Hanspeter — thank you!
I would much prefer to get my apps from a maintained repository. I suppose I should grab it and run it through its paces to make sure it will handle my documents properly.
[...] To może takie coś: pdftk 1.41 for Mac OS X 10.6 | fredericiana Bardziej szczegółowy opis działania tutaj: pdftk – the pdf toolkit Equipment: MacBook [...]