32bit GTK2 application

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:

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

Thanks for the help guys.

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?

Is that possible on a 64 bit machine?

Thanks

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.

1 Like

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

Could you post the actual output I asked for please?

It would help me give actual suggestions instead of vague guesses.

Oh sorry. No problem.

64 bit machine:

    linux-gate.so.1 =>  (0xf771e000)
    libgtk-x11-2.0.so.0 => /lib/libgtk-x11-2.0.so.0 (0xf7243000)
    libgdk-x11-2.0.so.0 => /lib/libgdk-x11-2.0.so.0 (0xf7185000)
    libatk-1.0.so.0 => /lib/libatk-1.0.so.0 (0xf7163000)
    libgio-2.0.so.0 => /lib/libgio-2.0.so.0 (0xf6fef000)
    libpangoft2-1.0.so.0 => /lib/libpangoft2-1.0.so.0 (0xf6fd8000)
    libpangocairo-1.0.so.0 => /lib/libpangocairo-1.0.so.0 (0xf6fcb000)
    libgdk_pixbuf-2.0.so.0 => /lib/libgdk_pixbuf-2.0.so.0 (0xf6fa4000)
    libm.so.6 => /lib/libm.so.6 (0xf6f5d000)
    libcairo.so.2 => /lib/libcairo.so.2 (0xf6e1c000)
    libpng12.so.0 => /lib/libpng12.so.0 (0xf6df2000)
    libpango-1.0.so.0 => /lib/libpango-1.0.so.0 (0xf6da7000)
    libfreetype.so.6 => /lib/libfreetype.so.6 (0xf6d05000)
    libfontconfig.so.1 => /lib/libfontconfig.so.1 (0xf6cc9000)
    libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0xf6c77000)
    libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0xf6c71000)
    libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0xf6c6e000)
    librt.so.1 => /lib/librt.so.1 (0xf6c65000)
    libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xf6b34000)
    libproj.so.0 => /lib/libproj.so.0 (0xf6ae9000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xf6acd000)
    libc.so.6 => /lib/libc.so.6 (0xf690e000)
    libX11.so.6 => /lib/libX11.so.6 (0xf67d2000)
    libXfixes.so.3 => /lib/libXfixes.so.3 (0xf67cc000)
    libXrender.so.1 => /lib/libXrender.so.1 (0xf67c1000)
    libXinerama.so.1 => /lib/libXinerama.so.1 (0xf67bd000)
    libXi.so.6 => /lib/libXi.so.6 (0xf67ab000)
    libXrandr.so.2 => /lib/libXrandr.so.2 (0xf67a0000)
    libXcursor.so.1 => /lib/libXcursor.so.1 (0xf6794000)
    libXcomposite.so.1 => /lib/libXcomposite.so.1 (0xf6790000)
    libXdamage.so.1 => /lib/libXdamage.so.1 (0xf678c000)
    libXext.so.6 => /lib/libXext.so.6 (0xf6779000)
    libffi.so.6 => /lib/libffi.so.6 (0xf6771000)
    libdl.so.2 => /lib/libdl.so.2 (0xf676c000)
    libz.so.1 => /lib/libz.so.1 (0xf6755000)
    libselinux.so.1 => /lib/libselinux.so.1 (0xf6731000)
    libresolv.so.2 => /lib/libresolv.so.2 (0xf6717000)
    libharfbuzz.so.0 => /lib/libharfbuzz.so.0 (0xf66be000)
    libpng16.so.16 => /lib/libpng16.so.16 (0xf6687000)
    /lib/ld-linux.so.2 (0xf771f000)
    libpixman-1.so.0 => /lib/libpixman-1.so.0 (0xf65da000)
    libEGL.so.1 => /lib/libEGL.so.1 (0xf65b0000)
    libxcb-shm.so.0 => /lib/libxcb-shm.so.0 (0xf65ac000)
    libxcb-render.so.0 => /lib/libxcb-render.so.0 (0xf65a0000)
    libxcb.so.1 => /lib/libxcb.so.1 (0xf657c000)
    libGL.so.1 => /lib/libGL.so.1 (0xf64ca000)
    libexpat.so.1 => /lib/libexpat.so.1 (0xf64a1000)
    libpcre.so.1 => /lib/libpcre.so.1 (0xf6436000)
    liblzma.so.5 => /lib/liblzma.so.5 (0xf640d000)
    libgraphite2.so.3 => /lib/libgraphite2.so.3 (0xf63f0000)
    libX11-xcb.so.1 => /lib/libX11-xcb.so.1 (0xf63ed000)
    libxcb-dri2.so.0 => /lib/libxcb-dri2.so.0 (0xf63e7000)
    libxcb-xfixes.so.0 => /lib/libxcb-xfixes.so.0 (0xf63de000)
    libxcb-shape.so.0 => /lib/libxcb-shape.so.0 (0xf63d9000)
    libgbm.so.1 => /lib/libgbm.so.1 (0xf63cb000)
    libwayland-client.so.0 => /lib/libwayland-client.so.0 (0xf63bf000)
    libwayland-server.so.0 => /lib/libwayland-server.so.0 (0xf63b1000)
    libglapi.so.0 => /lib/libglapi.so.0 (0xf636b000)
    libdrm.so.2 => /lib/libdrm.so.2 (0xf635d000)
    libXau.so.6 => /lib/libXau.so.6 (0xf6359000)
    libxcb-glx.so.0 => /lib/libxcb-glx.so.0 (0xf633e000)
    libXxf86vm.so.1 => /lib/libXxf86vm.so.1 (0xf6338000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf631a000)

