wine-devel February 2006

wine-devel@winehq.org

142 participants
259 discussions

linux/capi.h: present but cannot be compiled
by Joshua Crawford 03 Feb '06

03 Feb '06

(I'm not on the devel list, so please Cc: replies either to me or the users list.) After recently upgrading my distro (from Slackware 10.1 to Slackware 10.2 with Freerock GNOME), configure (current CVS) now reports configure: WARNING: linux/capi.h: present but cannot be compiled configure: WARNING: linux/capi.h: check for missing prerequisite headers? configure: WARNING: linux/capi.h: see the Autoconf documentation configure: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/capi.h: proceeding with the preprocessor's result configure: WARNING: linux/capi.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## It seems linux/capi.h requires linux/compiler.h (for __user). I tried simply putting linux/compiler.h above linux/capi.h in the AC_CHECK_HEADERS list, but that did't work, so I'll have to leave the fix to someone who actually knows something about autoconf. This is the relevant section from config.log: configure:7159: checking linux/capi.h usability configure:7171: gcc -c -g -O2 conftest.c >&5 In file included from conftest.c:76: /usr/include/linux/capi.h:80: error: variable or field `__user' declared void /usr/include/linux/capi.h:80: error: syntax error before '*' token /usr/include/linux/capi.h:115: error: syntax error before "capi_manufacturer_cmd" /usr/include/linux/capi.h:117: error: syntax error before '}' token configure:7177: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.6" | #define PACKAGE_STRING "Wine 0.9.6" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | #ifdef __cplusplus | extern "C" void std::exit (int) throw (); using std::exit; | #endif | #define YYTEXT_POINTER 1 | #define HAVE_GETHOSTBYNAME 1 | #define HAVE_CONNECT 1 | #define HAVE_INET_ATON 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_ALSA_ASOUNDLIB_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_ARPA_NAMESER_H 1 | #define HAVE_ASM_TYPES_H 1 | #define HAVE_CUPS_CUPS_H 1 | #define HAVE_CURSES_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_ELF_H 1 | #define HAVE_FLOAT_H 1 | #define HAVE_GETOPT_H 1 | #define HAVE_GIF_LIB_H 1 | #define HAVE_JPEGLIB_H 1 | #define HAVE_LBER_H 1 | #define HAVE_LCMS_H 1 | #define HAVE_LDAP_H 1 | #define HAVE_LINK_H 1 | /* end confdefs.h. */ | #include <stdio.h> | #if HAVE_SYS_TYPES_H | # include <sys/types.h> | #endif | #if HAVE_SYS_STAT_H | # include <sys/stat.h> | #endif | #if STDC_HEADERS | # include <stdlib.h> | # include <stddef.h> | #else | # if HAVE_STDLIB_H | # include <stdlib.h> | # endif | #endif | #if HAVE_STRING_H | # if !STDC_HEADERS && HAVE_MEMORY_H | # include <memory.h> | # endif | # include <string.h> | #endif | #if HAVE_STRINGS_H | # include <strings.h> | #endif | #if HAVE_INTTYPES_H | # include <inttypes.h> | #else | # if HAVE_STDINT_H | # include <stdint.h> | # endif | #endif | #if HAVE_UNISTD_H | # include <unistd.h> | #endif | #include <linux/capi.h> configure:7199: result: no configure:7203: checking linux/capi.h presence configure:7213: gcc -E conftest.c configure:7219: $? = 0 configure:7239: result: yes configure:7252: WARNING: linux/capi.h: present but cannot be compiled configure:7254: WARNING: linux/capi.h: check for missing prerequisite headers? configure:7256: WARNING: linux/capi.h: see the Autoconf documentation configure:7258: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" configure:7260: WARNING: linux/capi.h: proceeding with the preprocessor's result configure:7262: WARNING: linux/capi.h: in the future, the compiler will take precedence configure:7274: checking for linux/capi.h configure:7281: result: yes -- Joshua 'bruce' Crawford ... http://www.geocities.com/mortarn The early bird may get the worm, but the second mouse gets the cheese.

2 2

Most Wanted Windows Apps on Linux
by Vijay Kiran Kamuju 03 Feb '06

03 Feb '06

Hi All, Check this link http://www.desktoplinux.com/news/NS2756049592.html And how many of the top windows programs that are wanted on linux fare with WINE. Thanks and Regards, VJ

1 0

Re: lostwages: update myths
by Juan Lang 02 Feb '06

02 Feb '06

> > + .... One exception, > > +Unreal Tournament 2004, is available in a native Linux 64-bit > > version, so > > +nobody (except maybe a Wine hacker) should want to run the Windows > > version > > +anyway. > Not 100% correct, there's also a Win64 version of Far Cry. I didn't say there is no other Win64 app, but that there are few. The example I happened to pick has a Linux native version. If you want to say instead, that nearly all Win64 apps also have Win32 equivalents, that's fine too. The only one I can think of that doesn't, or won't, is Exchange, and it doesn't work on Wine anyway, and won't for the foreseeable future. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: lostwages: update myths
by Stefan Dösinger 02 Feb '06

02 Feb '06

Am Donnerstag, 2. Februar 2006 18:37 schrieb Juan Lang: > Due to a suggestion from Kate, rewrote the Win16/Win64 section. > > ChangeLog: Win32 has been the default for Wine for years, so say so > + .... One exception, > +Unreal Tournament 2004, is available in a native Linux 64-bit version, so > +nobody (except maybe a Wine hacker) should want to run the Windows version > +anyway. Not 100% correct, there's also a Win64 version of Far Cry. But there's still a 32 Bit version of that game. (Of course there are other Win64 apps too, but I don't think any Wine user has interest in them, since they are part of Win64 :) )

1 0

Re: New wined3d configuration window
by Brian Hill 02 Feb '06

02 Feb '06

It would be nice to have all options automagically detected but in my experience with that commercial wine variant, that simply isn't possible. Games are a complex beast. Let's say a game makes use of Shader Model 2.0. And we are using a future version of wined3d that supports 2.0. But under any ATI cards and their Linux drivers, this kills performance. We could have Wine autodetect and fall-back to a lower shader model with ATI cards but then that would make debugging more difficult. Also, it would vary per game. There could be another SM 2.0 game that does not cause issues on ATI cards. Stefan Dösinger wrote: >Hi, > > >>As long as nobody drops out of the blue sky and makes the best thing >>happen with a touch of h(is/er) magic wand, presenting the available >>options is a *very* nice thing to do. >> >>If the options are there, I might be able to run my games. I'll be >>able to report on the mailing list what options I used to get it to >>run, which should help debug the actual problem. >> >>If the options aren't there, I'll never know that they existed and so >>I'll probably be inclined to just give up and not try to run whatever >>game it is I'm trying to run. >> >> >This is all correct, but on the other hand, some users might complain about a >too complicated setup. Developers on the other hand just tell users to set an >option instead of fixing the code. > >I am all OK with options, but before adding an option one should think why it >is necessary and if it can be avoided. > > >------------------------------------------------------------------------ > > > >

1 0

Re: List box visible items are invalidated from the top if tab stops are used (Bug 4422)
by Alexandre Julliard 02 Feb '06

02 Feb '06

Raimonds Praude <raimonds.praude(a)sets.lv> writes: > Corrected TAB stop processing: if the current tab stops values were modified, > the old items remained with the "old" tabstops, while the new items appeared > with the new ones. Corrected so that all visible items are refreshed. Refreshing the listbox when tab stops are changed would be a good thing, but why are you doing it in LISTBOX_InsertItem? -- Alexandre Julliard julliard(a)winehq.org

1 0

unixfs: Use realpath instead of canonicalize_file_name for portability reasons.
by Michael Jung 02 Feb '06

02 Feb '06

Not quite sure about this one. The man page on realpath states that it's broken by design since some symstems don't have an upper bound on filename lengths. canonicalize_file_name uses dynamic memory, but isn't available on non GNU systems. We could provide a realpath based canonicalize_file_name implementation in libs/port as a fallback, but I guess that would be overkill? realpath assumes the buffer to be PATH_MAX, but FILENAME_MAX is always as least as large as PATH_MAX, so that's ok. See http://www.delorie.com/gnu/docs/glibc/libc_652.html Slightly related, this page states that one should not allocate an FILENAME_MAX array on the stack, since it might be huge. It's 4096 on linux. Do we want to switch this to dynamically allocated memory? IMO it would be overkill, though. ChangeLog: Use realpath instead of canonicalize_file_name for portability reasons. dlls/shell32/shfldr_unixfs.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-)

1 0

Re: setupapi: Add initial implementation of SetupGetInfInformation
by James Hawkins 02 Feb '06

02 Feb '06

On 2/1/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > I only added handling for the INFINFO_INF_SPEC_IS_HINF case to keep > the patch size small, and I'll keep sending in each other case > separately. I've added FIXMEs and BUGS so we know what's left to > implement. The next step is to implement SetupQueryInfFileInformation > so more of the tests pass, but that one is pretty simple. > > Changelog: > * Add initial implementation of SetupGetInfInformation. > Ignore this for now. I thought file->src_root was the name of the INF file, but it's just the directory where the inf file exists. Is there any way I can find out the filename of the INF file using the pointer to the inf_file? I don't know if there are objections to adding a filename field to the inf_file structure, but that is an option. Thanks, James Hawkins

1 0

Is there something wrong with the wined3d patches?
by Vitaly Budovski 02 Feb '06

02 Feb '06

Is there something wrong with the patches dated 20060201? Could someone please point it out? Thanks.

2 1

Re: advpack/tests: fixed failure, when "ProgramFilesDir" is != "C:\Program Files" [resend]
by Detlef Riekenberg 01 Feb '06

01 Feb '06

Am Sonntag, den 29.01.2006, 10:25 +0100 schrieb Stefan Leichter: > anything wrong with this patch ? Already in the tree: http://source.winehq.org/git/?p=wine.git;a=commitdiff;h=c824e8bc5b5c2bfcf56… -- By By ... ... Detlef

1 0

Jump to page:

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 February 2006