> "Paul" == Paul McNett <[EMAIL PROTECTED]> writes:
Paul> I crash when building an EXE in the new version of Visual Foxpro.
Paul> Any ideas? "windows" = "nt351", all dlls built-in. Here's the
Paul> output leading up to the crash:
Paul> fixme:hook:NotifyWinEvent (32769,0x5003
"Kevin DeKorte" <[EMAIL PROTECTED]> wrote:
> RedHat 8.0 up2date with glibc-2.3.2-4.80
>
> Wine compiles fine, no extra options are needed. But if wine has been built
> on the RedHat 8.0 OTB, then you should download a clean source tarball or if
> you use CVS, you should delete your working dir
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 .
--
s in ${WINEDIR}/dlls to
add a "lib" prefix, vis:
$ ( cd ${WINEDIR}/dlls ; ls -l *ntdll.dll* )
lrwxrwxrwx1 kevin18 Apr 1 15:29 ntdll.dll.so -> ntdll/ntdll.dll.so
lrwxrwxrwx1 kevin18 Apr 1 15:29 libntdll.dll.so -> ntdll/ntdll.dll.so
$
That keeps configure happy
Francois Gouget <[EMAIL PROTECTED]> 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, wh
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.
On 1 Apr 2003, Alexandre Julliard wrote:
> "Dimitrie O. Paun" <[EMAIL PROTECTED]> 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 wi
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 . Actually I think it would be
better if we appended the 'Why Wine is important' section to it.
>
Gerald Pfeifer <[EMAIL PROTECTED]> 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 probl
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.
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 wr
Alexandre,
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.
/usr/bin/gcc -c -I. -I. -I../
Andreas Mohr <[EMAIL PROTECTED]> writes:
> [I don't know why this wasn't applied, without any comment;
> resending it]
You don't really expect me to apply a patch that adds a #ifdef
FUBAR_CODE, do you?
--
Alexandre Julliard
[EMAIL PROTECTED]
I crash when building an EXE in the new version of Visual Foxpro. Any ideas?
"windows" = "nt351", all dlls built-in. Here's the output leading up to the crash:
fixme:hook:NotifyWinEvent (32769,0x50032,1,0)-stub!
fixme:pidl:SHLogILFromFSIL (pidl=0x4032b090)
fixme:dc:LockWindowUpdate (0x50033), p
I will try to fix this sometime in the next week, depending on whether I
can get CVS access to take advantage of the work Eric Pouech has done.
>>> Alexandre Julliard <[EMAIL PROTECTED]> 03/28/03 01:56 AM >>>
"Robert Shearman" <[EMAIL PROTECTED]> writes:
> +static int io_completion_send_data( str
Adam Gundy <[EMAIL PROTECTED]> writes:
> a new version of the valgrind patch has been uploaded to sourceforge -
> the only change is a small fix to the signal handling which should
> prevent "signal handler frame" uninitialized errors.
>
>
> http://sourceforge.net/tracker/index.php?func=detail
Alexandre Julliard wrote:
The winsock.h issues should hopefully be fixed now. I'm not sure we
should disable 16-bit code by default, you will want to support that
at some point.
I added a fix for that, hope it will work. The ultimate goal is to use
winegcc etc. in the Wine build process, so it's b
"Dimitrie O. Paun" <[EMAIL PROTECTED]> 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.
--
Alexandre Julliard
[EMAIL PROTECTED]
On 1 Apr 2003, Alexandre Julliard wrote:
> If they link with msvcrt then they are not supposed to use
> wine/port.h. To avoid trouble with process.c I'd suggest naming the
> function spawnvp, without the underscore prefix, and making it call
> the real _spawnvp on Windows.
Cool. Here it is again.
Adam Gundy wrote:
a new version of the valgrind patch has been uploaded to sourceforge -
the only change is a small fix to the signal handling which should
prevent "signal handler frame" uninitialized errors.
http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46268&atid=4455
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> OK, here's a patch to add _spawnvp to the portability lib. There
> are still a few questions:
> -- Should we provide the entire family (I wouldn't, unless we
> really need them, but that can wait for that need :))?
Yep that can wait.
> --
On 1 Apr 2003, Alexandre Julliard wrote:
> It's needed for out of tree builds, in that case the include paths are
> all different.
True, but why do we need the -I.? Do we need to ever include anything
from the current build dir?
--
Dimi.
Rolf Kalbermatter <[EMAIL PROTECTED]> writes:
> While downloading and compiling the latest CVS sources I noticed that the
> command line for each (most?) source files reads like
>
> gcc -c -I. -I. -I../../include -I../../include . or similar
>
> This is not a serious problem but the
> "BiGgUn" == BiGgUn <[EMAIL PROTECTED]> writes:
BiGgUn> How can you know which version of Windows, WIne is currently
BiGgUn> emulating ? Thanks in advance. Stephan
One posinility is a call to GetVersion().
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphys
> RedHat 9
>
> You need to set the environment variable LD_ASSUME_KERNEL=2.2.5 in the
shell
> prior to running configure and prior to running wine.
>
after installing i suggest to add the line in your winelauncher script
(/usr/local/bin/winelauncher) and to launch associate the .exe extension
with
While downloading and compiling the latest CVS sources I noticed that the
command line for each (most?) source files reads like
gcc -c -I. -I. -I../../include -I../../include . or similar
This is not a serious problem but the duplication of the two include parameters
strikes me as odd
How can you know which version of Windows, WIne is currently emulating ?
Thanks in advance. Stephan
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 <[EMAIL PROTECTED]>
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
I have some RedHat Notes
RedHat 8.0 out of the box
Wine compiles fine, no extra options are needed
RedHat 8.0 up2date with glibc-2.3.2-4.80
Wine compiles fine, no extra options are needed. But if wine has been built
on the RedHat 8.0 OTB, then you should download a clean s
On March 31, 2003 11:31 pm, Alexandre Julliard wrote:
> Yes, it's just that I don't like to add non-Unix APIs to the
> portability layer, but I guess there are good reasons for making
> an exception here.
I agree -- adding non-Unix APIs is not a good idea. 100% with you.
But this one is one partic
On Wed, 26 Mar 2003, Eric Pouech wrote:
> Alexandre Julliard wrote:
>> I think the code is wrong, we shouldn't store a Linux-only define in a
>> Windows structure, we should use a Windows define. Any one knows what
>> the right value should be?
> the code is wrong (evil cut & paste IMO). we should
Hi,
As we've been getting quite a few reports of glibc 2.3.x related
failures in bugzilla lately, it makes sense to mark them as dupes of a
bug, so I've started duping them against bug #1343
http://bugs.winehq.com/show_bug.cgi?id=1343
That way, when these problems are sorted out, we won't have t
> FWIW, my problem is the oft-asked "How do I call functions in a Windows
> DLL from an ELF process?" I appreciate WineLib is an option, and have
> run into a number of snarls along that path:
Well, see me discussing that with Bill a few days ago on the mailing
list archives. Basically you have t
33 matches
Mail list logo
