Is Linux compat still the correct way to run Acrobat Reader under FreeBSD?

I haven't tried though, but will, since rarely I need to fill out official forms in PDF.
Okular supports forms too. It also has a special review mode for annotating PDFs with notes, drawings, highlights etc. It has the best support for this of all open source PDF viewers AFAIK.
 
Well, Okular is a KDE application. I'm using a very slim desktop environment with x11-wm/dwm.
I need emulators/wine to run a couple of commercial programs anyway.

My first try with wine:
1. I downloaded Adobe Reader 11.0.10 for Win7 from: https://get.adobe.com/reader/otherversions/
2. To be able running the installer I needed winetricks from: https://wiki.winehq.org/Winetricks
3. Winetricks in its turn needed archivers/cabextract
4. I ran winetricks mspatcha
5. I ran the Adobe Reader installer
It works! However wine(1) ver. 1.9.4 crashes when I open a fillable form PDF.
 
Reader 11 is not wanted here. Not even 10. Adobe 9 was the latest that we are prepared to tolerate, everything Adobe have done since received very adverse reaction from our users who did not want anything to do with the UI changes which they thought were inconsiderate on Adobe's part.
 
From a security point of view (and I insist that's the POV a system operator should have -- while it's great to be helpful to your users, they won't thank you in the event something bad happens ...), this is just getting worse here. Just saying. But then, there shouldn't be a problem getting the old Linux version of the Reader to run with linux compat. Did you try?
 
No, I did not try the old reader for Linux as I could not find one anywhere. It seems to have vanished from the ports.
It is still available from Adobe but when I tried to run INSTALL.sh it said that it would not work on this system, and I did not have time to play any further.
 
Ah sure it won't work without some fiddling. Well the reason why it "vanished" should be pretty clear now, but svn doesn't forget, so you can as SirDice already mentioned take the latest version of that port as a starting point. Maybe at least jailing it would be a good idea ...

edit: Didn't pay attention, I meant this port, of course. Will be some work as well to fix e.g. dependencies ....
 
Ah sure it won't work without some fiddling. Well the reason why it "vanished" should be pretty clear now, but svn doesn't forget, so you can as SirDice already mentioned take the latest version of that port as a starting point. Maybe at least jailing it would be a good idea ...

Given the pace of ports evolution, having an undeleted port work without modification would be quite lucky.
Somebody familiar with ports can quickly fix whatever went obsolete (unless it's a dependency) but somebody with zero experience would be lost, even if they manage to pull it from svn archive. Ports stop building surprisingly quickly if they aren't maintained with rest of tree.
 
Somebody familiar with ports can quickly fix whatever went obsolete (unless it's a dependency) but somebody with zero experience would be lost
I really didn't expect it to be a big problem, but you're right! Now I was hooked and I HAVE it working, but I didn't expect this would involve hacking some kernel module code. What the hell is this? Adobe Reader 9 would crash when sched_setscheduler syscall returned an error and to work around this, back then, a kernel module was created just to hijack that syscall and ignore errors in case the calling process is acroread? Seriously? This was obvioulsy a piece of junk even when it was supported by Adobe :eek:

Nevertheless, here it is, in all its glory (showing a file I created myself with latex, just to be sure):
acroread.png

The patches themselves aren't huge, though.
 
I think it would be easier to convince the user to downgrade to FreeBSD 9. Remember: the users always get what they want.
 
I think it would be easier to convince the user to downgrade to FreeBSD 9.
The downgrade wouldn't help here, ports are the same for all versions, and this port is -- as it should be -- long dead. But as you can see, it's still possible to build it. You can pull my modified source (these ports are all in the "obsolete" directory) and try yourself...
Remember: the users always get what they want.
This is definitely not true in any organization where the CISO takes his job seriously. While IT tries to provide anything users need, which is the primary goal, the party ends where the user demands a horribly insecure solution.
 
I thought that the older FreeBSD have the ports tree on the DVD media. There's installation option to install the ports IIRC. Does it not contain acroread9 anymore?
 
Using the ports tree from an old DVD is the same as checking out an old revision of this whole tree. Sure you will have this port available. But you will have to stick with ages-old versions of all other ports, too. This includes a heap full of unfixed security issues in all ports. As soon as you update your tree with portsnap or svn, acroread9 will be gone for good.

edit: Really, no offense intended, but this idea is even a lot more dangerous than installing acroread9 alone. If you still feel you absolutely need to have acroread9, use my updated ports posted above.
 
Thank you for the patches and pointer at the SVN old revision!
I must be doing something wrong with the patches. Downloaded the files, checked out SVN revisions:

Code:
root@leo00:/usr/ports/print/acrobatviewer# make
===>  Staging for acroread9-9.5.5_1
===>  acroread9-9.5.5_1 depends on package: acroreadwrapper>=0.0.20110529 - not found
===>  Patching for acroreadwrapper-0.0.20130208
===>  Applying FreeBSD patches for acroreadwrapper-0.0.20130208
Ignoring previously applied (or reversed) patch.
1 out of 1 hunks ignored--saving rejects to Makefile.rej
=> Patch patch-Makefile failed to apply cleanly.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/print/acroreadwrapper
*** Error code 1

Stop.
make: stopped in /usr/ports/print/acrobatviewer

Code:
root@leo00:/usr/ports/print/acroreadwrapper# make
===>  Patching for acroreadwrapper-0.0.20130208
===>  Applying FreeBSD patches for acroreadwrapper-0.0.20130208
Ignoring previously applied (or reversed) patch.
1 out of 1 hunks ignored--saving rejects to Makefile.rej
=> Patch patch-Makefile failed to apply cleanly.
*** Error code 1

Stop.
make: stopped in /usr/ports/print/acroreadwrapper
 
What files did you download? What I linked to above were my changes to the very latest revisions of the required ports just before deletion. Tested ok on 11.0-CURRENT and should probably work on other versions as well, when my poudriere machine finishes a bulk, I can put them to a test just to see.

If you really really still want to install this mess, your easiest option would be:
  1. Get my ports working tree: git clone https://github.com/zirias/zfbsd-ports
  2. Go to the obsolete directory
  3. make install clean in www/linux-libgtkembedmoz, print/acroreadwrapper and print/acroread9, in this order.

But I, once again, strongly suggest you have a look at the latest version of graphics/okular instead, it's come a long way and does everything quite fine now. Opening up security holes just to accomodate habit really isn't worth it.
 
That worked but acrobat still does not run:

Code:
[root@leo00 /]# acroread
acroread  acroread8  acroread9 
[root@leo00 /]# acroread
/usr/local/Adobe/Reader9/ENU/Adobe/Reader9/Reader/intellinux/bin/acroread: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/libgdk_pixbuf-2.0.so.0)
/usr/local/Adobe/Reader9/ENU/Adobe/Reader9/Reader/intellinux/bin/acroread: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/libpng12.so.0)
/usr/local/Adobe/Reader9/ENU/Adobe/Reader9/Reader/intellinux/bin/acroread: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/libcairo.so.2)
[root@leo00 /]# acroread8
?warning: localized acroread (ENU) not found.
!fatal: No acroread binary found.  Check $LANG or $ADOBE_LANG, and installed acroread packages.
[root@leo00 /]# acroread9
/usr/local/Adobe/Reader9/ENU/Adobe/Reader9/Reader/intellinux/bin/acroread: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/libgdk_pixbuf-2.0.so.0)
/usr/local/Adobe/Reader9/ENU/Adobe/Reader9/Reader/intellinux/bin/acroread: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/libpng12.so.0)
/usr/local/Adobe/Reader9/ENU/Adobe/Reader9/Reader/intellinux/bin/acroread: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/libcairo.so.2)

