wine-devel

wine-devel@winehq.org

84463 discussions

CVS compilation problem: XvSelectNotify
by Heiko Nardmann 05 Jun '01

05 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just compiled CVS wine using ./configure --prefix=/opt/wine-20010605 --enable-dll --with-x and get the following error message starting Word: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /opt/wine-20010510/lib/libwine_tsx11.so: undefined symbol: XvSelectPortNotify Could not load graphics driver 'x11drv' - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7HJ2Opm53PRScYygRAkZsAKCXRyt3ncR7sFRNatc7/6Bls3+eywCg9sO5 7oombEYBU9llG4o8Gp7LeyA= =a8Qa -----END PGP SIGNATURE-----

1 0

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 07:20 AM 05/06/2001 +0200, you wrote: >Not really, as Alexandre said. > >Could you please test the attached small test program? It fails (of course). Here is the call with my working computer (glibc2.2, linux 2.4) 0x8048668 <main+72>: call 0x8048464 <write> 0x804866d <main+77>: add $0xc,%esp 0x8048670 <main+80>: push $0x0 0x8048672 <main+82>: push $0x0 0x8048674 <main+84>: push %ebx 0x8048675 <main+85>: push $0x1 0x8048677 <main+87>: push $0x3 0x8048679 <main+89>: push $0x4 0x804867b <main+91>: push $0x0 0x804867d <main+93>: call 0x80484a4 <mmap64>p For the failing one : 0x80486c8 <main+72>: call 0x80484dc <write> 0x80486cd <main+77>: addl $0x20,%esp 0x80486d0 <main+80>: addl $0xfffffff8,%esp 0x80486d3 <main+83>: pushl $0x0 0x80486d5 <main+85>: pushl %ebx 0x80486d6 <main+86>: pushl $0x1 0x80486d8 <main+88>: pushl $0x3 0x80486da <main+90>: pushl $0x4 0x80486dc <main+92>: pushl $0x0 0x80486de <main+94>: call 0x804851c <mmap64> This calls fails because glibc detects that the value at (esp+28) is different of 0 - the real system call is never done, with your test app and Wine. In the glibc 2.1.3 source, this test is not explained; in the 2.2.2 source, there is a comment saying that the offset is 'too large'. I understand that the app is calling mmap64 on an operating system that is not supporting it (it's perfectly correct in this case, the failing box having 2.2.5 kernel), and glibc tests if the call can be mapped to standard mmap. I think that the problem is in the compilation; pushing only 6 dwords on the stack to call mmap64 is wrong. I have not yet figured out why, though (I have never been any good with C header problems) Gerard

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 08:12 AM 03/06/2001 +0200, you wrote: >> After applying your patch to current cvs, rm config.cache, ./configure, >> make depend && make Wine crashes as before. > >You need to run 'autoheader -l include' if any change to acconfig.h >is submitted. Thanks, it worked. Problem solved IMO. Gerard

1 0

mIRC crash when processing large files.
by rpbrown＠xtra.co.nz 05 Jun '01

05 Jun '01

Details how to replicate the crash. (yes its time consuming, but it shows the crash) Ok, this is what I do to crash mIRC in wine. I install the mp3-script for mIRC. http://welcome.to/autoget load the script according to the readme..and join IRC Undernet, any Undernet server will do. /join #mpthree the person we're looking for is SuperServ (an Op) right mouse on the nick, and grab there mp3 list.. you can try other ppls lists, but SuperServ has a rather big list (8Mb) which at the end of the download the script keeps on loading (processing the txt file) ..and then crashes mIRC. Loading _this_ list itself into mIRC under windows normally, mIRC is locked for a 3-4 minutes (processing the list).. maybe wine gives up too soon, since its not getting a response within X amount of time. Or the list is too big for wine to handle? thats my guesses.. I hope this helps. -mdew

1 0

uname(1) on UnixWare (Solaris)
by Bang Jun-Young 05 Jun '01

05 Jun '01

Hi, I've nearly completed new DLL configuration code in configure.in. Before making it available, I need to know what uname(1) command prints out on UnixWare (and Solaris?). As in NetBSD, it's: $ uname NetBSD I guess it would be $ uname UnixWare on UnixWare. I also wonder if UnixWare and Solaris refer to the same. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

1 0

Re: FreeType autoconf checks
by Alexandre Julliard 05 Jun '01

05 Jun '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > CPPFLAGS works. Where the heck is that documented? (I can't find it in > the info pages for gcc or cpp.) It's not a gcc option, it's a configure internal variable (from $ac_cpp definition). This is the whole point: it will work independently of the compiler, or at least break the same way during configure and during the compile, which is what we want. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: set_thread_buffer fixed
by lawson_whitney＠juno.com 05 Jun '01

