multilib confusion / getting 32bit software to run

colinh · 2018-06-27 14:56:30

There's a straightforward question at the end. The preamble is background:

I'm trying to install an old program (hullform). It complains

./hullform: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory

I guess that that means it wants Motif installed, so I installed it with pacman -S openmotif.

It makes no difference, so I guess, what with it being an old program, that it wants 32-bit libraries.

I uncommented multilib in /etc/pacman.conf and did a pacman -Syu.

pacman -Ss lib32-openmotif doesn't find anything.

yay -Ss lib32-openmotif *does* find it...

... unfortunately it times out trying to download its dependency lib32-libxp. (which is some sort of X11 printing library. And no Motif program can possibly run without printing stuff...).

ERROR: Failure while downloading http://mirror.yandex.ru/archlinux/extra … pkg.tar.xz

So, I did a google search on libxp-1.0.3-1-i686.pkg.tar.xz.

Turns out it's in https://mirror.archlinux32.org/i686/extra/

Well, that's better than a 404 from some Russian site, so I downloaded it and tried

pacman -U libxp-1.0.3-1-i686.pkg.tar.xz

which gives:

error: failed to prepare transaction (package architecture is not valid)
:: package libxp-1.0.3-2.0-i686 does not have a valid architecture

So, I thought i'd compare that package with a lib32- package that did install ok, e.g. lib32-libXmu

The .PKGINFO that won't install is:

# Generated by makepkg 5.1.0
# using fakeroot version 1.22
pkgname = libxp
pkgbase = libxp
pkgver = 1.0.3-2.0
pkgdesc = X11 X Print Library
url = https://xorg.freedesktop.org/
builddate = 1527752220
packager = Erich Eckner <arch32 at eckner dot net>
size = 142336
arch = i686
license = custom
depend = libxext
depend = printproto
makedepend = xorg-util-macros

The one that is installed is:

# Generated by makepkg 5.1.0
# using fakeroot version 1.22
pkgname = lib32-libxmu
pkgbase = lib32-libxmu
pkgver = 1.1.2-2
pkgdesc = X11 miscellaneous micro-utility library (32-bit)
url = http://xorg.freedesktop.org/
builddate = 1527730694
packager = Felix Yan <felixonmars@archlinux.org>
size = 123904
arch = x86_64
license = custom
depend = lib32-libxext
depend = lib32-libxt
depend = libxmu
makedepend = xorg-util-macros
makedepend = gcc-multilib

I note that the .PKGINFO for libxp doesn't have a package name like lib32-libxp. Also, its arch is i686. And it depends on libxext and printproto. lib32-libxext is installed. As is, apparently, printproto.

x@xps:~/Downloads$ sudo pacman -Ss printproto
extra/xorgproto 2018.4-1 [installed]
    combined X.Org X11 Protocol headers

So, bearing in mind that what I actually wanted to do was design a boat hull, is it a trivial thing to modify the .PKGINFO ? The package comes with the actual libraries. Will I need to recompile them from source? I'm sort of interested in learning how to get this to work, because there are various pieces of 32bit software which used to work -- and now don't. So, if it's a relatively simple matter to get them going again, that would be cool.

I'm new to Arch Linux and am trying it out because the documentation is generally regarded as the best, and Arch users seem more likely to know what they're talking about. Unfortunately, I'm getting old and loosing interest in Linux as a hobby/interest for its own sake. I don't want to peruse the source code of pacman and makepkg. To be honest, I don't really want even to have to read and understand the whole of pacman's man page...

loqs · 2018-06-27 15:08:15

Multilib

Trilby · 2018-06-27 17:12:48

colinh wrote:

./hullform: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
... so I guess, what with it being an old program, that it wants 32-bit libraries.

No, the error is because it is looking for an older version of the library. It may also need the multilib version of the old library, but there is no indication of that here. But even enabling multilib will not get you old libraries, just 32 bit builds of current libs.

You need to rebuild hullform to link against the current version of motif.

progandy · 2018-06-27 17:41:26

The lib32-libxp PKGBUILD requires the i686 package as its source. Since you have gotten it from archlinux32, you now have to edit the PKGBUILD and set it as the source and build with makepkg.

@Trilby: If this is a binary without source recompiling is not possible. With this particular library a symlink from the old name to the new library is allowed:

https://sourceforge.net/p/motif/code/ci … e/RELNOTES writes:
Motif 2.3.X is an updated version of Motif 2.3.
Any applications built against a previous 2.x release of Motif will be
binary compatible with this release.

Last edited by progandy (2018-06-27 17:41:59)

Trilby · 2018-06-27 17:53:33

I stand corrected on that point - but still, is there evidence here that this requires a lib32 version, or should the 'normal' libXm.so.4 be symlinked?

progandy · 2018-06-27 19:07:04

There is no evidence.

