So, I have a 32 bit gtk2.22 application that I run flawlessly in Fedora 14.
When I compile it on the 32bit machine run it on Fedora 20 64bit machine I get:
(myprogram:6736): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(myprogram.:6736): Gtk-WARNING : Unable to locate theme engine in module_path: "adwaita",
Gtk-Message: Failed to load module "pk-gtk-module"
Executing RunOnce* Error in `myprogram': realloc(): invalid pointer: 0xf4300040 ***
Installed on the Fedora 20 machine are the 64 bit gtk binaries for version 2.24. My program depends on the 32bit binaries of version 2.22.
My guess is that this is why my program seg faults.....
I havea ll of the rpm packages for the gtk 32bit binaries but I am lost on how to set all of this up to run....any help?
It couldn't even try to run if you didn't have 32-bit ones available. Could not. Not even long enough to just crash. It's a logical contradiction. All you'd get is "no such file or directory." It runs, therefore, you have them.
So, they're there. How did they get there? On a 64-bit system, some common 32-bit libraries are often bundled up in one "emulation" package rather than installing 32 and 64 bit versions of the same thing. This is to avoid confusing the package manager. I don't know precisely what they call that package (or packages) in Fedora.
Well I guess if the drawing calls are to an older version of gtk(2.22) maybe this is causing problems....I would really like to be able to just run the program with the old libraries....didn't think it was that hard to setup.
You often do need to worry about versions, sadly. This is why different distributions often have their own packages. You may be able to be more specific about what version it uses, i.e. -lgtk-version instead of -lgtk, so that it gives 'file not found' instead of crashing when supplied with an incompatible version. Libraries are usually available under many names from the most generic to the most specific, allowing programs to be as picky or generic as will work:
so linking to generic 'pam' means 'I expect this program to work with any PAM from any era', linking to pam-0 means 'I expect this to work with any version 0.*', and linking to pam-0.83.1 means 'this program will work with only this exact version of pam'
If you could find out what version of GTK you have in your emulation packages that might help solve the mystery. Try ldd ./myprogram to see what libraries it has ended up using.
Lastly, I'd note that you haven't actually ruled out a bug in your program yet. More may have changed than you realized in moving from one machine to another of any bit width. Recompile with debugging info, and check through your program step by step as it runs on the 64-bit machine (i.e. using gdb).
This sounds like you are doing cross-compiling: making the executable on F14, then transferring the binary to F20.
If so, then the comments from Corona688 are applicable. There is, what, 6 years difference between F14 and F20? Lots of time for stuff to change.
If I were in this position, I would do the following:
1) Try making a static binary of the executable on F14. That would effectively take the libraries with you. However, if it does dynamic loading, it wil probably still fail.
I have tried cross-compiling but have also compiled on the 64bit machine. The problem seems to be coming from the ldd command.
It says I am linking against different .so files at runtime on the 64 bit machine than the 32 bit machine. Would installing the correct 32 bit gtk binaries solve this issue?
What does ldd show on the 32-bit machine, and what does ldd show on the 64-bit machine?
Like I said, it may be possible to make it depend on a specific version of GTK. This would at least cause it to fail to load instead of crashing when a compatible version isn't available.
Like I also said, it's even possible that the 32-bit emulation library has several versions of GTK, and linking a less generic name will cause it to load the correct one.
And also like I said, we haven't even ruled out there being a bug in your program yet. We're only assuming linking is the problem.
There is no bug in the program.
It is a widely distributed application that runs without problems. Tried and Tested.
Using your ldd command brought up some interesting things:
All of the dependencies displayed by ldd had Symlinks to newer GTK modules on the 64bit machine than the 32bit machine. This makes sense because I have not been able to install GTK2.22 on the 64bit machine. The oldest I could find was GTK2.24. I am thinking that if there was a way to somehow install these 32bit GTK2.22 this may solve my problem.
I just dont know how to install it, let along link to it.....
How did you decide that 64-bit had links to "newer GTK modules"? They both link to the generic 2.0 module. It seems to link to the 64-bit version, even, causing me to suspect you ran ldd on the version compiled for 64-bit, not the version you want to install libraries for.
Nope. I ran ldd on the version compiled on the 32bit machine.
The problem lies into the symbolic links which aren't evident in that output. Those files link to different actual .so files.