April 2012 - Wine-Devel - list.winehq.org

Re: Ubuntu 12.04 (version#2, drop previous mail)

by Eric Pouech

> 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

April 30, 2012

Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by Jerome Leclanche

On Sun, Apr 29, 2012 at 9:50 PM, Eric Pouech <eric.pouech(a)orange.fr> 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 > > > A+ > > -- > Eric Pouech > "The problem with designing something completely foolproof is to > underestimate the ingenuity of a complete idiot." (Douglas Adams) > > I tried for ages to get multiarch compiling working in 12.04, in the end it was the last straw that made me switch to Arch Linux. Other than that, I did get some issues compiling with the newer libjpeg but I think it's been fixed since. J. Leclanche

April 29, 2012

Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by Eric Pouech

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 A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 29, 2012

Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by Eric Pouech

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, just hints if you want to take that road (version #3) (I'm using a multiarch x86_64/i386) now wine compiles and runs in 32bit while compiled on 64bit machine here's the summary of the pain getting it right after upgrade in response to https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321 I was able to compile 32bit-wine on 64bit as I always, and without a chroot or anything similar Problem #1 ---------- an old (11.10 according to the dates) directory was left over after migration, whereas it should have been removed /usr/include/i386-linux-gnu Problem #2 ---------- a ton of symlinks are missing in /usr/lib/i386-linux-gnu for example [root:/usr/lib/i386-linux-gnu]# ls -l /usr/lib/i386-linux-gnu/libfree* lrwxrwxrwx 1 root root 20 avril 3 10:54 /usr/lib/i386-linux-gnu/libfreetype.so.6 -> libfreetype.so.6.8.0 -rw-r--r-- 1 root root 624084 avril 3 10:54 /usr/lib/i386-linux-gnu/libfreetype.so.6.8.0 and it misses lrwxrwxrwx 1 root root 16 avril 28 21:30 /usr/lib/i386-linux-gnu/libfreetype.so -> libfreetype.so.6 the same applies for a lot libraries libXcursor.so libXi.so libXxf86vm.so libxrandr.so libxinerama.so libxcomposite.so libGLU.so libdbus-1.so (libdbus-1.so lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu) libgnutls.so libsane.so libv4l1.so libgphoto2.so libgphoto2_port.so libgstreamer-0.10.so (***) libcapi20.so libcups.so libfontconfig.so libtiff.so libmpg123.so libopenal.so libxrender.so libGL.so (libGL.so is in mesa subdir!!!) libxml2.so libxslt.so libssl.so libcrypto.so libjpeg.so (***) libpng.so.0 (libpng12.so.0 lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu) libXext.so the ones marked (***) means that the symlink is missing but it doesn't solve fully the issue from a wine perspective (see below) Problem #3 (jpeg) ----------------- Fails to open<jconfig.h>. which only lies in /usr/include/x86_64-linux-gnu/jconfig.h, and couldn't be accessed from 32bit build Creating the /usr/include/i386-linux-gnu/ directory and creating a symlink for jconfig.h to /usr/include/x86_64-linux-gnu/jconfig.h just works (I checked the contents of jconfig.h and it looks reasonable to do so) Problem #4 (gstreamer) ---------------------- it doesn't work as only /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h is installed (/usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h doesn't exist, dpkg -S doesn't find it) and /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h defines gint64 as long, which is correct on 64bit targets one wrong on 32 bit ones... one should craft a decent /usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h, or grab one out of pure i386 install (I haven't had time to look further into those, my main interest was to have a 32bit setup up& running) List of potentially installed i386 packages ------------------------------------------- fixed by installing i386 packages (not exhaustive, unfortunately, as I didn't note all the :i386 packages I've manually installed) libldap2.so alternatively, if I do a [eric:~]$ dpkg -l | grep i386 | grep -- -dev ii libc6-dev-i386 2.15-0ubuntu10 Embedded GNU C Library: 32-bit development libraries for AMD64 ii libldap2-dev:i386 2.4.28-1.1ubuntu4 OpenLDAP development libraries ii libpthread-stubs0-dev:i386 0.3-3 pthread stubs not provided by native libc, development files ii libx11-dev:i386 2.1.4.99.1-0ubuntu2 X11 client-side library (development headers) ii libxau-dev:i386 1:1.0.6-4 X11 authorisation library (development headers) ii libxcb1-dev:i386 1.8.1-1 X C Binding, development files ii libxdmcp-dev:i386 1:1.1.0-4 X11 authorisation library (development headers) tends to ask for libc6-dev:i386, libldap2-dev:i386, libx11-dev:i386, libxau-dev:i386, libxcb1-dev:i386, libxdmcp-dev:i386 as dedicated installations of dev:i386 packages but strangely enough, when looking at details, libx11-dev (for example) cannot be installed with libx11-dev:i386 according to manifest, but I have both installed (and both install the same files in /usr/include for example) this looks very strange indeed List of stuff that won't work ----------------------------- won't be supported (just to note them, as those are the left overs from the configure failing list) compiled without multiarch support: libhal, libgsm 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) debugging (32bit and 64bit) is broken ------------------------------------- the debugging is broken it turns out that ptrace and prctl (which had to be added in 11.10) work fine when tracing, only the first started process get correct pid out of wineserver in socket SCM_CREDENTIALS info. the later get 0 I tried to force the pid without requiring the recvmsg stuff and it works just fine I've not found yet the change that broke this more to come if get any futher on the remaining topics A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 29, 2012

Re: wined3d: Fix build with MSVC (try 2).

by Stefan Dösinger

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.

April 29, 2012

Re: [PATCH 0/6] Extended file stat system call

by Dave Chinner

On Fri, Apr 27, 2012 at 01:31:07PM -0600, Andreas Dilger wrote: > On 2012-04-27, at 7:13 AM, Dave Chinner wrote: > > Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined > > at the bottom of the file. > > > > Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly > > generic - they are for indicating that files are to be avoided for > > defrag or backup purposes, the prealloc bit indicates that fallocate > > has been used to reserve space on the inode (finding files that space > > can be punched out of safely), and so on. > > There is already the FS_NODUMP_FL in the standard FS_IOC_GETFLAGS ioctl > and I expect this to be in statxat() also. I forgot that was one of the generic flags :/ > In ext4 there was also an > EXT4_EOFBLOCKS_FL added for inodes with fallocate'd data beyond EOF, > but Eric thought it was a pain to maintain and it has been deprecated > in ext4 and e2fsprogs recently. I'd think that flag is more of a "filesystem implementation specific" flag than a general "this file contained persistent preallocation" flag, which is essentially what the XFS flag says. XFS uses in various ways to optimise extent management on the file (e.g. don't truncate extents past EOF when closing the file), but it is not specific to one particular aspect of the preallocation implementation. > >> OTOH, there's plenty of uncommitted space, so if we can condense > >> the hints down to something small, we could perhaps add it later - > >> but from your paragraph above, it doesn't sound like it'll be small. > > > > Allocation block size, minimum sane IO size (to avoid page cache RMW > > cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit), > > optimal IO size for bandwidth (e.g. stripe width). I don't think > > there's much more than that which will be really usable by > > applications. > > I think this is a minimal set that makes sense, and is manageable for > both the interface and for users. Even if it isn't 100% correct for > every file of every filesystem, it still makes sense for many systems. That's the aim, isn't it? To expose what is useful to the majority in a simple manner? > I'd suggest st_frsize (like BSD statvfs() f_frsize) would be the > minimum fragment or page size, st_iosize (BSD f_iosize) could be > the optimal IO size, and "st_stripesize" for the minimum preferred RAID/chunk size. Personally, I think those names are, well, terribly lacking in obviousness. Something more along the lines of: st_blksize - file block size st_alloc_blksize - allocation block size/alignment st_small_io_size - IO size/alignment that avoids filesystem/page cache RMW st_preferred_io_size - preferred IO size for general usage. st_large_io_size - IO size/alignment for high bandwidth sequential IO With the aim that applications tend to use st_preferred_io_size for all general IO (i.e. the default), st_small_io_size for small IO, IOPS intensive workloads, and st_large_io_size for writing large chunks of sequential data. > One could argue that "st_blksize" is used for the "optimal IO size" > on Linux today, but this is an overloaded term. It _appears_ to > represent the filesystem blocksize, which it usually is not, and on > BSD st_bsize means the minimum blocksize and has a confusingly > similar name. Since any application using this API needs to do some > extra coding already, we may as well give the structure members good > names that are not ambiguous. Well said - I couldn't have stated the case better myself. ;) Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 28, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Fri, Apr 27, 2012 at 7:38 PM, Dave Chinner <david(a)fromorbit.com> wrote: > preferred minimum IO size (mp->m_readio_log/mp->m_writeio_log) This discussion about i/o sizes is very interesting. For network file system (at least for SMB2 to all known servers, and for cifs mounts to Samba, but probably for recent NFS), ideal i/o sizes are often well over a megabyte ... but how to indicate that to the application... > That's why I'd prefer specific optimal IO hints - we don't have to > overload st_blksize with lots of meanings to pass what is relatively > trivial information back to the application. > > Cheers, > > Dave. > -- > Dave Chinner Yes. -- Thanks, Steve

April 28, 2012

Re: [PATCH 0/6] Extended file stat system call

by Dave Chinner

On Thu, Apr 26, 2012 at 09:22:04PM -0600, Andreas Dilger wrote: > On 2012-04-26, at 7:06 PM, Dave Chinner wrote: > > On Thu, Apr 19, 2012 at 03:05:58PM +0100, David Howells wrote: > >> > >> Implement a pair of new system calls to provide extended and further extensible stat functions. > >> > >> The second of the associated patches is the main patch that provides these new system calls: > >> > >> ssize_t ret = xstat(int dfd, > >> const char *filename, > >> unsigned atflag, > >> unsigned mask, > >> struct xstat *buffer); > >> > >> ssize_t ret = fxstat(int fd, > >> unsigned atflag, > >> unsigned mask, > >> struct xstat *buffer); > >> > >> which are more fully documented in the first patch's description. > >> > >> These new stat functions provide a number of useful features, in summary: > >> > >> (1) More information: creation time, inode generation number, data > >> version number, flags/attributes. A subset of these is available > >> through a number of filesystems (CIFS, NFS, AFS, Ext4 and BTRFS). > > > > If we are adding per-inode flags, then what do we do with filesystem > > specific flags? e.g. XFS has quite a number of per-inode flags that > > don't align with any other filesystem (e.g. filestream allocator, > > real time file, behaviour inheritence flags, etc), but may be useful > > to retrieve in such a call. We currently have an ioctl to get that > > information from each inode. Have you thought about how to handle > > such flags? > > I'm sympathetic to your cause, but I don't want this to degrade into > the same morass that it did last time when every attribute under the > sun was added to the call. Understood, which is why I'm not asking for everything under the sun to be supported. I'm more interested in finding the useful subset of information that a typical application might make use of. > The intent is to replace the stat() call > with something that can avoid overhead on filesystems for which some > attributes are expensive, and that applications may not need. Some > common attributes were added that are used by multiple filesystems. > > If it is too filesystem-specific, and there is little possibility > that these attributes will be usable on other filesystems, then it > should remain a filesystem specific ioctl() call. Right, that's why I didn't mention the real-time bits, the filestream allocation bits, or other things that are tightly bound to the way XFS works.... > If you can make > a case that these attributes have value on a few other filesystems, > and applications are reasonably likely to be able to use them, and > their addition does not make the API overly complex, then suggest > away. Exactly my thoughts ;) > > Along the same lines, filesytsems can have different allocation > > constraints to IO the filesystem block size - ext4 with it's > > bigalloc hack, XFS with it's per-inode extent size hints and the > > realtime device, etc. Then there's optimal IO characteristics > > (e.g. geometery hints like stripe unit/stripe width for the > > allocation policy of that given file) that applications could use > > if they were present rather than having to expose them through > > ioctls that nobody even knows about... > > There is already "optimal IO size" that the application can use, > how do the geometry hints differ? Have a look at how XFS overloads stat.st_blksize depending on the filesystem and inode config. It's amazingly convoluted, and based on a combination of filesystem geometry, inode bits and mount options: xfs_vn_getattr() .... if (XFS_IS_REALTIME_INODE(ip)) { /* * If the file blocks are being allocated from a * realtime volume, then return the inode's realtime * extent size or the realtime volume's extent size. */ stat->blksize = xfs_get_extsz_hint(ip) << mp->m_sb.sb_blocklog; } else stat->blksize = xfs_preferred_iosize(mp); ...... xfs_extlen_t xfs_get_extsz_hint( struct xfs_inode *ip) { if ((ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE) && ip->i_d.di_extsize) return ip->i_d.di_extsize; if (XFS_IS_REALTIME_INODE(ip)) return ip->i_mount->m_sb.sb_rextsize; return 0; } .... static inline unsigned long xfs_preferred_iosize(xfs_mount_t *mp) { if (mp->m_flags & XFS_MOUNT_COMPAT_IOSIZE) return PAGE_CACHE_SIZE; return (mp->m_swidth ? (mp->m_swidth << mp->m_sb.sb_blocklog) : ((mp->m_flags & XFS_MOUNT_DFLT_IOSIZE) ? (1 << (int)MAX(mp->m_readio_log, mp->m_writeio_log)) : PAGE_CACHE_SIZE)); } All of that can be exported as 4 parameters for normal files: allocation block size (extent size hint) minimum io size (PAGE_CACHE_SIZE) preferred minimum IO size (mp->m_readio_log/mp->m_writeio_log) best aligned IO size (stripe width) And for realtime files it's a bit different because of the block-based bitmap allocator it uses: allocation block size (extent size hint) minimum io size (PAGE_CACHE_SIZE) preferred minimum IO size (extent size hint) best aligned IO size (some multiple of extent size hint) > Userspace is able to handle > st_blksize of several MB in size without problems, and any sane > application will do the IO sized + aligned on multiples of this. Actually, some applications still have problems with that. That's the reason we only expose stripe widths in st_blksize when a mount option is set. Stripe widths are known to get into the tens of MB, and applications using st_blksize for memory allocation of IO buffers tend to get into trouble with those. That's why I'd prefer specific optimal IO hints - we don't have to overload st_blksize with lots of meanings to pass what is relatively trivial information back to the application. Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 28, 2012

Re: [PATCH 0/6] Extended file stat system call

by Paul Eggert

On 04/26/2012 11:25 AM, Roland McGrath wrote: > What I'd really prefer is a name that is less meaninglessly arcane, Since people are used to the string "stat", and since this is about getting related attributes, how about using the string "statr"? Thus "statrat" could be the syscall that acts like fstatat, but gets related attributes too. A bonus of this name is that a "stat rat" is slang for someone who loves looking at statistics, often sports statistics. Billy Beane is a stat rat. Someone who cares about files' statistics is also a stat rat. The "r" in "statrat" could stand for "related", or for "relevant", or for whatever you like.

April 27, 2012

Re: Wine developer example sessions?

by Dan Kegel

On Fri, Apr 27, 2012 at 1:35 PM, Lucas Zawacki <lfzawacki(a)gmail.com> wrote: > When I first started to learn about wine development I stumbled across > some examples exactly like these in the wine wiki. A quick search > reveals them (the first 3) > http://wiki.winehq.org/DeveloperExamples?action=fullsearch&context=180&valu… > > I myself like this aproach, it's a very useful form of documentation. Ah, thanks, I link to those now, and to a canned query for AF's excellent bug reports, from http://wiki.winehq.org/DeveloperExamples

April 27, 2012