January 2009 - Wine-devel - list.winehq.org

Re: Build wine with gcc-4.3 and ssp
by Stefan Reimer 04 Jan '09

04 Jan '09

> On Fri, Jan 02, 2009 at 11:14:52PM +0100, Stefan Reimer wrote: >> Hi, >> to build wine using gcc 4.3 with enabled ssp (stack-smashing-protector) the following patch must be applied to loader/preloader.c >> >> see gcc source ./gcc/config/i386/i386.c around line 24391 >> >> /* For 32-bit code we can save PIC register setup by using >> __stack_chk_fail_local hidden function instead of calling >> __stack_chk_fail directly. 64-bit code doesn't need to setup any PIC >> register, so it is better to call __stack_chk_fail directly. */ >> >> Patch: >> >> diff --git a/loader/preloader.c b/loader/preloader.c >> index 5fcb974..1143972 100644 >> --- a/loader/preloader.c >> +++ b/loader/preloader.c >> @@ -163,6 +163,7 @@ void __bb_init_func(void) { return; } >> >> /* similar to the above but for -fstack-protector */ >> void *__stack_chk_guard = 0; >> +void __stack_chk_fail_local(void) { return; } >> void __stack_chk_fail(void) { return; } >> >> /* data for setting up the glibc-style thread-local storage in %gs */ > > Hmm, > > why does this work for me on openSUSE then? > > The line: > gcc -c -I. -I. -I../include -I../include -Wall -pipe > -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -W type-limits -Wpointer-arith -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funw > ind-tables -fasynchronous-unwind-tables -g -o preloader.o preloader.c > > works fine here. Are you passing in -fPIC? > > Ciao, marcus > > > Hi, I am using gentoo hardened: gcc (Gentoo Hardened 4.3.2-r7 p1.5, ssp, fortify, pie-10.2.0) 4.3.2 glibc 2.8 Using gcc -v gives: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/cc1 -quiet -v -I. -I. -I../include -I../include -imultilib 32 preloader.c -D_FORTIFY_SOURCE=2 -fPIE -fstack-protector -fstack-protector-all -fno-strict-overflow -quiet -dumpbase preloader.c -m32 -march=athlon64 -auxbase-strip preloader.o -O2 -Wall -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -version -fno-strict-aliasing -o - | /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy --32 -o preloader.o - The hardened gcc specs brings in -fPIE, which is similiar to -fPIC. So YES I do ;-) Is this a problem ? Cyas Stefan

2 2

REALLY EXCITING! wine iexplore.exe http://pyjs.org/examples/
by Luke Kenneth Casson Leighton 04 Jan '09

04 Jan '09

aww folks - bless you :) if all of these worked, then it means that mshtml is coming along _really_ well! i went through the kitchen sink example, and it passed - everything - with flying colours. the library unit test - passes everything! even the SVG canvas (in the addons) works! i was _just_ about to get _really_ excited, when i ran the JSONRPC example, but awwwww, i got this: fixme:mshtml:nsUploadChannel_SetUploadStream Unsupported aContentType argument: "application/x-www-form-urlencoded" darn, darn :) if that had worked first time, it would have been _unbelievable_ - and _so_ exciting. i liked especially the way that internet explorer is detected as Mozilla-compatible. to support IE's javascript features _would_ perhaps bit a _little_ too much :) but the real purpose of this message is to say WELL XXXXING DONE! l.

2 1

question on how to do language bindings to MSHTML's COM interface
by Luke Kenneth Casson Leighton 03 Jan '09

03 Jan '09

