Re: Ubuntu 12.04 (version#2, drop previous mail)
This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ -- -- Eric Pouech
Re: Ubuntu 12.04 (version#2, drop previous mail)
On Mon, Apr 30, 2012 at 10:37 AM, Eric Pouech eric.pou...@orange.fr wrote: This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ +1. One of the reasons I stopped contributing to Wine is that it became too hard to set up 32 bit dev libraries on a 64 bit Ubuntu 11.10 system with its broken multiarch. I was hoping it would be fixed in 12.04, but if it's so broken now that we have to use a chroot, then I might as well use FreeBSD where chroot has always been the only way. Damjan Jovanovic
Re: [1/2] gdi32: GetGlyphOutline should fail for a bitmap font.
On Sat, Apr 28, 2012 at 05:52:13PM +0900, Dmitry Timoshkov wrote: --- dlls/gdi32/freetype.c |6 ++ dlls/gdi32/tests/font.c | 17 - 2 files changed, 18 insertions(+), 5 deletions(-) This will break the display of bitmap fonts in winex11.drv . Do you have an app that depends on this? Huw.
Re: [1/2] gdi32: GetGlyphOutline should fail for a bitmap font.
Huw Davies h...@codeweavers.com wrote: On Sat, Apr 28, 2012 at 05:52:13PM +0900, Dmitry Timoshkov wrote: --- dlls/gdi32/freetype.c |6 ++ dlls/gdi32/tests/font.c | 17 - 2 files changed, 18 insertions(+), 5 deletions(-) This will break the display of bitmap fonts in winex11.drv . Do you have an app that depends on this? No, I have no an app that depends on this. I just tried to test bitmap font metrics with GetGlyphOutline since in Wine it's used to get metrics even for bitmaps. and found that it's supposed to fail. I guess that I resend the test without a fix then. -- Dmitry.
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
On 04/29/2012 10:44 PM, Eric Pouech wrote: for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile That's funny because I just tried yesterday and filed [1] to see what developers think. They are aware of the issue but will need some time to fix it. What I discovered is that installing gcc:i386 on amd64 doesn't mean what we think. It replaces the (amd64) gcc and wants to remove gcc and build-esential (and others). What we want is gcc-multilib which provides libc6-dev-i386. The other way also exists with libc6-dev-amd64:i386 (compiling programs targeting amd64 from a i386 computer) For the other issues, I guess we'll have to file as many bug as packages which are not multiarch-able. (I don't know how to say it, hope you get the idea) Hope it helps --- [1] : https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/990982
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
On 04/29/2012 10:44 PM, Eric Pouech wrote: snip Warning at compilation -- when compiling, some warnings still have to be worked upon /home/eric/work/wine/dlls/winex11.drv/keyboard.c:1109:5: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] this one can be forgotten for now (it's just being marked deprecated in precise, so warning doesn't come from misconfiguration) FYI, I asked it to be marked as deprecated in [1] when solving bug #21307 [2]. Now ([3] from [4]), wine uses XkbKeycodeToKeysym when available. --- [1] : https://bugs.freedesktop.org/show_bug.cgi?id=5349 [2] : http://bugs.winehq.org/show_bug.cgi?id=21307 [3] : http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/keyboard.c#l1104 [4] : http://source.winehq.org/git/wine.git/commitdiff/a30b94651d9f01b4bfa9afd073b7e02861e52f10
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
Eric Pouech wrote: Le 29/04/2012 22:44, Eric Pouech a écrit : for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile This could be useful if you want to have a dual x86_64 : i386 setup this is an updated version to what I already sent to scott ritchie of course this is not a step by step installation I forgot to mention that ubuntu devels did a crappy job in 12.04 I'm really starting to get angry at their inability to take care of upward compat in what they do Maybe looking at 'sudo apt-get build-dep wine' and the Wine packaging scripts will also reveal what's needed to build 32-bit Wine on Ubuntu 12.04 64-bit. In general the 12.04 release still has loads of bugs however. It seems the developers couldn't manage to look over all the reported bugs anymore before the release, but decided to release anyhow. They probably only focused on the crash bugs, because there are not many crashes, but many things do not work yet as they should. I expect 12.04.1 will contain a very significant amount of fixes. Julius
Re: wined3d: Fix build with MSVC (try 2).
On 2012-04-29 12:05, Stefan Dösinger wrote:
Am Samstag, 28. April 2012, 10:16:13 schrieb Thomas Faber:
Apparently NAN and INFINITE are C99 as well (I should really get a
version of the old standard instead of mostly reading C99 :|).
How about a simple const variable that will trick MSVC, while not
changing semantics.
How about a function in libs/port or a macro in one of its headers? I believe
the NAN/INFINITE issue is not specific to wined3d.
With the const variable, msvc compiles the code, but still produces a warning.
Ah, the warning appears only with optimization enabled, that's why I didn't
notice.
port sounds great - but (assuming there shouldn't be any 0x7fc0 or
#ifdef _MSC_VER in the solution) the best I can come up with at the moment
is the following :|
#ifndef INFINITY
static float __infinity(int x)
{
const float zero = x ? 0.0f : 1.0f;
return 1.0f / zero;
}
# define INFINITY __infinity(1)
#endif
#ifndef NAN
static float __nan(int x)
{
const float zero = x ? 0.0f : 1.0f;
return zero / zero;
}
# define NAN __nan(1)
#endif
Re: wined3d: Fix build with MSVC (try 2).
Am Montag, 30. April 2012, 15:26:30 schrieb Thomas Faber: port sounds great - but (assuming there shouldn't be any 0x7fc0 or #ifdef _MSC_VER in the solution) the best I can come up with at the moment is the following :| Alexandre prefers checks in configure that set macros like HAVE_INFINITY in config.h. For my own msvc builds I have a hand-written config.h file - I'm not sure if there's a way to tell configure running in mingw or cygwin to use msvc as the compiler. signature.asc Description: This is a digitally signed message part.
Re: [1/3] d3dx9: Define DDS structures. (try 3)
The patches look good to me.
Am Sonntag, 29. April 2012, 21:43:08 schrieb Józef Kucia:
This patch series implements the DDS support for D3DXGetImageInfo functions.
Try 2: Define pitch as LONG.
Try 3: Revert it back to DWORD.
---
dlls/d3dx9_36/surface.c | 66
++- 1 files changed, 65
insertions(+), 1 deletions(-)
diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c
index 567282c..3319927 100644
--- a/dlls/d3dx9_36/surface.c
+++ b/dlls/d3dx9_36/surface.c
@@ -28,9 +28,73 @@ WINE_DEFAULT_DEBUG_CHANNEL(d3dx);
/* Wine-specific WIC GUIDs */
-
DEFINE_GUID(GUID_WineContainerFormatTga,
0x0c44fda1,0xa5c5,0x4298,0x96,0x85,0x47,0x3f,0xc1,0x7c,0xd3,0x22);
+/* dds_header.flags */
+#define DDS_CAPS 0x1
+#define DDS_HEIGHT 0x2
+#define DDS_WIDTH 0x2
+#define DDS_PITCH 0x8
+#define DDS_PIXELFORMAT 0x1000
+#define DDS_MIPMAPCOUNT 0x2
+#define DDS_LINEARSIZE 0x8
+#define DDS_DEPTH 0x80
+
+/* dds_header.caps */
+#define DDS_CAPS_COMPLEX 0x8
+#define DDS_CAPS_TEXTURE 0x1000
+#define DDS_CAPS_MIPMAP 0x40
+
+/* dds_header.caps2 */
+#define DDS_CAPS2_CUBEMAP 0x200
+#define DDS_CAPS2_CUBEMAP_POSITIVEX 0x400
+#define DDS_CAPS2_CUBEMAP_NEGATIVEX 0x800
+#define DDS_CAPS2_CUBEMAP_POSITIVEY 0x1000
+#define DDS_CAPS2_CUBEMAP_NEGATIVEY 0x2000
+#define DDS_CAPS2_CUBEMAP_POSITIVEZ 0x4000
+#define DDS_CAPS2_CUBEMAP_NEGATIVEZ 0x8000
+#define DDS_CAPS2_VOLUME 0x20
+
+/* dds_pixel_format.flags */
+#define DDS_PF_ALPHA 0x1
+#define DDS_PF_ALPHA_ONLY 0x2
+#define DDS_PF_FOURCC 0x4
+#define DDS_PF_RGB 0x40
+#define DDS_PF_YUV 0x200
+#define DDS_PF_LUMINANCE 0x2
+
+struct dds_pixel_format
+{
+DWORD size;
+DWORD flags;
+DWORD fourcc;
+DWORD bpp;
+DWORD rmask;
+DWORD gmask;
+DWORD bmask;
+DWORD amask;
+};
+
+struct dds_header
+{
+DWORD signature;
+DWORD size;
+DWORD flags;
+DWORD height;
+DWORD width;
+DWORD pitch_or_linear_size;
+DWORD depth;
+DWORD miplevels;
+DWORD reserved[11];
+struct dds_pixel_format pixel_format;
+DWORD caps;
+DWORD caps2;
+DWORD caps3;
+DWORD caps4;
+DWORD reserved2;
+};
+
+
/
* D3DXGetImageInfoFromFileInMemory
*
signature.asc
Description: This is a digitally signed message part.
Patches 85862 85862
What's wrong with these patches : - http://source.winehq.org/patches/data/85862 - http://source.winehq.org/patches/data/85862 There are marked as pending but can't see anything wrong. Maybe I'm missing something. Christian
Re: [PATCH 3/4] ws2_32/tests: Test for AcceptEx IOCP behavior for a duplicated handle.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18133 Your paranoid android. === WVISTAADM (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W2K8SE (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PRO (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PROX64 (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PROX64 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120
Re: [PATCH 4/4] ws2_32/tests: Test for IOCP behavior without AcceptEx call.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18134 Your paranoid android. === WVISTAADM (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W2K8SE (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PRO (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PROX64 (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (32 bit sock) === sock.c:5628: Test failed: Internal status is c120 === W7PROX64 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120
Re: [PATCH 4/4] ws2_32/tests: Test for IOCP behavior without AcceptEx call (resend).
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18138 Your paranoid android. === W7PROX64 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120
Re: [PATCH 3/4] ws2_32/tests: Test for AcceptEx IOCP behavior for a duplicated handle (try 2).
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18137 Your paranoid android. === W7PROX64 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120 === TEST64_W7SP1 (64 bit sock) === sock.c:5628: Test failed: Internal status is c120
Re: Ubuntu 12.04 (version#2, drop previous mail)
On 4/30/12 1:37 AM, Eric Pouech wrote: This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least Some context would help here: In previous Ubuntus we ran into quite a few bugs (eg Wine's mpeg123 issues) that occurred because we used a 64-bit header file with a 32-bit library and .so symlink. This in turn was because the package manager did not have a concept of foreign-architectures -- 32-bit support on Ubuntu64 was done by installing a giant omni-package called ia32-libs that contained every library that might ever be useful (plus some .so links). Things are _much_ better in 12.04. Wine can actually be built and installed biarch as a user package! Ubuntu users are, for the first time, actually using 64-bit Wine when possible because the package manager understands multiarch and, more importantly, because the underlying libraries are coinstallable with themselves. This was not done for the -dev packages yet due to lack of time -- getting the actual libraries in users hands so programs like Wine can work was much more important. So some foo-dev:i386 will install, but will erase foo-dev:amd64. This is the downside people in this thread are complaining about: compiling 32-bit programs on a 64-bit Ubuntu install is now slightly more difficult. However, Wine is currently the _only_ piece of software I've encountered that needs to be built for both arches on the same machine in order to be usable. We are beautiful special snowflakes here: Wine developers who aren't using the build daemons is about the extent of the current use case. Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ I'm beginning to have memories of what happened when we removed gcc from the default install. Setting up a 32-bit chroot for building Wine should not be complicated -- I'll present a script to make it even easier soon. You can build in a single command and even use things like ccache and the like to speed it up. Thanks, Scott Ritchie
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
On 4/30/12 2:17 AM, GOUJON Alexandre wrote: On 04/29/2012 10:44 PM, Eric Pouech wrote: for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile That's funny because I just tried yesterday and filed [1] to see what developers think. They are aware of the issue but will need some time to fix it. What I discovered is that installing gcc:i386 on amd64 doesn't mean what we think. It replaces the (amd64) gcc and wants to remove gcc and build-esential (and others). What we want is gcc-multilib which provides libc6-dev-i386. The other way also exists with libc6-dev-amd64:i386 (compiling programs targeting amd64 from a i386 computer) For the other issues, I guess we'll have to file as many bug as packages which are not multiarch-able. (I don't know how to say it, hope you get the idea) Yes, this would be prudent. Tag them multiarch too. It's the next phase of the multiarch transition (there are a few lingering packages that aren't properly multiarch as well. It's a good chunk of work, as we have to go package by package and identify if they: 1) Have architecture-specific strings in the -dev stuff 2) Move them into arch-specific folders when appropriate 3) Move files that aren't arch-specific into -common packages that are arch:all 4) Tag the resulting package multiarch: same 5) Send changes back to Debian (which is still in the multiarch bronze age) Thanks, Scott Ritchie
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
On 4/30/12 6:24 AM, Julius Schwartzenberg wrote: Eric Pouech wrote: Le 29/04/2012 22:44, Eric Pouech a écrit : for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile This could be useful if you want to have a dual x86_64 : i386 setup this is an updated version to what I already sent to scott ritchie of course this is not a step by step installation I forgot to mention that ubuntu devels did a crappy job in 12.04 I'm really starting to get angry at their inability to take care of upward compat in what they do Maybe looking at 'sudo apt-get build-dep wine' and the Wine packaging scripts will also reveal what's needed to build 32-bit Wine on Ubuntu 12.04 64-bit. In general the 12.04 release still has loads of bugs however. It seems the developers couldn't manage to look over all the reported bugs anymore before the release, but decided to release anyhow. They probably only focused on the crash bugs, because there are not many crashes, but many things do not work yet as they should. I expect 12.04.1 will contain a very significant amount of fixes. It's sort of a consequence of time-based releases, unfortunately. We were very conservative about new versions of stuff that got into 12.04 to try and minimize new bugs, but stuff invariably comes up. Thanks, Scott Ritchie