I must be doing something wrong.
 
That looks more like a version mismatch of linux-c6 ports. My linux_base-c6 is version 6.7_1. Oh and you're running acroread as root. Eeek.
 
But I, once again, strongly suggest you have a look at the latest version of graphics/okular instead, it's come a long way and does everything quite fine now. Opening up security holes just to accomodate habit really isn't worth it.

And a day will come when that Adobe software is not going to work with any modern system. It's going to be alot more painful to switch then, instead of just getting it over with now.
 
Being headstrong about wanting an old version I can almost understand, but when also running as root I start to think this is trolling.
 
Yes, obviously it doesn't, as your glibc version doesn't match some other linux libs. Try upgrading all your linux-c6 related ports/packages. The point is, you try running it as root, and given your linux libs issue is resolved, it would run as root. Still trying to keep you shooting your foot harder than necessary, I say at least run it as an unprivileged user.
 
Not sure what else I can upgrade. It is what comes down from the ports today.
I did portsnap fetch extract, uninstalled everything mentioned in this thread, rebuilt and reinstalled and still getting the same errors.
This confuses me:
your glibc version doesn't match some other linux libs
I am not sure I understand significance of the bold part. Doesn't glibc come with linux-c6? If c6 installs a wrong version, or acroread9 expects a wrong version, what a user like me should do?
 