folks, hi, i have a rather intriguing issue i'd like to look at, which takes quite a bit of explaining as to why i'd like to go about it - if people are interested i can answer that, but for now i'll leave it at this: how, under linux, would i go about making an application that made _use_ of MSHTML.DLL's functionality, via its COM / DCE/RPC / MSRPC interface? in other words, if you are familiar with gecko / XUL, how would i go about making a gecko / XUL style of application, using MSHTML as the basis, and, once that was achieved, would it stand a chance of successfully running under vanilla windows, using MS's own version of MSHTML? yes i _am_ fully aware that, underneath, according to the wiki page on mshtml's implementation, mshtml underneath uses Gecko - but i don't _want_ to use the Gecko / XUL interface (mostly because it already exists! i don't like challenges that have already been done :) specifically, i'd _really_ like to have python bindings to the COM bindings to MSHTML - all under linux. so there are some _really_ weird esoteric "sub-questions" involved, such as: "what are the chances of porting pywin32 - specifically pywin32's COM bindings - to linux, thanks to widl and friends"? see http://sourceforge.net/projects/pywin32 many thanks for any advice and information. l.

2 4

[PATCH] Compile fix on Linux 2.6.28 / x86
by Pavel Troller 03 Jan '09

03 Jan '09

Hi! Due to changes in Linux kernel include file structure, the following patch is necessary to compile wine with the 2.6.28 kernel: --- wine/dlls/ntdll/serial.c.old 2009-01-03 19:31:17.000000000 +0100 +++ wine/dlls/ntdll/serial.c 2009-01-03 20:31:11.000000000 +0100 @@ -74,6 +74,10 @@ #include "wine/debug.h" #ifdef HAVE_LINUX_SERIAL_H +#include <linux/version.h> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28) +#include <asm/types.h> +#endif #include <linux/serial.h> #endif With regards, Pavel Troller

3 3

Re: Build wine with gcc-4.3 and ssp
by Marcus Meissner 03 Jan '09

03 Jan '09

On Fri, Jan 02, 2009 at 11:14:52PM +0100, Stefan Reimer wrote: > Hi, > to build wine using gcc 4.3 with enabled ssp (stack-smashing-protector) > the following patch must be applied to loader/preloader.c > > see gcc source ./gcc/config/i386/i386.c around line 24391 > > /* For 32-bit code we can save PIC register setup by using > __stack_chk_fail_local hidden function instead of calling > __stack_chk_fail directly. 64-bit code doesn't need to setup any PIC > register, so it is better to call __stack_chk_fail directly. */ > > Patch: > > diff --git a/loader/preloader.c b/loader/preloader.c > index 5fcb974..1143972 100644 > --- a/loader/preloader.c > +++ b/loader/preloader.c > @@ -163,6 +163,7 @@ void __bb_init_func(void) { return; } > > /* similar to the above but for -fstack-protector */ > void *__stack_chk_guard = 0; > +void __stack_chk_fail_local(void) { return; } > void __stack_chk_fail(void) { return; } > > /* data for setting up the glibc-style thread-local storage in %gs */ Hmm, why does this work for me on openSUSE then? The line: gcc -c -I. -I. -I../include -I../include -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -W type-limits -Wpointer-arith -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funw ind-tables -fasynchronous-unwind-tables -g -o preloader.o preloader.c works fine here. Are you passing in -fPIC? Ciao, marcus

2 2

Re: kernel32: implement CPU detection for OpenBSD
by Rob Shearman 03 Jan '09

03 Jan '09

2009/1/3 Austin English <austinenglish(a)gmail.com>: > diff --git a/dlls/kernel32/cpu.c b/dlls/kernel32/cpu.c > index 63ca277..10a8e87 100644 > --- a/dlls/kernel32/cpu.c > +++ b/dlls/kernel32/cpu.c > @@ -544,7 +544,7 @@ VOID WINAPI GetSystemInfo( > } > fclose (f); > } > -#elif defined (__NetBSD__) > +#elif defined (__NetBSD__) || defined(__OpenBSD__) > { > int mib[2]; > int value[2]; Why not just do something like the following: #ifdef __OpenBSD___ size_t value[2]; #else int value[2]; #endif And then you wouldn't have to ifdef each sysctl call. > @@ -557,31 +557,55 @@ VOID WINAPI GetSystemInfo( > #ifdef CPU_FPU_PRESENT > mib[1] = CPU_FPU_PRESENT; > value[1] = sizeof(int); > - if (sysctl(mib, 2, value, value+1, NULL, 0) >= 0) > +#ifdef __OpenBSD__ > + if (sysctl(mib, 2, value, (size_t *)(value+1), NULL, 0) >= 0) { > +#else > + if (sysctl(mib, 2, value, value+1, NULL, 0) >= 0) { > +#endif ... -- Rob Shearman

