64 bit dev packages should include 32 bit .so library file

[Rocko]

64 bit dev packages contain a 64 bit version of the library file(s) that they provide for linking but not a 32 bit version of the library file(s). In previous versions of Ubuntu, however, it was possible to compile 32 bit applications using the 64 bit dev packages in by installing ia32-libs, which contained the required 32 bit library files.

In the move to multiarch, 32 bit library files are being removed from ia32-libs. Multiarch (I assume) aims to keep the architectures separate, so the generally intended solution is to install the i386 version of the dev package when compiling 32 bit applications, ie side-by-side with the 64 bit dev package.

However, some 64 bit development packages conflict with their 32 bit equivalent. This creates a regressive situation where it is impossible to install them side-by-side - you are forced to either install the 32 bit package, which breaks 64 bit compilations, or the 64 bit package, which breaks 32 bit compilations.

An example is libglu1-mesa-dev, which conflicts with libglu1-mesa-dev:i386. The libglu1-mesa-dev file contains all the necessary development files for 32 bit *except* for the 32 bit library file. It does contain the 64 bit library file. Since the library file is part of the development files, libglu1-mesa-dev does not contain all the necessary development files for 32 bit, ie it does not contain all the necessary development files for multiarch. I think that it *should* contain all the necessary files for building multarch applications.

The two workarounds are:

1. Manually re-install the required i386 dev packages before compiling 32 bit apps, and then manually re-install the required amd64 dev packages before compiling 64 bit apps. This is a real pain.

2. Install the i386 binary package (eg libglu1-mesa:i386) and the amd64 dev package (eg libglu1-mesa-dev), and manually create symlinks for the i386 libXYZ.so package (eg sudo ln -s /usr/lib/i386-linux-gnu/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so). This is a more permanent solution but is a real pain to set up, as you have to find each missing library manually, and some library files, like mesa/libGL.so.1, are in subfolders.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libglu1-mesa-dev 8.0.1-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.94.1-0ubuntu1
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,grid,resize,compiztoolbox,vpswitch,place,gnomecompat,move,regex,animation,imgpng,snap,mousepoll,session,expo,workarounds,wall,ezoom,fade,scale,unityshell]
CompositorRunning: compiz
Date: Thu Mar 8 10:20:54 2012
DistUpgraded: Log time: 2012-02-26 08:25:08.500725
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus:
 virtualbox-guest, 4.1.8, 3.2.0-12-generic, x86_64: installed
 virtualbox-guest, 4.1.8, 3.2.0-14-generic, x86_64: installed
 virtualbox-guest, 4.1.8, 3.2.0-17-generic, x86_64: installed
 virtualbox-guest, 4.1.8, 3.2.0-18-generic, x86_64: installed
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef] (prog-if 00 [VGA controller])
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120201.1)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet
MachineType: innotek GmbH VirtualBox
ProcEnviron:
 LANGUAGE=en_AU:en
 TERM=xterm
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-generic root=UUID=630a9f76-6f8f-43be-bb99-6be721c9deaf ro quiet splash vt.handoff=7
Renderer: Software
SourcePackage: mesa
UpgradeStatus: Upgraded to precise on 2012-02-26 (11 days ago)
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:
dmi.product.name: VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH
version.compiz: compiz 1:0.9.7.0~bzr2995-0ubuntu5
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.30-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.1-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.1-0ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu4
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.99.901+git20120126-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

[Timo Aaltonen (tjaalton)]

the conflicts just need to be fixed

[Rocko (rockorequin)]

So the "conflicts with" have just been incorrectly set - it's not just because the i386 and amd64 packages supply the same files and therefore overwrite each other (and purging one of them will affect the other)?

There are a number of packages that fall into this category: is it something that can be automatically detected and fixed, or do we have to log a separate bug for each package?

[Eric Appleman (erappleman)]

Wine can not be properly built on amd64 by end-users until this bug is fixed.

[Darko Veberic (darko-veberic-kit)]

we have similar situation here in CERN where some legacy software requires 32 bit compiling and it is impossible to keep dependencies needed by ROOT in 32 bit installed alongside the 64 bit libraries. just to name a few library and -dev packages that are broken in such a way: libcppunit, libxft, libxext, libxmu etc...

[Darko Veberic (darko-veberic-kit)]

the same also with libpng...

[Andre Haas (andre-ca3t8a)]

Want to install Wine on my 64bit Ubuntu and get the error:

The following packages have unmet dependencies:

wine1.4: PreDepends: dpkg (>= 1.15.7.2~) but 1.16.1.2ubuntu7 is to be installed
         Depends: libc6 (>= 2.14) but 2.15-0ubuntu10.2 is to be installed
         Depends: wine1.4-amd64 (= 1.4-0ubuntu4.1) but 1.4-0ubuntu4.1 is to be installed
         Depends: wine1.4-i386 (= 1.4-0ubuntu4.1) but it is a virtual package

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

Even in the press already:, as this regards trusty too:

http://www.webupd8.org/2014/04/install-google-earth-in-ubuntu-1404.html

Also we can find quite a few people who suffered this with the LTS-Enablement-Stacks-Support... and Installations of any offcial flavour > 12.04.1

[Ian Mallett (0-ian-a)]

The second workaround does not work with apt-get; e.g.:

The following packages have unmet dependencies:
 libglu1-mesa-dev : Conflicts: libglu1-mesa-dev:i386 but 9.0.0-2 is to be installed
 libglu1-mesa-dev:i386 : Conflicts: libglu1-mesa-dev but 9.0.0-2 is to be installed
E: Unable to correct problems, you have held broken packages.

[Timo Aaltonen (tjaalton)]

nope, libraries should just be migrated to support multiarch, like libglu 9.0.0-2.1