05 Jun '01

On Sun, 3 Jun 2001, Marcus Meissner wrote: > Is this the case where set_thread_buffer fails or not? > Okay, it is not. It crashes in debug_printf or dump_exports (pe_image.c). However, it is so too a glibc-2.1.3 problem. I think. Sort of. The same Wine that crashes with kernel 2.4.4 and 2.4.5 works fine with kernel 2.2.14, and I bet later 2.2.x kernels when (if) I get around to building them. I think I might not be smart enough to debug it in detail. Maybe I should just send www4mail after glibc-2.2 instead. > I don't see a failure message here. > > Also, could you try to run the attached test program and see if it fails? success with either kernel version. Hmmm, do I have 2.0.30 still lying around? 1.3.18? > > Ciao, Marcus > Lawson Constants aren't, and variables won't. ---cut--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: FreeType autoconf checks
by Alexandre Julliard 04 Jun '01

04 Jun '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > One thing to keep in mind, however. The FreeType headers themselves > use relative paths to include one another, so this is an issue that > we're not going to be able to completely eliminate. This is why I > had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER > tries to preprocess the header file, so it has to be able to find any > subsidiary headers. (Is this what you mean by finding a way to check > that #include <freetype/freetype.h> works?) Yes; we should be using only relative paths in AC_CHECK_HEADER, since this is what we will use in the code. I don't think C_INCLUDE_PATH is portable either. Did you try setting CPPFLAGS instead? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: FreeType autoconf checks
by Ian Pilcher 04 Jun '01

04 Jun '01

Alexandre Julliard wrote: > > Well, I don't like it much, but I haven't had time to look into a > better solution yet. Basically I think it's dangerous to check for the > file name with an absolute path and then include it with a relative > path, since there is no guarantee we'll get the same file. I think we > should really find a way to check that #include <freetype/freetype.h> > works given the right C flags. Also I'm not sure about the portability > of the ${FREETYPEINCL#-I} construct. > I see your point. Now that I think about it, I probably would have been bitten by it if anyone will. I run Red Hat 7.1 which has: /usr/include/freetype/freetype.h (from FreeType 1.x) /usr/include/freetype2/freetype/freetype.h (from FreeType 2.x) I just checked the gcc documentation, and directories specified with '-I' options on the command line are checked first. I have no idea, however, if other compilers behave in a similar manner. Using absolute paths for the FreeType headers would be non-trivial, but probably doable. We would have to use autoconf to define macros that include the complete path name of the headers we want to include; then #include those macros instead of the file names. Somehow, I don't think you're going to want to do that. One thing to keep in mind, however. The FreeType headers themselves use relative paths to include one another, so this is an issue that we're not going to be able to completely eliminate. This is why I had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER tries to preprocess the header file, so it has to be able to find any subsidiary headers. (Is this what you mean by finding a way to check that #include <freetype/freetype.h> works?) I also had the same thought about the ${FREETYPEINCL#-I} construct. According to http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_006_002 it seems to be OK. Frankly, I share your distaste for this whole mess. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: fixup bogus SetLastError()
by Alexandre Julliard 04 Jun '01

04 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > objects/gdiobj.c really has no business dealing with SetLastError(). > SetLastError() is a mechanism to communicate errors to external programs, > so it should definitely not be used for highly internal functions. You didn't include the gdiobj.c patch, but I disagree with it anyway... There can be many good reasons for setting last error in internal functions; for instance setting it inside GDI_GetObjPtr avoids having to set it in every single caller. And in the very rare case where this is not what we want, the caller can always set it to another value. -- Alexandre Julliard julliard(a)winehq.com

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel