Update: with Alexandre's followup patch, Wine now builds on FreeBSD with
GCC 3.2.x (though with the system compiler we have some problems, but
let's postpone those).
On Thu, 21 Aug 2003, Gerald Pfeifer wrote:
So perhaps we ought to use -lc_r instead of -lc and omit -lpthread on
FreeBSD (or use
When building Wine on FreeBSD with libc_r (r for reentrant) instead of
libc, I now trigger the following FIXME in scheduler/pthread.c:
/* CONDITIONS */
/* not implemented right now */
int __pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *cond_attr)
{
know).
As far as I can see, the ideal approach might be:
o Check whether -lphtread exits/works and use it only, if it does.
o Check whether -lc_r exists/works, and if it does, use that instead
of -lc.
These two are independent, and should work in general, that is, portably.
Gerald
--
Gerald
[ Sorry, I just realized this was in my postponed! Alexandre, this
should have gone out yesterday, sorry. ]
On Wed, 20 Aug 2003, Gerald Pfeifer wrote:
Wine fails to build on FreeBSD 4.8 with the following failure mode:
/usr/bin/gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6
]: *** [glu32.dll.so] Error 1
gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/glu32'
gmake[1]: *** [glu32] Error 2
Gerald
--
Gerald Pfeifer (Jerry) [EMAIL PROTECTED] http://www.pfeifer.com/gerald/
][D3DTSS_ALPHAARG1] == D3DTA_TEXTURE)
( ( oldTxt == NULLpTexture != NULL )
|| ( pTexture == NULLoldTxt != NULL ) ) )
(Personally, I think it's also nicer to omit the parentheses around ==
and !=, but that's a different one.)
Gerald
--
Gerald Pfeifer (Jerry) [EMAIL
On Wed, 9 Jul 2003, Gerald Pfeifer wrote:
So, thanks a lot, Lionel! :-)
And thanks again for yesterday's update!
(There is only a single warning left now: directx.c:779: warning: implicit
declaration of function `glXGetProcAddressARB')
Gerald
--
Gerald Jerry [EMAIL PROTECTED] http
On Mon, 30 Jun 2003, Gerald Pfeifer wrote:
Could someone please have a look at addressing these?
It seems recent patches by Raphaël have fixed all these apart from mere
four:
directx.c:779: warning: implicit declaration of function `glXGetProcAddressARB'
wgl.c:325: warning: implicit
On Wed, 9 Jul 2003, Lionel Ulmer wrote:
It seems recent patches by Raphaël have fixed all these apart from mere
four:
Errrm, I did the changes, not Raphaël :-)
Oops, sorry. So, thanks a lot, Lionel! :-)
But at least these warnings are 'less critical' than the GL ones (where some
functions
As far as I can see, patches from Raphaël resolved many related warnings
I used to see (Thanks!), but using XFree86 4.3 and Mesa 3.4.2 I still get
the following.
Could someone please have a look at addressing these?
directx.c:779: warning: implicit declaration of function `glXGetProcAddressARB'
On Mon, 30 Jun 2003, Lionel Ulmer wrote:
Could someone please have a look at addressing these?
Well, I think the only way to safely remove these are by using
--disable-opengl.
Nah. It works perfectly, without a single warning, once
#define GL_GLEXT_PROTOTYPES
is added, but Raphaël didn't
Is the following warning for dlls/rpcrt4/rpc_server.c
rpc_server.c:133: warning: variable `func' might be clobbered by
`longjmp' or `vfork'
indicative of a real problem, or are we sure that won't cause problems?
(If the latter, is there a way to avoid the
On Fri, 6 Jun 2003, Alexandre Julliard wrote:
There's no reason to change it everywhere, it only needs to be fixed
in exported header files.
Well, but if two of the .c files in programs/notepad use windows.h,
while the other two use windows.h, that certainly is confusing.
And it _had_ confused
On Tue, 17 Jun 2003, Gregory M. Turner wrote:
This patch removes an unused variable introduced by the recent changes
to this file and thus avoids the following warning:
Was going to use that as the user-modifiable buffer for the cabinet name in
the Next Cabinet notification callback, which I
I'm afraid the following change to dlls/dmusic/dmusic_misc.c
revision 1.3
date: 2003/06/13 18:59:51; author: julliard; state: Exp; lines: +113 -9
Raphael Junqueira [EMAIL PROTECTED]
- always use IDirectMusicPerformance8Impl instead of
IDirectMusicPerformanceImpl (as the first
On Sat, 7 Jun 2003, Yorick Hardy wrote:
I guess I broke it, so I should fix it :-). I cannot see that it
would work, but would you mind first trying to include time.h
instead of sys/time.h as pointed out by
http://www.winehq.org/hypermail/wine-devel/2003/05/0732.html
Both including time.h
The following most certainly cannot be right:
% grep windows.h .../wine/programs/notepad/*.c
.../wine/programs/notepad/License_En.c:#include windows.h
.../wine/programs/notepad/dialog.c:#include windows.h
.../wine/programs/notepad/license.c:#include windows.h
On Thu, 5 Jun 2003, Dimitrie O. Paun wrote:
Should be windows.h.
Thanks; I'll submit patches for programs/clock and programs/notepad,
because there I had to debug an annoying problem.
If someone wants to take care of other instances, be my guest. :-)
Gerald
--
Gerald Jerry [EMAIL PROTECTED]
After the recent wave of commits, I'm getting a build failure for the
following line in dlls/d3d8/device.c:
IDirect3DBaseTexture8* cont = NULL;
The failure looks as follows
device.c:1989: syntax error before `*'
device.c:1991: `hr' undeclared (first use in this function)
device.c:1991:
The following change to include/winsock.h
revision 1.59
date: 2003/06/04 20:15:39; author: julliard; state: Exp; lines: +1 -0
Yorick Hardy [EMAIL PROTECTED]
Include sys/time.h for struct timeval definition.
causes compilation failure of programs/notepad:
/sw/gcc-3.2.2/bin/gcc -c
On Wed, 1 Apr 2003, Alexandre Julliard wrote:
I changed the way we handle htonl a bit. Does it work better now?
Yes, thanks a lot! Now it builds, though I'm getting warnings:
In file included from /usr/include/sys/types.h:126,
from ../../include/winsock.h:89,
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 use
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.
On Sat, 15 Mar 2003, Alexandre Julliard wrote:
I added a couple of #ifdefs, it's not really the right solution but it
should hopefully get you going. Let me know if it still doesn't work
for you.
It builds like a charm now, thanks!
The patch below is a most minor followup to avoid (warnings
On Sun, 16 Mar 2003, Dimitrie O. Paun wrote:
+#ifdef SOUND_MIXER_INFO
int mixer;
+#endif
+
Please don't add even more ugly ifdefs just to avoid some warnings.
How else do you suggest we/I detect those code regressions that compiler
warnings indicate?
Some may seem cosmetic, but many of
The following change to dlls/winmm/wineoss/audio.c
revision 1.79
date: 2003/03/15 00:54:12; author: julliard; state: Exp; lines: +231 -73
Robert Reif [EMAIL PROTECTED]
Added support for multiple direct sound devices.
unfortunately breaks compilation on FreeBSD:
audio.c: In function
The following patch
revision 1.76
date: 2003/02/14 23:59:15; author: julliard; state: Exp; lines: +258 -8
Robert Reif [EMAIL PROTECTED]
Started to add support for a real direct sound capture driver.
Changed the capture fragment size but this still needs tuning for best
performance.
Hi,
the following patch to dlls/msvcrt/locale.c
revision 1.15
date: 2003/02/11 22:11:17; author: julliard; state: Exp; lines: +15 -0
Marcus Meissner [EMAIL PROTECTED]
Implemented __crtLCMapStringA.
causes the following warning on FreeBSD 4.7 using GCC 2.95.4:
locale.c: In function
Hi Ove,
I'm now getting the following warnings in ndr_marshall.c, which seem
a bit weird:
ndr_marshall.c:1220: warning: operation on `pMemory' may be undefined
ndr_marshall.c:1223: warning: operation on `pMemory' may be undefined
ndr_marshall.c:1276: warning: operation on `pMemory' may be
We have had some (security-relevant) warning regressions for the following
two programs in tools:
winegcc.o: In function `get_temp_file':
/test/wine/tools/winegcc.c:119: warning: tempnam()
possibly used unsafely; consider using mkstemp()
winewrap.o: In function `main':
On all platforms I have access to (GNU/Linux, FreeBSD) I have been
seeing the following for quite some time now:
../../include/pshpack8.h:47:6: warning: #warning 8 as alignment is not supported
../../include/pshpack8.h:47:6: warning: #warning 8 as alignment is not supported
In dlls/d3d8/device.c I am getting the following warning (on FreeBSD):
/usr/bin/gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -g -O2
-Wall -Wpointer-arith -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__
-D_REENTRANT -o device.o device.c
device.c: In
On Mon, 20 Jan 2003, Raphaël Junqueira wrote:
ddraw/hal.c:152: warning: initialization from incompatible pointer type
can you test this patch (it fix this stupid warning for me)
Yes, thanks; this also fixes this warning for me!
Gerald
--
Gerald Jerry [EMAIL PROTECTED]
On Fri, 27 Dec 2002, Greg Turner wrote:
Here we use off_t (which requires sys/types.h), that's why I wrote
If we really want to use off_t in this file. Should this simply
become cab_off_t?
Bingo. [...] So, yes, this is most certainly an error on my part, and
your fix is likely the correct
On Thu, 26 Dec 2002, Greg Turner wrote:
If we really want to use off_t in this file (instead of cab_off_t)
we need to #include sys/types.h, or we'll break non-Linux systems.
actually I don't think we really want to use off_t. [...]
The easy version of the right fix is probably just to rename
Using GCC 2.95.3 on FreeBSD 4.7 (which has a couple of tests not
usually supported by GCC 2.95) I get a couple of warnings due to
recent changes/additions in Wine; these warnings seem to indicate
real problems:
rtlstr.c: In function `test_RtlInitUnicodeString':
rtlstr.c:110: warning: implicit
On Fri, 27 Dec 2002, Greg Turner wrote:
If we really want to use off_t in this file (instead of cab_off_t)
we need to #include sys/types.h, or we'll break non-Linux systems.
Short to medium term, do you agree with my fix (#include
sys/types.h) so that Wine also builds on non-Linux systems?
On Sat, 7 Dec 2002, Dimitrie O. Paun wrote:
Nevertheless, I will fix this for you.
Thanks a lot!
But I would like to note that an actual patch to fix this problem from
the people that care about it would help a lot more than complaining
about it.
Usually I'd do that (and I've done it a
The following patch broke portability of tools/wrc/wrc.c:
revision 1.18
date: 2002/12/06 19:49:36; author: julliard; state: Exp; lines: +78 -10
Dimitrie O. Paun [EMAIL PROTECTED]
Make wrc command line compatible with windres.
1) getopt() is supposed to to come from unistd.h, and
On Sat, 7 Dec 2002, Dimitrie O. Paun wrote:
2) getopt_long() is non-portable (and does not exist on FreeBSD, for
example).
Sorry, but I don't have *BSD, and I have no idea how you parse long
options on BSD. If you tell me, I'd be happy to oblige.
It's the other way around: Not *BSD needs a
On Fri, 15 Nov 2002, Patrik Stridvall wrote:
Alfred (Cc:ed) verified that these warnings can be eliminated by
o getting rid of the -Wl,-Bsymbolic option (which you probably want
to keep to actually get warnings linking symbols are hosed), or
o explicitly adding -lc.
Would you mind
On Thu, 21 Nov 2002, Alexandre Julliard wrote:
Adding -lc seems the right way. In fact I committed that fix last
night ;-)
Thanks a lot! :-)
On Thu, 21 Nov 2002, Patrik Stridvall wrote:
However, it doesn't seem to be the 100% correct fix.
DLLs using pthreads like the ones depending on OpenGL
When compiling Wine on FreeBSD, there are tons of warnings of the
following kind (and have been that way since I can remember) which
regularily cause confusion and support requests by people building
our port:
/usr/bin/gcc -shared -Wl,-Bsymbolic glu32.spec.oglu.o glu32.dll.dbg.o -o
I'd like to suggest some form of feedback for patches submitted to
wine-patches, which is currently a bit of a black hole.
Some of the patches I sent did not committed (probably because
Alexandre didn't consider the cleanup there worthwhile enough,
which I even could understand):
On Wed, 6 Nov 2002, Dimitrie O. Paun wrote:
This refers to binary packages. I thought FreeBSD usually download
source, is it customary in *BSD world to expect precompiled binaries?
Yeah, at least FreeBSD is that user friendly. ;-)
(I'm not sure this will get through to the list, as I am not subscribed,
so I am Cc:ing you.)
You wrote:
4. Enlist some 'official' distribution maintainers
(at the minimum RedHat, Suse, Mandrake, Debian)
Please also include FreeBSD, and feel free to contact me for
FreeBSD-related issues,
On Sun, 4 Aug 2002, Gerald Pfeifer wrote:
On a SuSE Linux 8.0 box[1] I'm getting the following #warning a few times
while building the current CVS version of Wine:
In file included from alsa.h:23,
from audio.c:46:
/usr/include/sys/asoundlib.h:1: warning: #warning
I am also Cc:ing this patch to wine-devel because I think it shows that
there is an issue that deserves a bit of thought: Code formatting.
We certainly should not get anal rentative on this, but something like
int trn = 1234,i=0;
from files/smb.c where even a single line is inconsistent really
On a SuSE Linux 8.0 box[1] I'm getting the following #warning a few times
while building the current CVS version of Wine:
In file included from alsa.h:23,
from audio.c:46:
/usr/include/sys/asoundlib.h:1: warning: #warning This header is
deprecated, use alsa/asoundlib.h
The following patch has broken configure
revision 1.320
date: 2002/07/19 03:16:51; author: julliard; state: Exp; lines: +210 -80
Gregg Mattinson [EMAIL PROTECTED]
- X11/extensions/shape.h requires X11/Xutil.h.
- X11/XKBlib.h requires X11/Xlib.h.
- net/if.h requires
On Mon, 1 Jul 2002, Francois Gouget wrote:
The bug was in the configure.ac file. Both Marcus and me sent patches
(different approaches ;-) to wine-patches. One of them has to be right
so this should be fixed pretty soon.
Yes, it works fine. Thanks to all that helped in fixing this!
Gerald
[ I'm now also Cc:ing this to the Wine developers, thus the full-quote.
In fact, all non-GLIBC platforms seem to be affected by this bug! ]
Based on your pointer, I believe I found the problem. In aclocal.m4 we
have:
AC_DEFUN([WINE_CHECK_ERRNO],
[AC_CACHE_CHECK([for reentrant libc:
I noticed that in the absence of ~/.wine/config Wine simply refuses to
start, and truss (on FreeBSD) and trace (on GNU/Linux) reveal that no
other location is consulted for a config file.
Even explictly Using ETCDIR or `configure --sysconfdir` doesn't seem to
make a difference, even though the
The following patch to dlls/msvcrt/file.c
revision 1.23
date: 2002/04/26 19:05:16; author: julliard; state: Exp; lines: +4 -0
Better support for configure detection of missing types, added check
for ssize_t.
Removed a couple of no longer used portability functions.
Various
The following patch to wine/debugger/stabs.c breaks FreeBSD:
revision 1.45
date: 2002/04/02 02:38:37; author: julliard; state: Exp; lines: +2 -0
Check ELF signature before processing file.
stabs.c: In function `DEBUG_ProcessElfFile':
stabs.c:1232: `ELFMAG' undeclared (first use in
The following patch breaks building on FreeBSD 4.5:
revision 1.15
date: 2002/04/01 20:56:15; author: julliard; state: Exp; lines: +15 -4
Jukka Heinonen [EMAIL PROTECTED]
Routine DOSVM_Wait now wakes up if new events are queued and it
returns if it processed any queued events.
with
On Tue, 2 Apr 2002, Eric Pouech wrote:
The following patch to wine/debugger/stabs.c breaks FreeBSD:
revision 1.45
date: 2002/04/02 02:38:37; author: julliard; state: Exp; lines: +2 -0
Check ELF signature before processing file.
that should fix it in a portable manner
Thanks! I
dlls/ntdll/cdrom.c revision 1.1 per
date: 2002/01/13 01:44:00; author: julliard; state: Exp;
Eric Pouech [EMAIL PROTECTED]
Changed the Wine internal cdrom interface to the NT model.
causes the following build failure on FreeBSD 4.4 (even though the
code in question is embedded in #elif
revision 1.10
date: 2001/12/04 19:54:45; author: julliard; state: Exp; lines: +41 -60
Moved most of the real-mode stuff to dlls/winedos.
of dlls/winedos/module.c causes the following build failure on FreeBSD 4.4:
/usr/bin/gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall
On Thu, 15 Nov 2001, Francois Gouget wrote:
Yes. This one is actually simple to solve: do not include
'winsock2.h'. AFAICT including 'winsock2.h' is not necessary since 1.66
(2000/08/31) when get_socket_event and FD_MAX_EVENTS where removed.
I am working on the other compilation
In server/thread.h we have a definition of struct thread.
Unfortunately, though, this clashes with struct thread as defined in
/usr/include/sys/thread.h on FreeBSD 5.x and probably other systems
(Solaris) as well.
How should this be addressed? Would any of you mind fixing this? (If it's
okay to
I believe relying on __compar_fn_t in dlls/wineps/afm.c is a Linuxism
recently added to dlls/wineps/afm.c (and only there), Ian.
Given that __compar_fn_t is only used in that single file and nowhere
else, I'd suggest to simply use a typedef of your own instead of the
non-portable __compar_fn_t.
On Fri, 23 Feb 2001, Marcus Meissner wrote:
Why not put them in /usr/lib/wine/ as suggested by the FHS?
That's what I've been doing for the FreeBSD port for ages.
Welcome to the club! :-)
Gerald
--
Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/
On 23 Feb 2001, Alexandre Julliard wrote:
Perhaps just some incomplete #ifdef ... #endif sequence?
Yep, here's a fix:
Index: scheduler/pthread.c
Yes, that fixes it. Thanks!
Gerald
--
Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/
On Fri, 26 Jan 2001, Ove Kaaven wrote:
This report concerns winelauncher. Could Jeremy White or someone else
decide on the best solution?
-- Forwarded message --
Please remove word `function' from line 288 of /usr/bin/wine:
function clean_up_info_message ()
or
On Fri, 19 Jan 2001, John R. Sheets wrote:
The attached patch fixes this problem, but I'm not sure about using
the conditional in documentation/Makefile.in. I'm pretty sure that's
a GNU Make-specific feature (I could be wrong about that, tho).
Then, please don't use it. ;)
Are the Wine
The following change
date: 2001/01/10 23:59:26; author: julliard; state: Exp;
Jon Griffiths [EMAIL PROTECTED]
- Migrate CRTDLL to MSVCRT.
- Many fixes and a load of new functions.
to dlls/msvcrt/math.c (which actually add this file), causes a build
to fail on FreeBSD 4.2:
On Fri, 12 Jan 2001, Gerald Pfeifer wrote:
return num == 0.0 ? _FPCLASS_PZ : (d 0 ? _FPCLASS_NN : _FPCLASS_PN);
Would you (or anyone else) familiar with that code mind having a look?
Well, seems I hit Ctrl-X to fast...
The following patch should fix the bug.
Gerald
ChangeLog:
Fix
On Sun, 31 Dec 2000, James Juran wrote:
I'm using Red Hat 7.0 + gcc update (yes, I know Red Hat shouldn't have
shipped a snapshot release of gcc).
Well, the situation was by far not trivial. Basically, there was no way
for Red Hat to meet all desiderata, so a compromise had to be made.
On Fri, 29 Dec 2000, Marcus Meissner wrote:
The first error I get is the following, though I'm afraid there may
be further ones hidden:
/usr/bin/gcc -shared -Wl,-soname,libkernel32.so
-Wl,-rpath,/usr/local/WINE/lib kernel32.spec.o comm.spec.o
kernel.spec.o stress.spec.o system.spec.o
Current CVS sources cannot be built with BSD make (FreeBSD 4.2) any
longer.
The first error I get is the following, though I'm afraid there may
be further ones hidden:
/usr/bin/gcc -shared -Wl,-soname,libkernel32.so
-Wl,-rpath,/usr/local/WINE/lib kernel32.spec.o comm.spec.o
kernel.spec.o
The following change to library/port.c broke building Wine on FreeBSD 4.2
which, unfortunately, does not have wchar.h yet.
revision 1.7
date: 2000/12/19 04:50:50; author: julliard; state: Exp; lines: +32 -0
François Gouget [EMAIL PROTECTED]
Added better support for Unicode:
Added support for
On Wed, 13 Dec 2000, James Abbatiello wrote:
I had two problems on #WineHQ of gcc 2.91.66 crashing on .spec.c files
Does anybody know what might be wrong for these buggy compilers ?
Yes. Upgrade to a version of the compiler that is (basically) less than
over two years old.
It seems we now require GNU make? With BSD make I get the following build
errors:
/usr/bin/gcc -shared -Wl,-soname,libkernel32.so -Wl,-rpath,/tmp/WINE/lib
kernel32.spec.o comm.spec.o kernel.spec.o stress.spec.o system.spec.o toolhelp.spec.o
windebug.spec.o win87em.spec.o wprocs.spec.o comm.o
On Fri, 8 Dec 2000, Francois Gouget wrote:
The target of Wine is the regular Linux user who still needs a few
Windows applications.
s#Linux user#user of Linux, FreeBSD, or some other Unix-like OS#
(I agree with the rest, but -- while using Linux by myself (among others)
-- I try to reduce
On Fri, 8 Dec 2000, Patrik Stridvall wrote:
What I mean is that a "heuristic" do not cover all strange
cases like normal "algoritms" does and tries to be clever
and make assumptions on how the input usually looks like.
What you seem to miss is that there are many problems where an
optimal
On Wed, 6 Dec 2000, Patrik Stridvall wrote:
I think we have different definitions of heuristics.
Definitely.
But that is not an heuristic. If it it referenced or recusive it is
always correct to not inline it. There is no incorrect cases and
therefore it is not an heuristic it is an
On Wed, 6 Dec 2000, gerard patel wrote:
Also, if anyone interested in gcc documentation is reading this, the
man page for gcc 2.95 don't say anything about this option. It's
documented in the source of course :-)
The man page of GCC is not the correct place to look at:
This man page is
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
So if optimization can't analyze what inline assembler does it
shouldn't do any optimizations that depends on what the assembler
code does.
Can you please provide a minimal example? (I missed the original mail,
but will try to have a look and have
We recently gained a couple of new compiler/linker warnings:
shell32_main.c:361: warning: initialization makes integer from pointer
without a cast
filedlg.c:332: warning: passing arg 1 of `LoadCursorA' makes integer
from pointer without a cast
[ PATCH at the end which I added just before hitting Send... ]
I'm afraid these recent changes to Wine have broken Wine on FreeBSD 4.x
platforms, probably also Solaris:
revision 1.27 date: 2000/11/25 21:39:03; author: julliard
Jon Griffiths [EMAIL PROTECTED]
- Fix ctype(), make is*
On Mon, 13 Nov 2000, gerard patel wrote:
I think that's the relay debugging that is causing this particular
problem. The true problem is not here. I expect that if you don't use
+relay, it will fail on a timed out critical section.
I can confirm that. (Seen with notepad.exe on FreeBSD 4.1 for
On Wed, 1 Nov 2000, Dimitrie O. Paun wrote:
B. Compilers / Runtime
Supported: gcc, cc (solaris) (Patrik?)
Perhaps we also should specify (some) specific versions of GCC which
ought to work?
But before we go into details, do people agree that such a system
would be useful?
Yes, that
I already fixed most bugs shown by compiler warnings added recently. Could
someone please have a look at the following?
disp.rc:42:9: Warning: Usertype uses reserved type-ID 1, which is used by
CURSOR
mouserc.rc:7:9: Warning: Usertype uses reserved type-ID 1, which is used
On Sun, 17 Sep 2000, Ove Kaaven wrote:
While browsing through Debian's bug database on the wine package (for
fun), I happened to come across a user report which seemed to suggest what
the Real Solution (tm) (R) (patent pending) to the long-lasting "libxxx.so
residing in /usr/lib/wine not
On Fri, 15 Sep 2000, Rein Klazes wrote:
Exactly, but according to my knowledge (Steven's Unix Network
Programming) the gethostbyaddr_r() is different on Solaris and other
platforms. Different arguments and so. A bit hard to make a configure
test unles you put your knowledge of platforms in.
On Fri, 15 Sep 2000, Jeremy White wrote:
2. Documentation should be clear (the user should quickly see
the thing that he or she wants, and there should be no confusion
as to which document is 'right')
Sounds good!
4. Switch the FAQ to use a FAQ-O-MATIC, to
Folks,
if I am not mistaken, most of the following compiler warnings (detected
by GCC 2.95.2 on FreeBSD 4.1) are new ones:
internet.c:1402: warning: implicit declaration of function `select'
socket.c:159: warning: unused variable `ifInfo'
snoop.c:127: warning: implicit declaration of function
There is a new build failure on FreeBSD 4.1:
/usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -DWINELIB -D_REENTRANT
-I/usr/X11R6/include -o lex.yy.o lex.yy.c
/usr/bin/gcc -o winedbg winedbg.spec.o break.o db_disasm.o display.o editline.o expr.o
hash.o info.o memory.o module.o
...on FreeBSD 4.0:
revision 1.33
date: 2000/07/29 14:34:45; author: julliard
Ove Kaaven [EMAIL PROTECTED]
Added support for the Win32 Console interface to the main DOSVM event
loop. Cleaned up event dispatching code a bit.
gmake[1]: Entering directory
On Wed, 26 Jul 2000, David Elliott wrote:
Easy in bash:
if /sbin/route -n | grep "^0.0.0.0"
then
echo "Nothin' but 'net"
else
echo "Please connect to the 'net"
fi
Sorry, not all the world is Linux:
gomeisa[53]:~% /sbin/route -n ; uname -rs
/sbin/route: Command not found.
On Tue, 25 Jul 2000, James Hatheway wrote:
I hope this patch fixes compiling of my WsControl/WSAIoctl stuff on
other platforms such as FreeBSD and Solaris. I was wondering if you
guys could try compiling this patch on your respective platforms [...]
Of course! With your patch current CVS
The following change to msdos/dpmi.c
revision 1.37
date: 2000/07/25 12:24:39; author: julliard; state: Exp; lines: +20 -78
Ove Kaaven [EMAIL PROTECTED]
Fixed broken assembler. Removed support for old protected-mode hack
for running real-mode code on platforms that don't support
The following patch to dlls/winsock/socket.c broke compilation on FreeBSD
and probably all other non-Linux targets:
revision 1.21
date: 2000/07/23 19:28:24; author: julliard; state: Exp; lines: +285 -0
Adds an initial WSAIoctl function with support for only the
SIO_GET_INTERFACE_LIST
On Mon, 24 Jul 2000, James Hatheway wrote:
Unfortunately I don't have access to other build environments such as
FreeBSD, Solaris, etc.
If you're interested, we surely can arrange for an account on a FreeBSD
box somehow! ;-)
So I will ask Alexandre to please retract my patch from CVS, and I
On Mon, 24 Jul 2000, Gerald Pfeifer wrote:
dlls/wsock32/socket.c, we'll have to investigate...
Actually, there are two problems with that: The real one (concerning
system structures) and the use of ulong which is not defined on FreeBSD:
In file included from ./socket.c:14:
wscontrol.h:26
On Mon, 24 Jul 2000, Josef Wegner wrote:
I have solved this problem by compiling the regapi_spec.c file by hand
without the -O2 flag. Looks like a egcs bug...
Please note that you are using an old version of the compiler. Please
upgrade to GCC 2.95.2, our official release; if the problem
On Thu, 20 Jul 2000, David Elliott wrote:
If you guys had checked the discussion on this two days ago between
Lionel and I, you would have noticed it's already been fixed, grab the
three files Wine needs out of XF 4.0.1 since the 4.0 ones are
technically broken anyway.
It's not that easy!
During `make install` with BSD make (instead of GNU make) I get the
following error:
cd `dirname tools/__install__` make install
cd `dirname cvdump/__install__` make install
make: don't know how to make install. Stop
*** Error code 2
What's the correct fix here?
a) Remove cvdump
On Wed, 14 Jun 2000, Jim Graham wrote:
2.) Given the above idea, we then create a graphical configuration
tool (or simply extend TkWineSetup) so that we can build a complete
.winerc file that includes all possible options available to Wine.
This tool would also have help and explanations
1 - 100 of 106 matches
Mail list logo
