LinuxQuestions.org - [SOLVED] Install the 32 bit version and the 64 bit version, on multilib system.

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Install the 32 bit version and the 64 bit version, on multilib system. (https://www.linuxquestions.org/questions/slackware-14/install-the-32-bit-version-and-the-64-bit-version-on-multilib-system-4175486287/)

Knightron

11-29-2013 04:58 PM

Install the 32 bit version and the 64 bit version, on multilib system.

Hi, i'm running Slackware 14, multilib. I have installed TiMidity++ from Slackbuilds.org, compiled as 32 bit. I would also like to install it as a 64 bit application as well, is this possible? I was thinking the naming would be an issue. Pkgtool reports it as this: TiMidity++-2.14.0-x86_64-1

TommyC7

11-29-2013 07:18 PM

Quote:

Knightron:
I have installed TiMidity++ from Slackbuilds.org, compiled as 32 bit.

Do you know this for a fact? Because if pkgtool reports: TiMidity++-2.14.0-x86_64-1 it sounds like you built a 64-bit version of the package.

My guess is, you didn't build a 32-bit package on your multilib installation. To do so:

Code:

. /etc/profile.d/32dev.sh # (or 32dev.csh if you use that).

./TiMidity++.SlackBuild

This will create a 32-bit package of TiMidity++ which you can then use convertpkg-compat32 on like this:

Code:

convertpkg-compat32 /path/to/TiMidity++-2.14.0-i?86-1.tgz

Which will give you the same 32-bit package with a few changes (e.g. /usr/bin/32) and a different name. Then you can build a 64-bit package normally (although not in the same environment since the /etc/profile.d/32dev.sh script was sourced).

Now you'll have 2 separate packages and can install them normally.

Knightron

11-29-2013 08:07 PM

Hi TommyC7. Thanks for the advice. Eric has stated the following when compiling packages as 32 bit.

Quote:

Compiling 32-bit programs
=========================

In case you need to compile a 32-bit program (wine and grub are two examples
of open source programs that are 32-bit only) you first configure your
shell environment by running the command:

. /etc/profile.d/32dev.sh

Note the 'dot' in front of the filename - that is actually part of the
commandline! It will change or create several environment variables so
that 32-bit versions of binaries are preferred.

You will be able to use standard SlackBuild scripts to build 32-bit packages
for Slackware64. You have to keep two things in mind:
(1) You will have to define the ARCH variable as 'x86_64' even though you
are compiling a 32-bit program!
(2) You will have to edit the SlackBuild and if it wants to use 'lib64/'
directories for "$ARCH = x86_64", you will have to force it to use 'lib/'
directories instead. Usually, this is accomplished by finding a definition
like:
LIBDIRSUFFIX="64"
and change this line to
LIBDIRSUFFIX=""

I have done all this, pkgtool reports it as a x86_64 because of point 1 in Eric's guide.

TommyC7

11-30-2013 12:16 AM

In that case, I would recommend appending the ARCH variable manually like so:

Code:

. /etc/profile.d/32dev.sh # source 32dev.sh

ARCH=i486 ./TiMidity++.SlackBuild # setting the ARCH will take care of that LIBDIRSUFFIX thing too

convertpkg-compat32 -i /tmp/TiMidity++-2.14.0-i?86-1.tgz

phenixia2003

11-30-2013 05:07 AM

Hello,

Quote:

Originally Posted by TommyC7 (Post 5072770)

In that case, I would recommend appending the ARCH variable manually like so:

Code:

. /etc/profile.d/32dev.sh # source 32dev.sh

ARCH=i486 ./TiMidity++.SlackBuild # setting the ARCH will take care of that LIBDIRSUFFIX thing too

convertpkg-compat32 -i /tmp/TiMidity++-2.14.0-i?86-1.tgz

As stated by Eric here, this will result in gcc error :

Quote:

You will have to define the ARCH variable as 'x86_64' even though you are compiling a 32-bit program!
This is related to the triplet of “$ARCH-slackware-linux” which is normally used in the “configure” command. Also, try setting the ARCH to for instance “i486” and you will see that the CFLAGS definition for that architecture will result in gcc errors like ”compiler can not create executables”.

AFAIK, you can pass any 32-bit package built on Slackware64 to convertpkg-compat32 without any issue.

Note that, regardless of the input package ARCH field value, convertpkg-compat32, will warn you if it seems to contain 64-bit libraries :

Code:

# Check if the user fed us a 64bit package:

if [ -d usr/lib64 -o -d lib64 ]; then

  echo "** This script converts 32bit packages for Slackware64 multilib!"

  echo "** It looks like you gave me a 64bit package instead."

  echo "** Are you certain you want to convert the package $(basename $PKGPATH) ?"

  echo "** Press [Ctrl]-[C] now if you want to abort the script."

  read JUNK

fi

Cheers.

--
SeB

Knightron

11-30-2013 07:31 AM

It's not making the package that i'm concerned about.
I desire to install both the 32bit and 64bit version of the same package. I am concerned there might be files that'll get over written, or maybe won't even be able to install since they will be named the same.

phenixia2003

11-30-2013 08:05 AM

Hello,

Quote:

Originally Posted by Knightron (Post 5072941)

You should not experience that kind of issue with 32 bit packages converted using convertpkg-compat32 which preserves only 32 bit binaries, 32 bit libraries and some documentation files from input package. Moreover, 32bit binaries are moved into /usr/bin/32.

--
SeB

TommyC7

11-30-2013 08:17 AM

Quote:

phenixia2003:
As stated by Eric here, this will result in gcc error :

Quote:

You will have to define the ARCH variable as 'x86_64' even though you are compiling a 32-bit program!
This is related to the triplet of “$ARCH-slackware-linux” which is normally used in the “configure” command. Also, try setting the ARCH to for instance “i486” and you will see that the CFLAGS definition for that architecture will result in gcc errors like ”compiler can not create executables”.

I only get that error when I don't source /etc/profile.d/32dev.sh first:

Code:

ARCH=i486 ./gpicview.SlackBuild

checking for a BSD-compatible install... /usr/bin/ginstall -c

checking whether build environment is sane... yes

checking for a thread-safe mkdir -p... /usr/bin/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make supports nested variables... yes

checking whether to enable maintainer-specific portions of Makefiles... no

checking build system type... i486-slackware-linux-gnu

checking host system type... i486-slackware-linux-gnu

checking how to print strings... printf

checking for style of include used by make... GNU

checking for gcc... gcc

checking whether the C compiler works... no

configure: error: in `/tmp/gpicview-0.2.4':

configure: error: C compiler cannot create executables

See `config.log' for more details

But if I do source /etc/profile.d/32dev.sh and append the ARCH=i486 variable, the package is successfully built.

Quote:

Knightron:
I desire to install both the 32bit and 64bit version of the same package. I am concerned there might be files that'll get over written, or maybe won't even be able to install since they will be named the same.

That's where the convertpkg-compat32 script comes in. It'll install the 32-bit version of the stuff in /usr/bin into /usr/bin/32, /lib64 stuff will go into /lib, etc. You use the convertpkg-compat32 script on a 32-bit package (which is what I believe led us into the discussion of building 32-bit packages on Slackware64).

jtsn	12-01-2013 05:37 AM

Using setarch(1) in addition to setting $ARCH could be useful, too.

TobiSGD

12-01-2013 08:45 AM

As the name "multilib" already says, it is intended to provide 32 bit libraries for applications that don't exist as 64 bit binaries. It is not intended to have the 32 and 64 bit version of an application installed simultaneously. This wouldn't make sense anyway, why would you install the 32 bit version if you have already the 64 bit version? If you really want to have both versions available I would opt for a chroot with a 32 bit Slackware system.

Alien Bob

12-01-2013 03:08 PM

I think I need to re-visit the instructions for compiling 32-bit software on a multilib 64-bit Slackware computer. Setting ARCH to i486 appears to work correctly these days - when I wrote these instructions around the time of Slackware 13.0, I just got compliler errors.

What I think will change in those instructions, is this: you simply set ARCH=i486 and then you'll end up with a package name like foobar-1.1-i486-1.txz. The ARCH variable nicely distinguishes it from the 64-bit version of such a package. And then, when you convert it to a "compat32" package I would like the resulting package "foobar-compat32" to have an arch "x86_64" because setting it to "i486" would perhaps cause too much confusion after all these years of multilib.

Knightron, rename your 32-bit package from TiMidity++-2.14.0-x86_64-1 to TiMidity++-2.14.0-i486-1 and then run convertpkg-compat32 on it. That should solve your issue.

phenixia2003 - changing the package arch for 32-bit packages on multilib to "i486" may have impact on your scripts. Please check if you have to change anything, I won't do anything until you know how to handle this. Like I said, I would like to keep the ARCH for compat32 packages to "x86_64". So perhaps you do not have to change a bit.

Eric

phenixia2003

12-02-2013 04:38 AM

Hello,

Quote:

Originally Posted by Alien Bob (Post 5073516)

phenixia2003 - changing the package arch for 32-bit packages on multilib to "i486" may have impact on your scripts. Please check if you have to change anything, I won't do anything until you know how to handle this. Like I said, I would like to keep the ARCH for compat32 packages to "x86_64". So perhaps you do not have to change a bit.

If you don't change how convertpkg-compat32 works (i.e output package with ARCH=x86_64), I will have nothing to do. Otherwise, compat32pkg will be slightly impacted(only one line of code to change), and slackpkg+ (development version) already allows to mix 32-bit and 64-bit packages on Slackware64 (disabled by default). This has been introduced following this thread.

Cheers.

--
SeB

Knightron

12-02-2013 09:23 PM

Quote:

Originally Posted by Alien Bob (Post 5073516)

Knightron, rename your 32-bit package from TiMidity++-2.14.0-x86_64-1 to TiMidity++-2.14.0-i486-1 and then run convertpkg-compat32 on it. That should solve your issue.

Cheers :)

All times are GMT -5. The time now is 09:37 PM.