Bug#540642: [libwine-unstable] wine.bin cannot find libwine.so.1
Daniel Schaal
Version: 1.1.26-1
Severity: normal
I get the following error message when trying to run wine:
/usr/lib/i486-linux-gnu/wine/wine.bin: error while loading shared libraries:
libwine.so.1: cannot open shared object file: No such file or directory
--- System information. ---
Architecture: amd64
Kernel: Linux 2.6.28.9
Debian Release: squeeze/sid
500 unstable ftp.de.debian.org
500 unstable ftp-stud.hs-esslingen.de
101 experimental ftp.de.debian.org
--- Package information. ---
Depends (Version) | Installed
============================-+-==============
ia32-libs (>= 20080808) | 20090808
lib32z1 (>= 1:1.1.4) | 1:1.2.3.3.dfsg-15
libc6-i386 (>= 2.9) | 2.9-23
Package's Recommends field is empty.
Suggests (Version) | Installed
=======================-+-===========
wine-doc |
Ove Kaaven
reassign -1 ia32-libs
stop
Daniel Schaal skrev:
> Package: libwine-unstable
> Version: 1.1.26-1
> Severity: normal
>
> I get the following error message when trying to run wine:
>
> /usr/lib/i486-linux-gnu/wine/wine.bin: error while loading shared libraries:
> libwine.so.1: cannot open shared object file: No such file or directory
You could add a new file to /etc/ld.so.conf.d/ containing the string
"/usr/lib/i486-linux-gnu". Perhaps some package like libc6-i386 or
ia32-libs should provide such a file, not sure which. I'll tentatively
assign this to ia32-libs.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ove Kaaven
severity 540646 important
retitle 540646 Need 32-bit multiarch path added to ld.so.conf.d
reassign 540646 libc6-i386 2.9-23
affects 540646 wine-unstable
stop
After some discussion, it seems that libc6-i386 is the correct package
for this bug. Reassigning.
Ove Kaaven
libc maintainers, please add a file to /etc/ld.so.conf.d/ in the
libc6-i386 package containing the appropriate 32-bit multiarch path,
"/usr/lib/i486-linux-gnu" or so, so that my shiny new multiarch-enabled
Wine packages will actually run for amd64 users.
Thanks.
Aurelien Jarno
> After some discussion, it seems that libc6-i386 is the correct package
> for this bug. Reassigned.
>
> libc maintainers, please add a file to /etc/ld.so.conf.d/ in the
> libc6-i386 package containing the appropriate 32-bit multiarch path,
> "/usr/lib/i486-linux-gnu" or so, so that my shiny new multiarch-enabled
> Wine packages will actually run for amd64 users.
>
biarch packages should not use the multiarch path, otherwise the
transition to multiarch would be a nightmare.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aure...@aurel32.net http://www.aurel32.net
Ove Kaaven
> biarch packages should not use the multiarch path, otherwise the
> transition to multiarch would be a nightmare.
So how do you propose I multiarchify Wine (and make it ia32-apt-get-able
while I'm at it) without using multiarch paths?
Aurelien Jarno
> Aurelien Jarno skrev:
> > biarch packages should not use the multiarch path, otherwise the
> > transition to multiarch would be a nightmare.
>
> So how do you propose I multiarchify Wine (and make it ia32-apt-get-able
> while I'm at it) without using multiarch paths?
>
You can use the multiarch paths, but only with the path corresponding to
the architecture of the .deb that is:
- /usr/lib/i486-linux-gnu on i386
- /usr/lib/x86_64-linux-gnu on amd64
- etc.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aure...@aurel32.net http://www.aurel32.net
--
Ove Kaaven
> On Sun, Aug 09, 2009 at 10:21:05PM +0200, Ove Kaaven wrote:
>> Aurelien Jarno skrev:
>>> biarch packages should not use the multiarch path, otherwise the
>>> transition to multiarch would be a nightmare.
>> So how do you propose I multiarchify Wine (and make it ia32-apt-get-able
>> while I'm at it) without using multiarch paths?
>
> You can use the multiarch paths, but only with the path corresponding to
> the architecture of the .deb that is:
> - /usr/lib/i486-linux-gnu on i386
> - /usr/lib/x86_64-linux-gnu on amd64
> - etc.
That won't help. Even if it had made any sense to put 32-bit libraries
into /usr/lib/x86_64-linux-gnu, I've done these changes for a reason.
For Win64 support, I need a path to place the 32-bit Wine libraries as
well as a path to place the 64-bit Wine libraries, simultaneously and
nonconflicting. Preferably paths that ld.so will also actually search.
It turns out that using different library paths in the i386 and amd64
build (/usr/lib on i386 vs /usr/lib32 on amd64) is going to break under
the likes of ia32-apt-get (and, of course, under real multiarch) since
the correct path must be compiled into libwine, and the only path I know
that is supposed to work the same on i386 and amd64 for holding 32-bit
libraries is /usr/lib/i486-linux-gnu.
Hence I've multiarchified Wine, and as a temporary measure until real
multiarch is here, I still build amd64 packages with i386 content
inside. Once multiarch is here, and the user can install the i386
packages directly, *then* I'll switch the build system to only build the
64-bit content into the amd64 packages, and make it the user's
responsibility to coinstall the 32-bit and 64-bit packages. (And try to
avoid holding up any transitions.) Until that's possible, I need a way
to ship 32-bit and 64-bit libraries from the same packages, making the
package conform to the upcoming multiarch stuff seemed like a reasonable
solution, and de-multiarching the package (and be back at square one)
again doesn't really seem appealing...
Aurelien Jarno
> Aurelien Jarno skrev:
> > On Sun, Aug 09, 2009 at 10:21:05PM +0200, Ove Kaaven wrote:
> >> Aurelien Jarno skrev:
> >>> biarch packages should not use the multiarch path, otherwise the
> >>> transition to multiarch would be a nightmare.
> >> So how do you propose I multiarchify Wine (and make it ia32-apt-get-able
> >> while I'm at it) without using multiarch paths?
> >
> > You can use the multiarch paths, but only with the path corresponding to
> > the architecture of the .deb that is:
> > - /usr/lib/i486-linux-gnu on i386
> > - /usr/lib/x86_64-linux-gnu on amd64
> > - etc.
>
> That won't help. Even if it had made any sense to put 32-bit libraries
> into /usr/lib/x86_64-linux-gnu, I've done these changes for a reason.
> For Win64 support, I need a path to place the 32-bit Wine libraries as
> well as a path to place the 64-bit Wine libraries, simultaneously and
> nonconflicting. Preferably paths that ld.so will also actually search.
> It turns out that using different library paths in the i386 and amd64
> build (/usr/lib on i386 vs /usr/lib32 on amd64) is going to break under
> the likes of ia32-apt-get (and, of course, under real multiarch) since
> the correct path must be compiled into libwine, and the only path I know
> that is supposed to work the same on i386 and amd64 for holding 32-bit
> libraries is /usr/lib/i486-linux-gnu.
ia32-apt-get is gone, so I am not sure trying to support it is a good
idea.
> Hence I've multiarchified Wine, and as a temporary measure until real
> multiarch is here, I still build amd64 packages with i386 content
> inside. Once multiarch is here, and the user can install the i386
> packages directly, *then* I'll switch the build system to only build the
> 64-bit content into the amd64 packages, and make it the user's
> responsibility to coinstall the 32-bit and 64-bit packages. (And try to
How are you going to handle this transition then? With the current
situation, wine-unstable will provide the same file in the i386 package
and the amd64 package (as the amd64 one already provide
/usr/lib/i486-linux-gnu), so you will have to play with
cross-architectures conflicts.
> avoid holding up any transitions.) Until that's possible, I need a way
> to ship 32-bit and 64-bit libraries from the same packages, making the
> package conform to the upcoming multiarch stuff seemed like a reasonable
> solution, and de-multiarching the package (and be back at square one)
> again doesn't really seem appealing...
>
Don't put the libraries not conforming to the architecture of the
package in the multiarch path. You can chose /usr/lib32 or an other
path providing you add it to /etc/ld.so.conf.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aure...@aurel32.net http://www.aurel32.net
--
Ove Kaaven
> ia32-apt-get is gone, so I am not sure trying to support it is a good
> idea.
It might come back. Or something like it, perhaps.
>> Hence I've multiarchified Wine, and as a temporary measure until real
>> multiarch is here, I still build amd64 packages with i386 content
>> inside. Once multiarch is here, and the user can install the i386
>> packages directly, *then* I'll switch the build system to only build the
>> 64-bit content into the amd64 packages, and make it the user's
>> responsibility to coinstall the 32-bit and 64-bit packages. (And try to
>
> How are you going to handle this transition then? With the current
> situation, wine-unstable will provide the same file in the i386 package
> and the amd64 package (as the amd64 one already provide
> /usr/lib/i486-linux-gnu), so you will have to play with
> cross-architectures conflicts.
Well, I was thinking about handling it by just stop putting the i386
content into the amd64 packages once multiarch works. Any coinstallable
packages are automatically kept in strict lockstep by the multiarch
implementation itself, no need to worry about that. All my interpackage
dependencies are also already strictly versioned. And if I decide to not
set the Multi-Arch field (or if I use Multi-Arch: foreign/allowed) until
I remove the i386 stuff from the amd64 packages, then that by itself
would work as a perfectly suitable cross-architecture conflict.
Hence, to get breakage, someone would probably have to actively try to
get it - which, while probably possible, is a smaller concern to me than
those many who *aren't* actively trying to get breakage, but get it
anyway because of all these breakages and transitions in amd64 -
apparently including this prohibition of actually using multiarch features.
>> avoid holding up any transitions.) Until that's possible, I need a way
>> to ship 32-bit and 64-bit libraries from the same packages, making the
>> package conform to the upcoming multiarch stuff seemed like a reasonable
>> solution, and de-multiarching the package (and be back at square one)
>> again doesn't really seem appealing...
>
> Don't put the libraries not conforming to the architecture of the
> package in the multiarch path. You can chose /usr/lib32 or an other
> path providing you add it to /etc/ld.so.conf.
So you *are* asking to de-multiarch the package?
Aurelien Jarno
> >> avoid holding up any transitions.) Until that's possible, I need a way
> >> to ship 32-bit and 64-bit libraries from the same packages, making the
> >> package conform to the upcoming multiarch stuff seemed like a reasonable
> >> solution, and de-multiarching the package (and be back at square one)
> >> again doesn't really seem appealing...
> >
> > Don't put the libraries not conforming to the architecture of the
> > package in the multiarch path. You can chose /usr/lib32 or an other
> > path providing you add it to /etc/ld.so.conf.
>
> So you *are* asking to de-multiarch the package?
No, I am just asking to stop using /usr/lib/i486-linux-gnu in an amd64
package, which is nothing but multiarch. multiarch implies that the
paths used for the binaries corresponds to the architecture of the
package.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aure...@aurel32.net http://www.aurel32.net
--