[cups.bugs] Broken --enable-32bit and --enable-64bit in cups 1.2.0

[Herton Krzesinski]

While trying to compile cups on a x86_64 system generating native and
32 bits libs, I got the following errors:

Compiling 32-bit interpret.c...
Compiling 32-bit raster.c...
Linking 32-bit libcupsimage.32.so.2...
/usr/bin/ld: skipping incompatible ../cups/libcups.so when searching for -lcups
/usr/bin/ld: skipping incompatible ../cups/libcups.a when searching for -lcups
/usr/bin/ld: cannot find -lcups
collect2: ld returned 1 exit status
make[1]: *** [libcupsimage.32.so.2] Error 1
make: *** [all] Error 1

with the following as configure options:
../configure --enable-static --enable-image --enable-pam --enable-slp
--enable-ssl --enable-threads --with-cups-group=lp --with-cups-user=lp
--with-docdir=/usr/share/cups/doc --with-perl=/usr/bin/perl
--with-php=/usr/bin/php --with-python=/usr/bin/python --enable-32bit
--with-optim="-O2 -g"

Analysing the problem, what occurs is that libcupsimage.so.2 in 32
bits can't be generated because it links against main libcups.so.2 but
the native one in 64 bits is already generated in the directory with
libcups.so symlink pointing to it. And there is other issue too,
libcups.32.so.2 is generated with a wrong soname (libcups.32.so.2, can
be checked with objdump -p libcups.32.so.2 | grep SONAME).

I think that these problems also would occur if I were compiling on an
arch with 32 bits native using configure --enable-64bit option; and
about libcupsimage.32.so.2, if I could generate it, it would have a
wrong soname too like the main libcups case.

I made a patch that is a try to correct the problems, I'll try to
attach with this message.

-- 
[]'s
Herton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cups-1.2.0-enable_32_64_bits.patch
Type: application/octet-stream
Size: 8798 bytes
Desc: not available
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20060519/56154b40/attachment.obj>