[gentoo-amd64] Emerge libraries in /usr/lib32 too

[gentoo-amd64] Emerge libraries in /usr/lib32 too

[Regis Decamps]

Hi,

I'd like to run a 32 bits closed-source application.

Usually, I can do this thanks to emul-x86-* packages.Unfortunately, this 
particular application requires a library which is not in app-emulation 
(I think).

What do you advise me to do?


For more details:
The application I'd like to run is Rigs of Rods 
(http://rigsofrods.blogspot.com).

When I try to run it,
./RoR.bin: error while loading shared libraries: libalut.so.0: cannot 
open shared object file: No such file or directory

Of course I have emerged freealut, but this gives me
/usr/lib64/libalut.so
when I think I actually need
/usr/lib32/libalut.so

I'm sure I can solve my problem with a 32-bit chrooted environment, but 
this seems like a hammer to crush a fly.

So I'd like to have a emul-linux-x86 that provides libalut.so. I already 
wrote a couple of ebuilds, but emul-linux-x86-* ebuilds seem different. 
Are they binary packages? How can I write a emul-linux-x86 package for 
freealut?

Or I'd like an ebuild for freealut in multilib mode (amd64 being merged 
into /usr/lib64 and i686 being merged into /usr/lib32)? I could probably 
write such an ebuild looking at glibc as a example. But would that be a 
best practice or not recommended?

Thanks for you opinion,
-- 
Régis

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Emerge libraries in /usr/lib32 too

[Ian McCulloch]

On Mon, 23 Apr 2007, Regis Decamps wrote:

> Hi,
> 
> I'd like to run a 32 bits closed-source application.
> 
> Usually, I can do this thanks to emul-x86-* packages.Unfortunately, this
> particular application requires a library which is not in app-emulation (I
> think).
> 
> What do you advise me to do?

[....]

If it is a one-off, and not many other people are likely to want to 
install it on a 64-bit gentoo, why not just compile and install a 32-bit 
freealut by hand?  as in 
CXXFLAGS=-m32 ./configure --prefix=/usr/local && make install etc.

Cheers,
Ian
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Emerge libraries in /usr/lib32 too

[Daniel Gryniewicz]

On Mon, 2007-04-23 at 16:12 +0200, Regis Decamps wrote:
> Hi,
> 
> I'd like to run a 32 bits closed-source application.
> 
> Usually, I can do this thanks to emul-x86-* packages.Unfortunately, this 
> particular application requires a library which is not in app-emulation 
> (I think).
> 
> What do you advise me to do?
> 
> 

You have a couple of options.  If you want to make the application
available to other computers (say you're installing on a set of
workstations, or something) then you probably want to make your own
emul-linux-x86 package for the missing libs.  There's a howto here:
http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml

If you're just installing on one computer, you have a number of options.
By far the easiest is to copy the missing libs off of some x86 gentoo
system.  If you don't have access to one of those, you can install a
32-bit chroot (no need to jump through hoops like above, just a plain
32-bit chroot is fine) and copy out of that.  If all else fails, you can
compile a 32-bit version on your 64-bit system, assuming all the
compile-time deps of the libs are available in 32-bit versions there.

Good luck.

Daniel

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Emerge libraries in /usr/lib32 too

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian McCulloch wrote:
> 
> If it is a one-off, and not many other people are likely to want to 
> install it on a 64-bit gentoo, why not just compile and install a 32-bit 
> freealut by hand?  as in 
> CXXFLAGS=-m32 ./configure --prefix=/usr/local && make install etc.
> 

I usually just build it in a 32-bit chroot, use quickpkg and then expand
that tarball in the 64-bit land.  It is a bit messy but it works.

You could also read the docs - I think there is one on creating emul-
packages if you really want to give this a try.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGLMoTG4/rWKZmVWkRAhQXAJ0YrClf5B0D+u6yEouJGc8C8Dy79wCfeKmn
ov3ng9xBrgFsPnCI4YDMm38=
=Dq7x
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