@colinh: Where did you get the application and what is the output of

$ file hullform
$ ldd hullform

loqs · 2018-06-27 19:34:19

https://download.cnet.com/Hullform-for- … 11572.html

$ file hullform
hullform: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, with debug_info, not stripped

eschwartz · 2018-06-27 19:47:15

This AUR package for lib32-libxp is a complete piece of utter trash. Instead of compiling from source, which would work, it downloads a prebuilt package from the i686 repository, then untar's it and repackages it as x86_64.

Obviously that will break whenever the repository version is updated... or deleted, because i686 was removed entirely.

...

progandy wrote:

The lib32-libxp PKGBUILD requires the i686 package as its source. Since you have gotten it from archlinux32, you now have to edit the PKGBUILD and set it as the source and build with makepkg.
@Trilby: If this is a binary without source recompiling is not possible. With this particular library a symlink from the old name to the new library is allowed:
https://sourceforge.net/p/motif/code/ci … e/RELNOTES writes:
Motif 2.3.X is an updated version of Motif 2.3.
Any applications built against a previous 2.x release of Motif will be
binary compatible with this release.

openmotif 2.3.4-2 from April 2013 is the earliest version still in Arch Linux's archive (currently hosted by archive.org this package is so old), and it has the soname libXm.so.4

I sincerely doubt that what they mean is symlinking the library is allowed. What they're saying, is that they did not increment the soname for 2.3.x, therefore *all* 2.3.x releases are, in fact, already libXm.so.4

Where did you derive this odd logic from?

progandy · 2018-06-27 20:08:37

Where did you derive this odd logic from?

I copied the wrong section from the release notes:

https://sourceforge.net/p/motif/code/ci/master/tree/RELNOTES wrote:

6. Compatibility Notice
Motif 2.3.x is binary compatible with Motif 2.2.x.
Applications built against Motif 2.2 should work with Motif 2.3.x
without having to recompile it.
Motif 2.3.x is not binary compatible with Motif 2.1.30.
Applications built against Motif 2.1.30 will need to be recompiled
with the Motif 2.2+ header files.

Debian has the symlink as well.
https://packages.debian.org/en/sid/libxm4
https://packages.debian.org/en/sid/libmotif3

---

Hmm, the source for hullform is available, but only for windows. To recompile, someone would have to recreate the missing pieces.
https://web.archive.org/web/20120703104 … lform.com/

This is the hullform binary I used:
https://web.archive.org/web/20120320105 … f9p.tar.gz

I got it to start with lib32-libxt, lib32-libxmu and then the lib directories from these packages in LD_LIBRARY_PATH to skip making PKGBUILDs for a quick test.
https://mirror.archlinux32.org/i686/ext … pkg.tar.xz
https://mirror.archlinux32.org/i686/com … pkg.tar.xz (added symlink libxm.so.3)
https://mirror.archlinux32.org/i686/ext … pkg.tar.xz
https://sourceforge.net/projects/mesa3d … z/download

I had to do one hack since I don't have the required font (helvetica), and changed it do droid sans ([communty]/ttf-droid)

sed -i 's/adobe-helvetica-medium/misc-droid sans-medium/g' hullform

Last edited by progandy (2018-06-27 20:34:01)

colinh · 2018-06-27 21:40:23

Gosh! Thanks everyone!

I think I downloaded it (hf9s.tar.gz) from cnet.com.

I untar'd all the libraries progandy mentioned in one directory and did sudo cp -R * /usr/local.
Then export LD_LIBRARY_PATH=/usr/local/lib

Then it just complained about libglut so I installed lib32-freeglut.

$ file hullform
hullform: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, with debug_info, not stripped

