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

Unexpected message from winebuild...

by Kevin Cousins

...when attempting to build a WineLib application. Remember, I'm attempting to get something that will run-time link against a native DLL, so I take my code, run it by "winemaker", run "./configure", then "make", all with options I believe to be appropriate. In particular, given export WINEDIR=/home/kevin/wine, the root of my Wine source tree checked out from winehq CVS yesterday, and export DLLINCDIR=/home/kevin/include, then from within the directory containing the C source code for my simple console app I execute the following: $ winemaker --cuiexe -I${DLLINCDIR} -I${WINEDIR} [...snip...] $ ./configure --with-wine=${WINEDIR} \ --with-wine-dlls=${WINEDIR}/libs/dlls --srcdir=`pwd` \ --with-wine-libraries=${WINEDIR}/libs/wine:${WINEDIR}/libs/uuid:${WINEDIR}/libs/unicode [...snip...] $ make [...snip...] Until make executes, there seems to be no obvious problem (at least to my eyes), and even then, as the compilation happens, I get a nice file called "prog.o" written. However, as "winebuild" executes, I see the following: --- LD_LIBRARY_PATH="/home/kevin/wine/libs/wine:/home/kevin/wine/libs/unicode:$LD_LIBRARY_PATH" /home/kevin/wine/tools/winebuild/winebuild -fPIC -o prog.exe.spec.c --exe prog.exe -mcui prog.o -L/home/kevin/lib -L/home/kevin/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 -lshell32 -luser32 -lwinspool could not open .def file for advapi32 --- I don't believe I even need anything from advapi32.dll.so, let alone most of the other Wine DLLs mentioned on the winebuild command line. Even if I hack the generated Makefile so as to remove mention of any Wine DLLs on the winebuild command line, winebuild still complains about not opening "...a .def file for ntdll". On a related note, the configure script generated by winemaker complains about test linking against -L${WINEDIR}/dlls -lntdll.dll and subsequent equivalent builtin DLLs such as -lkernel32.dll and -luser32.dll. My quick hack is merely to clone the symbolic links in ${WINEDIR}/dlls to add a "lib" prefix, vis: $ ( cd ${WINEDIR}/dlls ; ls -l *ntdll.dll* ) lrwxrwxrwx 1 kevin 18 Apr 1 15:29 ntdll.dll.so -> ntdll/ntdll.dll.so lrwxrwxrwx 1 kevin 18 Apr 1 15:29 libntdll.dll.so -> ntdll/ntdll.dll.so $ That keeps configure happy, but I wonder what I'm doing wrong. This is Wine built from CVS as of 20030401 (i.e. yesterday). Suggestions? Particularly for the wanted .def files. They're %^*&@# builtin DLLs! -- Kevin.

April 2, 2003

Re: Compiling Wine sources with duplicated include parameters

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Though it does not appear to be specified in the standard, all compilers > I know of first look for y.tab.h in the current directory if included > using quotes. At least gcc doesn't do that. It looks in the directory that the source file came from, which is *not* the current directory for out of tree builds. So the -I. is very much needed. -- Alexandre Julliard julliard(a)winehq.com

April 2, 2003

Re: Compiling Wine sources with duplicated include parameters

by Dimitrie O. Paun

On April 2, 2003 12:15 am, Alexandre Julliard wrote: > At least gcc doesn't do that. It looks in the directory that the > source file came from, which is *not* the current directory for out of > tree builds. So the -I. is very much needed. OK, but then we don't need to include the source dir <g>. -- Dimi.

April 2, 2003

Re: Compiling Wine sources with duplicated include parameters

by Dimitrie O. Paun

On April 1, 2003 09:24 pm, Francois Gouget wrote: > Though it does not appear to be specified in the standard, all compilers > I know of first look for y.tab.h in the current directory if included > using quotes. I don't have a standard handy, but AFAIK K&R specifies this behaviour... -- Dimi.

April 2, 2003

Re: Wine's goals

by Francois Gouget

On Sun, 30 Mar 2003, Dimitrie O. Paun wrote: [...] > While what you're stating here is correct, I feel it's way too negative > (and large!) to be on the About page: I think the about page too short <g>. Actually I think it would be better if we appended the 'Why Wine is important' section to it. > we don't do this, nor that, etc. > We already state what we do, that's fine. Some of these things are touched > upon in the FAQ, and that's where we should address this sort of thing IMO. Makes sense. The FAQ format should be a good fit for it. I'll move it there the next time I get some spare time. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

April 2, 2003

Re: Compiling Wine sources with duplicated include parameters

by Francois Gouget

On 1 Apr 2003, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > > > True, but why do we need the -I.? Do we need to ever include anything > > from the current build dir? > > Yes, some headers are generated, for instance the y.tab.h files. Shouldn't these be included with #include "y.tab.h"? In that case -I. should be unnecessary no? Though it does not appear to be specified in the standard, all compilers I know of first look for y.tab.h in the current directory if included using quotes. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

April 2, 2003

Wine

by Tuch

I recently tried to install wine from src and ran into a problem. when it prompted me to enter the root password to do a "make install" I did so, and it proceeded to tell me that I entered an incorrect password. I tried this several times realizing it is possible to enter the password incorrectly, but each time gave the same result. Now I know the password was correct as I am the only user of this box and I installed Slackware 9.0 myself. As a request of your install app, I am e-mailing you this. Thanks Bill

April 2, 2003

Re: winsock.h portability patch causing portability problem

by Alexandre Julliard

Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > I am afraid the following patch > > revision 1.52 date: 2003/03/31 23:56:35; author: julliard; state: Exp; lines: +63 -60 > Try to make winsock.h more portable (based on a patch by Francois > Gouget). > > actually caused a portability problem for FreeBSD. I changed the way we handle htonl a bit. Does it work better now? -- Alexandre Julliard julliard(a)winehq.com

April 2, 2003

Re: OSS Bug

by Robert Reif

The problem Rod is seeing is caused by code that I added to check the return value of an ioctl in OSS_RawOpenDevice. The code now checks the return value and returns on failure rather than ignoring it. I don't know if this is a BSD issue or a hardware driver issue or something else. Rod Taylor wrote: > http://bugs.winehq.com/long_list.cgi?buglist=1349 > > I think bug 1349 is related to the below conversation. > > http://www.winehq.com/hypermail/wine-devel/2003/03/0379.html > > Robert Reif suggested I send in a note. > > -- > Rod Taylor <rbt(a)rbt.ca> > > PGP Key: http://www.rbt.ca/rbtpub.asc > > ------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: application/x-unknown-content-type-asc_auto_file > Description: This is a digitally signed message part

April 2, 2003

Re: valgrind for WINE

by Dimitrie O. Paun

On April 1, 2003 02:00 pm, Eric Pouech wrote: > another option would be to embed this support as an option > to the wine script (like --valgrind) This one seems a lot nicer. I can modify winewrap to work with such an option, if need be. -- Dimi.

April 1, 2003