[gentoo-amd64] Re: Emerge libraries in /usr/lib32 too

[Regis Decamps]

Richard Freeman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ian McCulloch wrote:
>> If it is a one-off, and not many other people are likely to want to 
>> install it on a 64-bit gentoo, why not just compile and install a 32-bit 
>> freealut by hand?  as in 
>> CXXFLAGS=-m32 ./configure --prefix=/usr/local && make install etc.
>>
> 
> I usually just build it in a 32-bit chroot, use quickpkg and then expand
> that tarball in the 64-bit land.  It is a bit messy but it works.

What do you mean by "expand" the tarball? If I merge the tarball in the 
/ of my main amd64 system, then I'll lose my amd64 lib, won't I? On my 
system /use/lib points to /usr/lib64.

Should /usr/lib point to /usr/lib32 instead? I think it should in the 
future, but I was not aware the Gentoo layout was LSB (Linux standard 
base) compliant already. Is it?

> 
> You could also read the docs - I think there is one on creating emul-
> packages if you really want to give this a try.

I've been looking for that one before posting my original message. If 
you have a URL, I'll be glad to have it.

-- 
Régis

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Emerge libraries in /usr/lib32 too

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regis Decamps wrote:
> 
> What do you mean by "expand" the tarball? If I merge the tarball in the
> / of my main amd64 system, then I'll lose my amd64 lib, won't I? On my
> system /use/lib points to /usr/lib64.

Yup.  I was thinking about stuff that just doesn't work at all 64-bit.
This wouldn't work for multilib.  It really is a bit of a hack that
isn't the kind of fix I'd package up for anybody but myself...

> 
> Should /usr/lib point to /usr/lib32 instead? I think it should in the
> future, but I was not aware the Gentoo layout was LSB (Linux standard
> base) compliant already. Is it?
> 

You must be new here...  :)  It used to point to lib32 and a lot of
sweat and tears went into changing it to the way it is now...  I don't
profess to be an LSB expert...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGLOxjG4/rWKZmVWkRAn3QAJ4rx1Bqi2Qjh0ek475dwFw8Yx5g5gCdHt8O
wfZQdVbGLbS2BIpMScYyA/U=
=OTYE
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-amd64] Emerge libraries in /usr/lib32 too

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

On Monday 23 April 2007 17:00:35 Richard Freeman wrote:
> You could also read the docs - I think there is one on creating emul-
> packages if you really want to give this a try.

http://www.gentoo.org/proj/en/base/amd64/emul/index.xml

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Emerge libraries in /usr/lib32 too

[Duncan]

Richard Freeman <rich@thefreemanclan.net> posted
462CEC63.2030705@thefreemanclan.net, excerpted below, on  Mon, 23 Apr 2007
13:26:59 -0400:

> Regis Decamps wrote:
>> 
>> What do you mean by "expand" the tarball? If I merge the tarball in the
>> / of my main amd64 system, then I'll lose my amd64 lib, won't I? On my
>> system /use/lib points to /usr/lib64.
> 
> Yup.  I was thinking about stuff that just doesn't work at all 64-bit.
> This wouldn't work for multilib.  It really is a bit of a hack that
> isn't the kind of fix I'd package up for anybody but myself...

Both of you are aware that portage binpkgs are simply bz2'ed tarballs 
(thus the tbz2 extention) of the various files composing the installed 
package, with the ebuild and a bit of additional metadata tacked onto the 
end, right?

Thus, one can simply extract the package tarball as one would a normal 
tarball, using the appropriate tar switches (or the equivalent GUI 
functionality) to ensure that it doesn't extract directly over /, thus 
overwriting a 64-bit version.  tar will warn about extra data on the end 
-- the ebuild and metadata tacked on -- but it still extracts just fine.

