Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
Jörg Ebeling wrote: Huam... Okay, let me go some OT: I know the other readers like xpdf, kpdf and the like, but beside that they all have problems with some special images (i.e. JPEG transparency) or that they're sometimes ugly in the handling, I've one BIG problem with them... may be it's because of nescience of mine: "The all have NO reload possibility !" Wrong. With xpdf, hit R on the keyboard, or right-click the document and select "reload" from the context menu. Just tested it. :-) Imagine, you're developing in/a PDF and need to check the result very often. When using "Adobe Acrobat" as a Browser-Plugin, you've the possibility to press the "reload" button of the browser = one click. With kpdf or the like you need to close and re-open the file. I'm working the whole day with my AMD64 environment. Everything works fine. But when I need to develope in PDF I really restart my system back into IA32 only because of the "Mouseclick" case. I know, it's stupid. May be someone knows another way how to reload PDFs with one click. No problem with xpdf. Helge Hafting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
Jörg Ebeling wrote: >>7. To remove the warning during module loading: I heard about a config in preferences of acrobat (reader too?), to unload plugins. I'm currently without acrobat reader, and I don't know if there is such an option in the reader too, but I heard about it to speed up the reader in a remarkable way. Maybe someone can look into that? regards Gerhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
Jörg Ebeling wrote: > I'm working the whole day with my AMD64 environment. > Everything works fine. > But when I need to develope in PDF I really restart my system back into > IA32 only because of the "Mouseclick" case. > I know, it's stupid. > > May be someone knows another way how to reload PDFs with one click. > I think the browser-plug-in relies on a 32bit browser, maybe I'm wrong, if so please correct me. Can one try to install a 32bit browser like you are showing as example in this thread with acrobat reader? If yes, how could that work? I think the simpliest way might be to get opera 32bit *static*, test with ldd which libs are missing and configure the system that it finds the lacking 32bit libs. For example: I got the same problem with skype_static on my ubuntu amd64 box. ldd shows one lib missing. Is there an easy way to install that lib (libdbus-1.so.0) under /usr/lib32 ? (dbus might be an impossible case, I don't know). Where did you the config edit, you're talking about? The other way is to build a 32bit chroot environement and install there a 32bit browser and the acroread and plugin. I'm pretty unsure about all this 32 vs. 64 bit stuff. I need some hints to get a bit more aware on this stuff... Kind regards Gerhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
On 5/22/05, Jörg Ebeling <[EMAIL PROTECTED]> wrote: > However, haven't known that there's a config file... Simply changed it > there so that it points to the lib32 one. > > And YEA... it works !!! Glad to hear that. > I guess something other don't work now due to the config change... but > "shit happen" ;-) . I guess so, but making a copy first should solve that. > Beside that, is there a chance to get the pdf mozilla plugin working or > is that impossible at all (as long as there's no real AMD64 port) ? Try mozplugger. Seems to work for me, after a bit of tweaking. But the reload button restart acroread, which is probably necessary, but may not be what you want. > I know the other readers like xpdf, kpdf and the like, but beside that they > all have problems with some special images (i.e. JPEG transparency) or that > they're sometimes ugly in the handling, I've one BIG problem with > them... may be it's because of nescience of mine: > > "The all have NO reload possibility !" kpdf does. And gv has it in the File menu (which is not shown for a plugin, correct). Also UI of kpdf is very much improved with version 3.4: it finally scrolls nicely across pages, has page previews etc. I think it compare pretty well again acroread, as long as you do not need to fill in forms. > With kpdf or the like you need to close and re-open the file. Not any more, luckily. Just get it from ubuntu and give it a try. Imho kpdf is the one application tha makes upgrading worth it. Thomas
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
Thomas Steffen wrote:
Ok, found the problem with gdk-pixbuf.
5. Edit /usr/bin/acroread. Towards the end, there is a line
exec "$ACRO_EXEC_CMD" ${1+"$@"}
Add
GCONV_PATH=/usr/lib32/gconv LD_PRELOAD=/usr/lib32/libpangohack.so.0.0
at the beginning of this line, before exec.
This should be
GCONV_PATH=/usr/lib32/gconv
LD_PRELOAD=/usr/lib32/libpangohack.so.0.0
GDK_PIXBUF_MODULE_FILE=/etc/gtk-2.0/gdk-pixbuf.loaders32
6. Copy /etc/gtk-2.0/gdk-pixbuf.loaders to
/etc/gtk-2.0/gdk-pixbuf.loaders32, and replace all references to
/usr/lib/ with /usr/lib32/:
sed 's:/usr/lib/:/usr/lib32/:' < /etc/gtk-2.0/gdk-pixbuf.loaders >
/etc/gtk-2.0/gdk-pixbuf.loaders32
7. To remove the warning during module loading:
rm /usr/lib/Adobe/Acrobat7.0/Reader/intellinux/plug_ins/PPKLite.api
Hm, 7 steps is a bit much. Looks like a script should do that :-) Does
it work for you?
Yeah, now everything is perfect !!
Lot thanks !!
Jörg
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
Thomas Steffen wrote: I am glad that you are verifying my approach. I was afraid that I forgot a step that I did, and that seems to be true. Anyway, once it *really* works, I may put it into the FAQ. Ahhh, don't worry about it... you already solved it again... read on... ;-) On 5/22/05, Jörg Ebeling <[EMAIL PROTECTED]> wrote: With your cool description I get the reader now loaded/started, but get a small "Adobe Reader" MessageBox with a warning: "There was an error while loading the plug-in 'PPKLite.api'. The plug-in failed to initialize." Yep, I get that, too. I don't even know what that module is for, so I am not worried :-) Deleting the module should "fix" the warning. Ahh, deleting works :-D ... such easy :-[ . "(acroread:7941): GdkPixbuf-WARNING **: Error loading XPM image loader: Bildlader-Modul konnte nicht geladen werden: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: cannot open shared object file: Datei oder Verzeichnis nicht gefunden" Ok, so pixbuf is a real problem. The issue is that it is using the config file in /etc/gtk-2.0/???, which points to the mentioned libpixbufloader-xpm.so. Since this is an amd64 shared library, it cannot be loaded into the ia32 binary. Which gives me an idea: if you add the ia32 libpixbufloader (probably in /usr/lib32) *in addition* to this one, it should work for both kinds of binaries. I already have them in the libs32 too... However, haven't known that there's a config file... Simply changed it there so that it points to the lib32 one. And YEA... it works !!! I guess something other don't work now due to the config change... but "shit happen" ;-) . Looot thanks !!! Beside that, is there a chance to get the pdf mozilla plugin working or is that impossible at all (as long as there's no real AMD64 port) ? If the plugin spawns a separate process, probably yes. But my experience with plugins is extremely mixed. As a plugin I prefer kpdf 3.4 in konqueror anyway. Huam... Okay, let me go some OT: I know the other readers like xpdf, kpdf and the like, but beside that they all have problems with some special images (i.e. JPEG transparency) or that they're sometimes ugly in the handling, I've one BIG problem with them... may be it's because of nescience of mine: "The all have NO reload possibility !" Imagine, you're developing in/a PDF and need to check the result very often. When using "Adobe Acrobat" as a Browser-Plugin, you've the possibility to press the "reload" button of the browser = one click. With kpdf or the like you need to close and re-open the file. I'm working the whole day with my AMD64 environment. Everything works fine. But when I need to develope in PDF I really restart my system back into IA32 only because of the "Mouseclick" case. I know, it's stupid. May be someone knows another way how to reload PDFs with one click. Cya Jörg
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
Ok, found the problem with gdk-pixbuf.
> 5. Edit /usr/bin/acroread. Towards the end, there is a line
> exec "$ACRO_EXEC_CMD" ${1+"$@"}
> Add
> GCONV_PATH=/usr/lib32/gconv LD_PRELOAD=/usr/lib32/libpangohack.so.0.0
> at the beginning of this line, before exec.
This should be
GCONV_PATH=/usr/lib32/gconv
LD_PRELOAD=/usr/lib32/libpangohack.so.0.0
GDK_PIXBUF_MODULE_FILE=/etc/gtk-2.0/gdk-pixbuf.loaders32
6. Copy /etc/gtk-2.0/gdk-pixbuf.loaders to
/etc/gtk-2.0/gdk-pixbuf.loaders32, and replace all references to
/usr/lib/ with /usr/lib32/:
sed 's:/usr/lib/:/usr/lib32/:' < /etc/gtk-2.0/gdk-pixbuf.loaders >
/etc/gtk-2.0/gdk-pixbuf.loaders32
7. To remove the warning during module loading:
rm /usr/lib/Adobe/Acrobat7.0/Reader/intellinux/plug_ins/PPKLite.api
Hm, 7 steps is a bit much. Looks like a script should do that :-) Does
it work for you?
Thomas
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
I am glad that you are verifying my approach. I was afraid that I forgot a step that I did, and that seems to be true. Anyway, once it *really* works, I may put it into the FAQ. On 5/22/05, Jörg Ebeling <[EMAIL PROTECTED]> wrote: > With your cool description I get the reader now loaded/started, but get > a small "Adobe Reader" MessageBox with a warning: >"There was an error while loading the plug-in 'PPKLite.api'. The > plug-in failed to initialize." Yep, I get that, too. I don't even know what that module is for, so I am not worried :-) Deleting the module should "fix" the warning. > "(acroread:7941): GdkPixbuf-WARNING **: Error loading XPM image loader: > Bildlader-Modul konnte nicht geladen werden: > /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: > /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: cannot open > shared object file: Datei oder Verzeichnis nicht gefunden" Ok, so pixbuf is a real problem. The issue is that it is using the config file in /etc/gtk-2.0/???, which points to the mentioned libpixbufloader-xpm.so. Since this is an amd64 shared library, it cannot be loaded into the ia32 binary. Which gives me an idea: if you add the ia32 libpixbufloader (probably in /usr/lib32) *in addition* to this one, it should work for both kinds of binaries. I may have a look at this later. (and maybe that trick also works for pango?) > Beside that, is there a chance to get the pdf mozilla plugin working or > is that impossible at all (as long as there's no real AMD64 port) ? If the plugin spawns a separate process, probably yes. But my experience with plugins is extremely mixed. As a plugin I prefer kpdf 3.4 in konqueror anyway. Thomas
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
Well I tried to get Acrobat 7 working multiple times without success, therefore I'm happy to see that I'm not the onliest who needs the real "Adobe Acrobat Reader" application. With your cool description I get the reader now loaded/started, but get a small "Adobe Reader" MessageBox with a warning: "There was an error while loading the plug-in 'PPKLite.api'. The plug-in failed to initialize." That don't seem to harm because the reader starts successful after that MSG, but when I try to open any kind of PDF, it automatically closes with a remaining MSG: "(acroread:7941): GdkPixbuf-WARNING **: Error loading XPM image loader: Bildlader-Modul konnte nicht geladen werden: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so: cannot open shared object file: Datei oder Verzeichnis nicht gefunden" I checked the existence of "libpixbufloader-xpm.so" and I found it in lib32 as well as in lib64. Any suggestions ? Beside that, is there a chance to get the pdf mozilla plugin working or is that impossible at all (as long as there's no real AMD64 port) ? Kind regards Jörg
Re: Success with Acrobat Reader 7.0 (tweaking module pathes)
On 5/21/05, Thomas Steffen <[EMAIL PROTECTED]> wrote:
[getting acroread to work]
I think I found an end user friendly way now to install acroread on a
pure64 system.
1. Get ia32-libs and install it. Just about any version should work:
testing, unstable, or ubuntu hoary. If you are unsure, do "apt-get
install ia32-libs".
2. Get ia32-libs-gtk from ubuntu:
http://archive.ubuntu.com/ubuntu/pool/main/i/ia32-libs-gtk/ia32-libs-gtk_4_amd64.deb
, and install it with "dpkg -i ia32-libs-gtk_4_amd64.deb".
3. Get the acroread debian package from
ftp://ftp.nerim.net/debian-marillat/dists/testing/main/binary-i386/acroread_7.0-0sarge0.9_i386.deb
. While you are at it, you may also get the extra plugins.
4. Install it with dpkg -i --force-all acroread_7.0-0sarge0.9_i386.deb
. It wont go without force, because it is the wrong architecture.
5. Edit /usr/bin/acroread. Towards the end, there is a line
exec "$ACRO_EXEC_CMD" ${1+"$@"}
Add
GCONV_PATH=/usr/lib32/gconv LD_PRELOAD=/usr/lib32/libpangohack.so.0.0
at the beginning of this line, before exec.
That is still a bit messy, but for the time being it will have to do.
Do you think there is any chance of:
1. Adobe taking this patch on?
2. Marillat including it?
3. Ubuntu packaging acroread 7.0?
4. Debian getting an acroread installer?
Any of these parties could hide the difficulties and make a package
that "just works".
Thomas
Success with Acrobat Reader 7.0 (tweaking module pathes)
I know, xpdf and gv do a nice job with PDF most of the time, but sometimes you need the real deal. So I forced the (ia32) acroread package from marillat onto my amd64 system. While it does works fine inside of an ia32 chroot, it does not work when it is installed in the (amd64) root. Since I am not a big fan of running anything in chroot, I went to explore the issue. It seems to be pretty generic, so I think it might hit other applications, too. All problems are related to the dynamic loading of shared modules (libdl/dlopen). This is not a surprise: while you can tell ld.so to look for the right libraries in /emul/ia32-linux/lib, the path for dynamic loading is set by the library itself, and still pointing to the "wrong" directory. As a seasoned "real programmer", I have solved this with a hex editor, but I would not recommend that :-) 1. The modules in /usr/lib/gconv cannot be loaded, because they are amd64 of course. Setting GCONV_PATH=/emul/ia32-linux/usr/lib/gconv should be sufficient. I have filed a bug with ia32-libs, because I think this should be fixed during the build process. 2. gtk-2.0 is required, which is not included in ia32-libs. If you copy it from a chroot installation (or include a chroot in /etc/ld.so.conf), gtk pixbuf does not work, because it tries to load format specific modules from /usr/lib/gtk-2.0/2.4.0/loaders. Since it only loads the xpm module, maybe Acrobat works without this. 3. And pango looks for its modules in /usr/lib/pango/1.4.0/modules, which is again wrong. It should be possible to override that with a new configure file and by setting PANGO_RC_FILE, but I was never really successful in configuring pango, so I let somebody else figure that out. I imagine that any executable that uses gnome runs into the same problems, so fixing them would be very useful. Including gnome in ia32-libs (or creating ia32-gnome-libs) seems like the way to go. I know how difficult it is to compile gnome, so I don't envy the packager. In the long run, I think we need multiarch to take care of this. The problem is that the path of loadable modules is specified in configuration files. I think this is a very bad idea, but gnome does it extensively. So either a better way of finding loadable modules has to be found and implemented in gnome, or multiarch has to differentiate configuration files, too. Thomas
