[cups.bugs] Re: [MOD] STR #1487: rpmbuild fails on x86_64

Michael Sweet mike at easysw.com
Wed Mar 15 10:57:45 PST 2006


Klaus Singvogel wrote:
> ...
> But isn't it our final goal to get rid of the 32-bit stuff for the
> 64-bit architecture?

Given that all of the LSB-compliant distributions, including SuSE,
have adopted a 32-bit compatible directory structure with 32-bit
libraries in /usr/lib and 64-bit libraries in /usr/lib64, I do not
think that is "our" goal at all.

If it was, you would have followed Debian down the slippery
slope by putting 64-bit libraries in /usr/lib and 32-bit
libraries in /usr/lib32.

I *don't* like Debian's approach because it makes it impossible
to install and use 32-bit binaries on a 64-bit system.  They
pretty much have guaranteed that they will have limited commercial
support (if they had any at all).  However, it certainly does
force adoption of x86_64 if you are going to run 64-bit at all.

Perhaps vendors will be able to adopt the Solaris model for
32/64-bit support: /usr/lib/32 and /usr/lib/64 are the locations
of their 32/64-bit libraries, with /usr/lib/32 being a symlink
to /usr/lib on 32-bit installs and /usr/lib/64 being a symlink
to /usr/lib on 64-bit installs.  Vendors can supply libraries
with the /usr/lib/32/libfoo and /usr/lib/64/libfoo and they
will get installed in the right places.

(this lends itself to a possible solution to the Debian/LSB
conflict: /usr/lib32 and /usr/lib64 must be present on all
systems, one of them will be a symlink to /usr/lib)

Anyways....

Even though the 64-bit extensions provide additional registers
and instructions that allow for more efficient code, the memory
overhead of the increased pointer and data type sizes (about 50%
overall for the CUPS code) limits the performance gain you'll
actually see.  The numbers I've seen suggest only an 8%
improvement in speed overall, which IMHO is not sufficient by
itself to justify abandoning 32-bit builds and support on x86.
Mind you, if most programs are compiled 64-bit, the 50% memory
overhead will generally be eaten by the 32-bit libraries you
load just to run CUPS, so in that case it makes sense to compile
all of CUPS 64-bit on x86_64 and only provide 32-bit libraries.

So, on Linux x86_64 we compile 64-bit by default with optional
32-bit libraries.  On IRIX and Solaris we compile 32-bit by
default with optional 64-bit libraries, and I'd guess we would
do the same for Linux on those same systems.

On MacOS X, we compile everything for *all* architectures since
MacOS X uses Mach-O which allows us to put 32-bit and 64-bit
PPC and Intel code in the same file (the installer can strip
out unused bits if you like)

 > So we might want to install 32-bit libraries
> only, if 32-bit binaries are present in your 64-bit system, and this
> means for cups: the 32-bit libraries only if you have appropriate
> library calls from any 32-bit executable. Otherwise you don't need to
> bloat your 64bit system with 32-bit stuff, nor need to have a 32-bit
> compile environment parallel installed.

IMHO, if you install the developer tools on the system, then you
should be able to use -m32 or -m64 to generate 32-bit or 64-bit
x86 code on Intel.  Don't make it a special case.

> So, I think it's the right step not to include the 32-bit libraries
> in a 64-bit package.

It makes package management almost impossible.  In particular, the
way SuSE packages the 32bit CUPS libraries, you can't install an
alternate version of those packages without wiping that package,
which then triggers other dependencies.  It ain't pretty.

> BTW: SUSE is building the 32-bit CUPS libraries not in a multi-arch
> system, instead 32-bit packages are build in a pure 32-bit system.
> It's only a kind of "bonus" to have the 32-bit libraries included on a
> 64bit installation media. :-) We don't separate them via a "hack". We
> produce them on a 32-bit system and include them for the 64-bit
> installation, just for the any case. :-)

I've had the displeasure of providing support for your customers
who have no end of trouble with your CUPS packages...

> ...
> We never had any problems for supporting the architectures in the past
> and in the way we do. Maybe this might influence the way how you do
> the multi-architecture support so far? :-)

Given that I am *not* disconnected from customer support like you
are, I see a lot more problems than you do, apparently.

> Another comment: I doubt that you can compile and link a 32-bit CUPS
> libraries by using the 64-bit libraries only and without having access
> to the appropriate 32-bit libraries in your build environment. So, if

I *do* have the 32-bit libraries in my build environment, otherwise
I wouldn't be able to generate the CUPS libraries in the first place
(they have to link against *something*...)

> you have both installed, why do you insist to include the files for
> one architecture in the packages for a different one? Isn't it the
> better philosophy to build and keep them separate and let the
> decision be made finally by the user (and by the necessities of the
> installed packages)?

No, I would need twice as many build systems to accomplish the
same thing that I do now.  I would need to make sure they had
compatible versions of every library, use the same version of
GCC, etc.  Then I would need to merge *some* of the packages
from the 32-bit build systems into the final distribution
image for the 64-bit systems.

Now, if I want to provide the 32-bit libraries in a separate
package, all I need to do it make a separate "cups-libs32"
subpackage, however that would break 32-bit packages that have
a dependency on cups-libs, and if I used the same name as the
64-bit package, that would only be confusing to the user.

So, we build everything for a particular platform (and x86_64
is both 32-bit and 64-bit) and put everything in one package.
Dependencies are satisfied, users are not confused, and everything
just works.

> Solaris and IRIX don't use RPM, don't they? It was one of my
> preconditions to talk about rpm specific stuff only. I know that other
> UN*X systems also support multi-architectures, but the discussed
> macros and having a specfile is RPM specific. So, I don't see any need
> to look on different OS's, when RPM specific stuff is discussed. :-)

RPM is available on Solaris and IRIX, but not the default.  In any
case, it *is* relevant to the discussion of multiple-architecture
platforms because they've been doing since long before SuSE was
around!

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com





More information about the cups mailing list