UNIX for Advanced & Expert Users

Hi all,

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 ***

======= Backtrace: =========
/lib/libc.so.6(+0x6e143)[0xf69ea143]
/lib/libc.so.6(+0x74984)[0xf69f0984]
/lib/libc.so.6(realloc+0x2f3)[0xf69f50d3]
/home/myprogram[0x8065b47]
/home/emperor/DAQNAV_V1/myprogram[0x805d33b]
/lib/libpthread.so.0(+0x6d4c)[0xf6b40d4c]
/lib/libc.so.6(clone+0x5e)[0xf6a7382e]
======= Memory map: ========
08048000-08081000 r-xp 00000000 fe:04 3407960 /home/emperor/DAQNAV_V1/myprogram-client-backup
08081000-08086000 rw-p 00038000 fe:04 3407960 /home/emperor/DAQNAV_V1/myprogram-client-backup
08086000-08181000 rw-p 00000000 00:00 0 [heap]
f4300000-f4321000 rw-p 00000000 00:00 0
f4321000-f4400000 ---p 00000000 00:00 0
f447e000-f447f000 ---p 00000000 00:00 0
f447f000-f4c7f000 rw-p 00000000 00:00 0
f5b52000-f5b62000 r-xp 00000000 fe:00 140405 /usr/lib/libcanberra.so.0.2.5
f5b62000-f5b63000 r--p 0000f000 fe:00 140405 /usr/lib/libcanberra.so.0.2.5
f5b63000-f5b64000 rw-p 00010000 fe:00 140405 /usr/lib/libcanberra.so.0.2.5
f5b64000-f5b68000 r-xp 00000000 fe:00 140432 /usr/lib/libcanberra-gtk.so.0.1.9
f5b68000-f5b69000 r--p 00003000 fe:00 140432 /usr/lib/libcanberra-gtk.so.0.1.9
f5b69000-f5b6a000 rw-p 00004000 fe:00 140432 /usr/lib/libcanberra-gtk.so.0.1.9

And the list goes on and on......

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?

Thanks a lot!

It couldn't even try to run if you didn't have the 32-bit ones available. Linux can tell the difference.

As for why it's crashing, perhaps your 32-bit machine had a very different version of GTK, or your program simply has a bug. Troubleshoot it and see.

Well I know the gtk2.22 32bit versions are not installed because I can't install the rpm package that contains them.

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:

Code:

lrwxrwxrwx 1 root root      11 Aug 26  2014 libpam.so -> libpam.so.0
lrwxrwxrwx 1 root root      16 Aug 26  2014 libpam.so.0 -> libpam.so.0.83.1
-rwxr-xr-x 1 root root   55760 Aug 26  2014 libpam.so.0.83.1

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).

Hi.
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.

2) Compile it in 64-bit bit mode on F20.

Like I said, shots in the dark.

Best wishes ... cheers, drl