$ ldd hullform
	linux-gate.so.1 (0xf7f6c000)
	libXm.so.3 => /usr/local/lib/libXm.so.3 (0xf7c8b000)
	libXmu.so.6 => /usr/lib32/libXmu.so.6 (0xf7c43000)
	libXpm.so.4 => /usr/local/lib/libXpm.so.4 (0xf7c2e000)
	libXp.so.6 => /usr/local/lib/libXp.so.6 (0xf7c23000)
	libXt.so.6 => /usr/lib32/libXt.so.6 (0xf7bbb000)
	libm.so.6 => /usr/lib32/libm.so.6 (0xf7aee000)
	libGL.so.1 => /usr/lib32/libGL.so.1 (0xf7a8e000)
	libGLU.so.1 => /usr/lib32/libGLU.so.1 (0xf7a02000)
	libglut.so.3 => /usr/lib32/libglut.so.3 (0xf7952000)
	libXi.so.6 => /usr/lib32/libXi.so.6 (0xf793f000)
	libc.so.6 => /usr/lib32/libc.so.6 (0xf7764000)
	libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7615000)
	libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7600000)
	libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0xf75b6000)
	libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf74e6000)
	libXft.so.2 => /usr/lib32/libXft.so.2 (0xf74ce000)
	libjpeg.so.8 => /usr/lib32/libjpeg.so.8 (0xf7481000)
	libpng16.so.16 => /usr/lib32/libpng16.so.16 (0xf7443000)
	libXau.so.6 => /usr/lib32/libXau.so.6 (0xf743e000)
	libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7434000)
	libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7418000)
	/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f6e000)
	libGLX.so.0 => /usr/lib32/libGLX.so.0 (0xf73f5000)
	libGLdispatch.so.0 => /usr/lib32/libGLdispatch.so.0 (0xf7394000)
	libdl.so.2 => /usr/lib32/libdl.so.2 (0xf738f000)
	libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf7370000)
	libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf71f3000)
	libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf71d7000)
	libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0xf71ca000)
	libXxf86vm.so.1 => /usr/lib32/libXxf86vm.so.1 (0xf71c3000)
	libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7199000)
	libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf7167000)
	libuuid.so.1 => /usr/lib32/libuuid.so.1 (0xf715e000)
	libbz2.so.1.0 => /usr/lib32/libbz2.so.1.0 (0xf714c000)
	libz.so.1 => /usr/lib32/libz.so.1 (0xf7131000)
	libharfbuzz.so.0 => /usr/lib32/libharfbuzz.so.0 (0xf707a000)
	libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf706e000)
	libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7067000)
	libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0xf6f38000)
	libpcre.so.1 => /usr/lib32/libpcre.so.1 (0xf6ec0000)

So, it seems happy enough with the libraries.

fc-list says i have nearly 100 Helvetica fonts -- albeit 75dpi and 100dpi ones. So I thought I'd try it and see what happens.

What happens is:
Bad drawable error(s).
Cannot open font heb8x13

Heb8x13 ??! No, I don't have that installed. But I don't have misc-droid sans-medium either.

I tried
sed -i 's/adobe-helvetica-medium/LiberationSans-Regular/g' hullform
but then it said
Can't locate font

I tried
sed -i 's/LiberationSans-Regular/FreeSans/g' hullform
but that gave:
Segmentation fault (core dumped)

Sooo, it looks like the library issue is OK, but I need to read up on my font configuration... :-/

progandy · 2018-06-27 22:01:27

The replacement string has to be the exact same length and the end result inside the binary has to be a valid x11 font descriptor. I said it was a hack.
You probably don't need that hack since you get the heb9x13 error instead. The helvetica from the aur didn't work for me for whatever reason.

If you get "Cannot open font heb8x13", then try to install xorg-fonts-alias and xorg-fonts-misc.

Edit: Also, if you use /usr/local/lib, then you don't need LD_LIBRARY_PATH. Better would be to create PKGBUILDs and compile lib32 packages, though

Last edited by progandy (2018-06-27 22:18:50)

Trilby · 2018-06-27 23:18:45

progandy wrote:

The replacement string has to be the exact same length ...

I'd bet you could get away with a shorter string too as long as you pad it with null bytes (or technically, with 1 null byte followed by whatever you want).

colinh · 2018-06-28 00:17:37

progandy wrote:

The replacement string has to be the exact same length and the end result inside the binary has to be a valid x11 font descriptor. I said it was a hack.

Argh! Of course. Gods -- I'm out of practice. Too many years on a Mac. You know -- click, works.

Trilby wrote:

I'd bet you could get away with a shorter string too as long as you pad it with null bytes (or technically, with 1 null byte followed by whatever you want).

Yes, I expect that would work...

Arch Linux

#1 2018-06-27 14:56:30

multilib confusion / getting 32bit software to run

#2 2018-06-27 15:08:15

Re: multilib confusion / getting 32bit software to run

#3 2018-06-27 17:12:48

Re: multilib confusion / getting 32bit software to run

#4 2018-06-27 17:41:26

Re: multilib confusion / getting 32bit software to run

#5 2018-06-27 17:53:33

Re: multilib confusion / getting 32bit software to run

#6 2018-06-27 19:07:04

Re: multilib confusion / getting 32bit software to run

#7 2018-06-27 19:34:19

Re: multilib confusion / getting 32bit software to run

#8 2018-06-27 19:47:15

Re: multilib confusion / getting 32bit software to run

#9 2018-06-27 20:08:37

Re: multilib confusion / getting 32bit software to run

#10 2018-06-27 21:40:23

Re: multilib confusion / getting 32bit software to run

#11 2018-06-27 22:01:27

Re: multilib confusion / getting 32bit software to run

#12 2018-06-27 23:18:45

Re: multilib confusion / getting 32bit software to run

#13 2018-06-28 00:17:37

Re: multilib confusion / getting 32bit software to run

Board footer