32 bit machine:

    linux-gate.so.1 =>  (0x0056e000)
    libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x05acd000)
    libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x0024a000)
    libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00487000)
    libgio-2.0.so.0 => /lib/libgio-2.0.so.0 (0x00adf000)
    libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00458000)
    libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x0023c000)
    libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00219000)
    libm.so.6 => /lib/libm.so.6 (0x008d1000)
    libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00371000)
    libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00195000)
    libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x004a8000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00101000)
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x001e2000)
    libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x00a87000)
    libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00ad9000)
    libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x00a80000)
    librt.so.1 => /lib/librt.so.1 (0x008c6000)
    libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x0091c000)
    libproj.so.0 => /usr/lib/libproj.so.0 (0x00304000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x008a2000)
    libc.so.6 => /lib/libc.so.6 (0x00716000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00c6d000)
    libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x0043a000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00dd0000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x0044d000)
    libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00df4000)
    libXi.so.6 => /usr/lib/libXi.so.6 (0x00de3000)
    libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x0042b000)
    libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00441000)
    libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00df9000)
    libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00435000)
    libdl.so.2 => /lib/libdl.so.2 (0x008bf000)
    libresolv.so.2 => /lib/libresolv.so.2 (0x00a64000)
    libz.so.1 => /lib/libz.so.1 (0x00a4d000)
    libselinux.so.1 => /lib/libselinux.so.1 (0x00a2c000)
    /lib/ld-linux.so.2 (0x006f5000)
    libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x004f1000)
    libexpat.so.1 => /lib/libexpat.so.1 (0x00da6000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00c4d000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x008fd000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00c48000)

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.

I would like to see that, then.

I am not sure how to show you all of them. For example if I look up the first one in the list on both machines:

libgtk-x11-2.0.so.0 contained in directory /lib/

64bit machine:
FileType: Link to Shared Library (application/x-sharedlib)
Link Target: libgtk-x11-2.0.so.0.2400.26
Location: /usr/lib

32bit machine:
Filetype: Link to Shared Library (application/x-sharedlib)
Link Target: libgtk-x11-2.0.so.0.22000.0
Location: /usr/lib