32-bit compatibility on a 64-bit AMD box ??
I have a 64-bit Linux 2.6.18 system.. I normally compile my own libraries & apps (Gnome, KDE) as 64-bit whenever possible - no problems. But some stuff such as OpenOffice still only seems to work as 32-bit, and proprietary stuff like Opera, Sun Java & Flash only comes as 32-bit binary. I then run into problems when they either try to load a shared library or need to be run from a 64-bit app - doesn't work.
I have a full /usr/lib64, which I keep up to date with libraries I compile, and /usr/lib32 with a basic set of 32-bit libraries, such as Sun Java and Flash.
But I'm stuck with a 64-bit Konqueror web browser which won't use Flash or Java, and OpenOffice which won't use my /usr/lib64 libraries.
I don't want to be locked in to having and maintaing 32 bit versions of everything, including only using a 32-bit web browser, to make this all work, it's a stupid idea.
So.. is there any magic to let my 64-bit Gnome & KDE apps load these few 32-bit shared libraries, and 32 bit apps like OpenOffice load my 64-bit shared libraries - is there any guide to how to retain 32-bit compatibility on a 64-bit system ? Or am I compiling my libraries & apps wrong ?
can I break your question into parts pls
1) I compile using my own config file...from a vanilla kernel running on the latest mandriva 2007 but I deliberately use konq only as a file manager and have firefox running as a 32 bit.
This firefox gets the links java and flashplayer
2) never looked seriously at what my open office is but I feel for you....there are still a number of posters saying they keep to 32 bit.
3) I may be wrong but I do believe a 32 bit system file can run in a 64 bit application and vice versa so you have done nothing wrong.
The 32-bit and 64-bit ABI's are not the same so you can't use 32-bit libraries with 64-bit applications and vice-versa. The machine code is different, plus the 64-bit instruction set is expanded and will likely be taken advantage of. For any application that you want to run 32-bit, you'll need a 32-bit library and possibly headers, although only a couple of applications I can think of needed separate headers.
Open Office v2.0.4 built and runs fine as a 64-bit application albeit with some hacking. That was the first version Sun released with claimed 64-bit support. Sun provides a 64-bit Java binary at their download site. However, the last time I checked Sun only offered a 32-bit browser plugin. There are no 64-bit versions of Acrobat Reader or Macromedia Flash. I don't know about Opera.
If you just gotta have Flash and Acrobat support in Firefox, you'll need a 32-bit version. If it were me, I would build just a 32-bit version until Adobe gets off their duff and gives us a 64-bit version of Acrobat and Flash. Firefox takes awhile to build; why have two of something that takes that long?! The other option is to build a 64-bit version and then install a 32-bit precompiled binary.
FYI, if you're trying to conform to the FHS, 32-bit/31-bit libraries live in /usr/lib and 64-bit libraries live in /usr/lib64. Unless, of course, you have an IA64 architecture, then 64-bit libraries go in /usr/lib and 32/31-bit libraries go in /usr/lib32.
I use opera as 32bit browser and that works fine with flash etc. - dunno about the sound,don't have sound.
Openoffice 2.0.4 does compile for me as 64 bit app with gentoo - no idea what patches they applied though.
As far as I know it seems that most distros settled on the lib32 and lib64 thing.What is in there is different though.Opera might not work for you.
The only things I could think of right now that only work with 32 bit are flash and M$ media codecs but I am sure there is more.Might not be worth the effort to keep up an 32bit environment.
There is some doc on setting up a 32bit chroot although I am not sure that is what you need http://www.gentoo.org/proj/en/base/a...?part=1&chap=2
Thanks for your feedback guys. Sounds like there is no magic fix to allow 32 & 64 bit components to talk to each other. So I need separate environments for 32 and 64-bit components. I also found this link a useful explanation of the problem :-
So I went with the apparent standard of having /usr/lib64 for 64-bit and /usr/lib for 32-bit libraries. Then I found it difficult to restrict the build process to the correct environment. It turned out that pkg-config, which tells the build process where to find linker instructions, ignores PKG_CONFIG_PATH, it needs PKG_CONFIG_LIBDIR to tell it whether to use /usr/lib64/pkg-config or /usr/lib/pkgconfig. I use --libdir= to tell config where to install into.
So far so good. Then I find some builds (like tiff) don't use pkgconfig to find libraries like jpeg, it requires --with-jpeg-lib-dir=/usr/lib64 otherwise it defaults to linking with /usr/lib (32-bit).
I'm also having trouble with glibmm (c++ bindiings for glib) which tries to link to /usr/lib for some reason.
|All times are GMT -5. The time now is 10:08 AM.|