2 1

App Database Ratings
by Keith Muir 03 Jan '09

03 Jan '09

Recently read the thread on the poor quality of the ratings but changing the wording isn't going to have much of an effect. A properly structured questionnaire that then suggests a rating will. The problem with this is the amount of work required to overhaul the database in order to do it. That said the ratings are instead of being objective, which is what wine users and developers want, subjective and nearly useless.

2 1

Fwd: [Wine] Look for a Wine Expert to Possibly hire....
by Austin English 03 Jan '09

03 Jan '09

For those of you that don't read wine-users: ---------- Forwarded message ---------- From: BaseHead <wineforum-user(a)winehq.org> Date: Sat, Jan 3, 2009 at 4:18 AM Subject: [Wine] Look for a Wine Expert to Possibly hire.... To: wine-users(a)winehq.org Hey all! We make a Sound FX Database Program called BaseHead for windows. www.baseheadinc.com we would love to make it run on OS X and Linux with Wine. I did already get it up and running via Crossover which I saw is based on WINE which bought me here. It runs pretty chunky using Crossover tho.........8( We are looking to possibly hire someone to make us an all in one BaseHead/Wine Installer that is optimized to run under OS X and Linux that is custom for us. Basically we'd need someone that knows quite a bit about wine to tell us what will works good and what doesn't and if it's even possible. AND if we need to change certain coding to make it run better and what pitfalls to avoid etc.... if anyone one is interested send me an email steve 'AT' baseheadinc 'DOT' com or go to the site and use the contact forum thx!! Steve -- -Austin

1 0

Re: [PATCH 2/3] fusion: Add tests for the IAssemblyEnum interface. [try4]
by Alexandre Julliard 03 Jan '09

03 Jan '09

"James Hawkins" <truiken(a)gmail.com> writes: > Now handling different ordering of directory listings. It doesn't work here: ../../../tools/runtest -q -P wine -M fusion.dll -T ../../.. -p fusion_test.exe.so asmenum.c && touch asmenum.ok asmenum.c:445: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0", got "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" asmenum.c:479: Test failed: Expected "Wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "Wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" asmenum.c:492: Test failed: Expected "Wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0", got "Wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" asmenum.c:573: Test failed: Expected "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" asmenum.c:586: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" or "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" make: *** [asmenum.ok] Error 5 -- Alexandre Julliard julliard(a)winehq.org

1 0

libwine.so "incompatible"???
by Luke Kenneth Casson Leighton 03 Jan '09

03 Jan '09

rob, anyone - any ideas? gcc -pthread -shared -o libpython2.5.so Modules/_typesmodule.o Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/tokenizer.o Objects/abstract.o Objects/boolobject.o Objects/bufferobject.o Objects/cellobject.o Objects/classobject.o Objects/cobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/intobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/methodobject.o Objects/moduleobject.o Objects/object.o Objects/obmalloc.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/stringobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/weakrefobject.o Objects/unicodeobject.o Objects/unicodectype.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/errors.o Python/frozen.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getmtime.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/pyarena.o Python/pyfpe.o Python/pystate.o Python/pythonrun.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrtod.o Python/dynload_shlib.o Python/thread.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o -lpthread -ldl -lutil -lwine -lm; \ fi /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/libwine.so when searching for -lwine /usr/bin/ld: skipping incompatible /usr/lib/../lib/libwine.so when searching for -lwine /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libwine.so when searching for -lwine /usr/bin/ld: skipping incompatible /usr/bin/../lib/libwine.so when searching for -lwine /usr/bin/ld: skipping incompatible /usr/lib64/libwine.so when searching for -lwine /usr/bin/ld: skipping incompatible /usr/lib/libwine.so when searching for -lwine /usr/bin/ld: cannot find -lwine collect2: ld returned 1 exit status

1 2