In fact, that's basically what the emergency rescue procedure is for 
getting a working portage if it breaks.  You procure a binpkg (they used 
to have one for download, but quickpkg-ing up the latest Gentoo release 
version out of a stage tarball works as well, and I'm not sure if they 
maintain the emergency portage download itself any more, since it could 
just as easily be python or some other portage dependency that's broken), 
then extract it over the "dead" version on the normal filesystem.  
(Please backup config files it'll overwrite first, or simply don't 
replace them if you are extracting and placing files manually.)  After 
that, you should have a working portage, but its database will still 
think it has the version that broke merged, so you then merge a known 
working version again, thus getting the database in sync with what's 
actually merged once again.

Since I use FEATURES=buildpkg and have for some time, I have a basically 
complete history of packages, often several versions (using eclean, from 
gentoolkit, once in awhile to clean out the old ones), stored in my 
$PKGDIR.  Thus, if something breaks, I either use portage itself to roll 
back to an earlier version, or extract the tarball manually, if necessary.

Actually, it's also quite useful to have the packages around otherwise as 
well.  If I want to extract a single file from an older version, for 
whatever reason, it's easy to do, as it is to simply compare how configs 
or included files might have changed from version to version.  Both are 
occasionally quite useful indeed for bug tracing, in addition to the 
standard sysadmin role package rollback feature.  FEATURES=buildpkg is 
therefore one of my favorite "Gentoo poweradmin" tricks, almost a secret, 
as IMO the handbook (last I checked anyway) doesn't say /nearly/ enough 
about how truly useful this feature can be, and how one can really make 
use of it!

>> Should /usr/lib point to /usr/lib32 instead? I think it should in the
>> future, but I was not aware the Gentoo layout was LSB (Linux standard
>> base) compliant already. Is it?
>> 
>> 
> You must be new here...  :)  It used to point to lib32 and a lot of
> sweat and tears went into changing it to the way it is now...  I don't
> profess to be an LSB expert...

Actually... AFAIK the LSB says for AMD64, lib should be 32-bit (plus arch-
neutral stuff), while lib64 is 64-bit.  However, Gentoo/amd64 made its 
original choice before that standard existed, and was originally 
implemented more like ia64 (Itanium), where lib is 64-bit, and lib32 is 
32-bit.  The LSB reasoning being that on ia64, 64-bit is the only true 
native bitness, 32-bit being emulated, so lib gets the native.  On x86_64 
aka amd64, both bitnesses are truly hardware-native, so the new bitness, 
64-bit, gets the new location, lib64, while the old 32-bit gets to keep 
lib for legacy reasons.  The original Gentoo reasoning being that 64-bit 
will ultimately be the emphasized bitness, with legacy 32-bit being less 
of an issue as time goes on, so 64-bit should get the native bitness 
location in lib.  (Gentoo 32-bit was originally in emul/lib32, or some 
such, I've forgotten.)

However, when LSB went the other way, since there was no serious Gentoo 
reason to do otherwise, Gentoo/amd64 started trying to move toward the 
standard.  Basically, we've moved 64-bit to lib64, while keeping 32-bit 
in lib32.  On Gentoo/amd64, lib is now normally a symlink to lib64, but 
the only stuff that's supposed to be installed directly to lib is arch-
independent stuff.  FEATURES=multilib-strict causes portage to do some 
checks and die if the wrong thing gets installed to lib.  There are not 
regularly supported testing-only profiles that do away with the symlink, 
but that's exactly what they are, not normally/regularly supported, as 
it's not unusual at all for particularly new packages, but also 
occasionally updates from upstream where they played an unexpected trick, 
to put stuff in lib that doesn't belong there.

Some day, probably after portage (or pkgcore or paludis or another 
successor) gets full multi-arch support, and can thus properly track 32-
bit vs 64-bit in a single instance, Gentoo may in fact switch to a 32-bit 
lib in accordance with the LSB.  However, as time rolls on, that becomes 
less and less of an issue, as more and more stuff, even the proprietary 
aka slaveryware that caused the problem to be so big in the first place, 
either gets dumped for newer stuff, or gets native 64-bit versions.  
Thus, as time goes on, there's gradually less and less reason to even 
have 32-bit on the system at all, even for those who have no ethical/
legal/freedom/practical compunctions about running proprietaryware.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list