Not sure what else I can upgrade. It is what comes down from the ports today.
I did portsnap fetch extract, uninstalled everything mentioned in this thread, rebuilt and reinstalled and still getting the same errors.
This confuses me:

I am not sure I understand significance of the bold part. Doesn't glibc come with linux-c6? If c6 installs a wrong version, or acroread9 expects a wrong version, what a user like me should do?

Welcome to the wonderful world of Linux distros and their refusal of co-ordinating of what should be in their "base system" ;)

You would need an acroread binary that is built for CentOS 6.5 which I think is not available. The other solution would be to find suitable compatibility libraries for CentOS 6.5 for running older applications from earlier versions of CentOS or from other distros.
 
kpa, this is NOT the issue here. The messages looked like /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/lib/libgdk_pixbuf-2.0.so.0). That this happens trying to run acroread is irrelevant, it says the installed libgdk_pixbuf-2.0.so.0 is not happy with the symbol/version info in glibc. Both come from the linux-c6 ports, so something is broken on the OP's system. acroread itself happily runs with the most recent linux-c6 ports, see my screenshot above.
 
At this point it sounds like weirdness of Fedora is a lesser pain than fighting the complete showstopper mysteries of FreeBSD 10.1 (the only recent version which does not constantly go into kernel panic from almost everything) or staring at the kernel dumping memory in FreeBSD 10.3 or PCBSD 10.3 several times a day.

I did not have anywhere near that many issues in FreeBSD 9, it is sounding like brain rot of Linux has infected FreeBSD project as well by this time. It was nice while it lasted, and slowly but surely the entire free/open source software world is sliding into a cess pit as releasing without testing becomes a norm.

I get paid peanuts for working for a worldwide charity organization that teaches the poorest people how to open their own small business to change their lives and the lives of their communities instead of immigrating into the Western hemisphere and overburdening already overstretched welfare systems, and we depend on free software. With its overall quality getting out of hand and its hardware requirements skyrocketing, we may have to close shop. At least from my pinhole view of its IT infrastructure I see how the front line people get frustrated not being able to do their work. I never thought that a day will come when I will have to tell them there is no more help I can offer. Most of them are seriously pissed by the direction the enlightened ivory tower dweller software developers are taking the OSs, window managers and software packages they are used to and trained for. None of them cares for the security issues you are so worried about, as they know full well that their work is primarily performed on the government produced PDFs, offline with no internet connection for weeks or months, but of course that is insignificant for the the geeks.

One very wise man used to say: you may be 100% correct, but at the same time totally wrong.
 
Back
Top