yout/index.php?title=VirusDB
> */
>
>
>
> On Mon, Sep 23, 2013 at 1:20 PM, Dan Kegel wrote:
>>
>> Fun times:
>> http://bugs.winehq.org/show_bug.cgi?id=34556
>>
>>
>
Fun times:
http://bugs.winehq.org/show_bug.cgi?id=34556
Damian wrote:
> 1) ATI or nVidia for new GPU? Does SLI/Crossfire work with wine?
Don't know. I just use nvidia cards I find in the trash :-) But then
I don't actually play games, so I don't care about 3d performance.
> 2) FX 8320 or intel same price class CPU? As the AMD has far inferior
> sing
t to avoid
overloading the
databases if you try.
On Sun, Aug 18, 2013 at 12:11 PM, Rosanne DiMesio wrote:
> Dan,
>
> I don't know if you've been following the "PLEASE add bug links!" thread on
> wine-devel, so I figured I'd just contact you directly. Do you remembe
Minor problem:
+static void test_strncpy(void)
+{
+size_t len = 10;
+char *ret;
+char dst[len + 1];
Hmm. That last line is a VLA, and might not compile in all C
compilers because it's not allowed in C89.
http://stackoverflow.com/questions/448844/variable-sized-arrays-in-c
Wine seems
tion due to the nature of the app.
I think there have been several such compatibility layers.
http://chiharu.haun.org/peace/ for instance.
Wine's the only one that has really tried tor run everything.
Why can't you just bundle wine?
- Dan
Or run
https://winezeug.googlecode.com/svn/trunk/install-addons.sh
Watch http://source.winehq.org/patches/
for your patch's status (see legend at bottom).
It might be rejected since it doesn't actually fix any behavioral
problem in Wine.
IIRC trivial cleanups in code are frowned upon, especially if
they cross many modules. Better to pick some small
real problem
http://bugs.winehq.org/show_bug.cgi?id=22280 just got another dup.
How awful would it be to make SetThreadPriorityBoost just
return success, as in the patch attached to
http://bugs.winehq.org/show_bug.cgi?id=22280#c1
http://bugs.winehq.org/attachment.cgi?id=27224&action=diff&context=patch&collap
Thanks. I saw the 'doesn't apply' status at
source.winehq.org/patches, so was going to take another look tonight.
On Mon, Apr 22, 2013 at 4:40 PM, James Eder wrote:
> Dan, the patch doesn't build for 64-bit Wine. On the #else side you have
> an unwanted semicolon.
>
> --
> Jim
Hi Anulesh,
improving wine's support of cygwin is a toughie.
( I gave http://bugs.winehq.org/show_bug.cgi?id=15679 the old college
try, but failed. )
You should probably be more specific about what you have in mind.
- Dan
mooth your way:
There is a lot of bison in wine already, so using bison might be the
path of least resistance.
Switching just one command to bison, while leaving the rest using the
existing code,
would likely be much easier to get committed than a big patch that
changed lots of things.
Good luck!
- Dan
On Fri, Apr 19, 2013 at 10:38 AM, Dan Kegel wrote:
> Hooking is a fragile business. Somebody somewhere is probably
> making assumptions about how hooking works (like, how many stack
> frames are pushed), and inlining call_hook_proc probably violates one
> of those assumptions.
Tha
proc is probably the only function whose inlining matters
for this problem (since my patch solved your problem at -O2).
(inline is only a hint. FORCEINLINE is stronger.)
- Dan
I suspect this is a real fix, and there is no gcc bug.
On Fri, Apr 19, 2013 at 9:47 AM, Qian Hong wrote:
> Hi Dan,
>
> Thanks for working on it! It is really an annoying bug, however, is
> adding DECLSPEC_NOINLINE a workaround or a real fix? If it is only a
> workaround, would
OK, thanks.
On Fri, Apr 5, 2013 at 7:45 AM, André Hentschel wrote:
> Hi Dan,
> i just removed your gsoc idea and i want to let you know why. There was a
> quite short discussion on IRC:
>
> Andre_H_laptop: austin_laptop: Dan added a quite controversal gsoc idea...
> afaik
I had a look at a couple warnings, e.g.
file:///home/dank/Downloads/scan-build-2012-12-18-1/report-z07lcL.html#EndPath
file:///home/dank/Downloads/scan-build-2012-12-18-1/report-9D2p5I.html#EndPath
They're hard to follow, but mostly look like garbage :-( Too bad
there's no web interface for marki
Henri wrote:
>+/* Recent (304.64, possibly earlier) versions of the nvidia driver only
>+ * report a DFP's native mode through RandR 1.2 / 1.3. Standard DMT modes
>+ * are only listed through RandR 1.0 / 1.1. This is completely useless,
>+ * but NVIDIA considers this a feature, so i
On Sat, Nov 17, 2012 at 1:34 PM, Dan Kegel wrote:
> $ git clone https://source.winehq.org/git/wine.git newwine-git
> Cloning into 'newwine-git'...
> error: server certificate verification failed. CAfile:
> /etc/ssl/certs/ca-certificates.crt CRLfile: none w
$ git clone https://source.winehq.org/git/wine.git newwine-git
Cloning into 'newwine-git'...
error: server certificate verification failed. CAfile:
/etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing
https://source.winehq.org/git/wine.git/info/refs
Maybe that's related to the big fat
After gstreamer, gcrypt is also dropping support for alternative
thread libraries.
Good thing secur32/schannel_gnutls.c doesn't use it. (Right?)
- Dan
-- Forwarded message --
From: Werner Koch
Date: Wed, Nov 7, 2012 at 1:31 AM
Subject: Re: Bug#566351: libgcrypt11: shoul
Which game were you testing?
lution.
vmware seems to work, though I haven't tried it myself yet:
http://lsimons.wordpress.com/2011/06/02/libvirt-vmware-fusion-mac-os-x/
- Dan
On Wed, Oct 24, 2012 at 5:38 AM, Alexandre Julliard wrote:
> What I'm actually saying is that you should stop playing games with the
> compiler and implement this in assembler...
Thanks for the cleartext.
ative offsets in the x86 and x64 assembly code by one pointer unit.
I don't think it's that complicated.
Here's a draft that does what Alexandre suggests.
It seems fine to me and to Daniel Lehman, and I was about to
submit it when I got Jörg's reply.
- Dan
0001-vcomp-single-threaded-implementation-of-_vcomp_fork.patch
Description: Binary data
Christian Costa wrote:
...
--- a/programs/services/rpc.c
+++ b/programs/services/rpc.c
...
@@ -952,7 +952,7 @@ BOOL service_send_command( struct service_entry
*service, HANDLE pipe,
}
r = GetOverlappedResult( pipe, &overlapped, &count, FALSE );
}
-if (!r || count != sizeo
like it makes sense to add as many tests as possible before
refactoring, but if they're messy to submit without also fixing the
problems they find, go ahead and keep them local for now...
just don't forget to submit them asap.
I must say, it's awesome how you're tearing into the cmd problems!
- Dan
ackground to recognize a situation that might be
> troublesome. I think this could be one of those situations and I have
> urged AJ to consult a real expert on the subject.
I believe he has already, and is quite well informed on the legal issues.
- Dan
In general, patches to wine should have some
demonstrated benefit, either by increasing the
number of passing conformance tests, or by
making some app work better, or both.
Your current patch doesn't seem to do either of these things.
Getting into a pissing match with AJ about patent
and copyrigh
New draft at
https://testbot.winehq.org/JobDetails.pl?Key=22035
(the testbot seems stuck... Maarten, does it need a kick?)
Thanks to Maarten for getting me to try C varargs again;
the first assembly function is now gone.
I've also added comments that explain the vcomp execution
model, I hope that
typelib.c
> Does this help?
Yes, your questions are very helpful. I'll run the next draft by both
you and Maarten if you don't mind.
- Dan
send him a new draft for private review.
- Dan
As you might know from watching too many of my patches
scroll by, I've been working on adding support
for OpenMP to wine. (A handful of games, and a lot
of serious apps, seem to use that api.) After getting
it nicely organized and cleaned up to the point where it
passed all the tests I could thro
want to find a more solid fix for your first submission.
Welcome, and good luck!
- Dan
On Fri, Sep 7, 2012 at 7:21 AM, Dan Kegel wrote:
> As I mentioned earlier, the testbot can't handle vcomp.dll tests
> until a fix for http://bugs.winehq.org/show_bug.cgi?id=31609
> is deployed.
>
> It can handle vcomp100.dll tests, though (no manifest). I guess I can submi
As I mentioned earlier, the testbot can't handle vcomp.dll tests
until a fix for http://bugs.winehq.org/show_bug.cgi?id=31609
is deployed.
It can handle vcomp100.dll tests, though (no manifest). I guess I can submit
the series again with the vcomp100 forwarding and tests
in a sixth patch, that wo
On Tue, Sep 4, 2012 at 3:18 PM, Francois Gouget wrote:
>> (But as it turns out, the code I needed to fix was in buildbot,
>> not winetest.)
>
> Maybe the WineTestBot code needs a similar fix?
> In testbot/src/TestLauncher/TestLauncher.c?
Yeah, um, ^buildbot^testbot
I have a patch at
http://bugs.w
ree for building the tests.
> Just have mingw32 installed, run ./configure, then 'make crosstest'.
I've done 'make crosstest' many times, but building winetest.exe itself
does seem to require the two trees as described by that page.
(But as it turns out, the code I needed to fix was in buildbot,
not winetest.)
- Dan
On Sun, Sep 2, 2012 at 1:14 PM, Dan Kegel wrote:
> On Wed, Aug 8, 2012 at 7:27 AM, Dan Kegel wrote:
>> Testing vcomp100 does work, but I shouldn't need to
>> do that until there's some vcomp100-specific code.
>>
>> msvcr90/tests just adds a manifest, an
testbot
doesn't think vcomp.dll is installed.
( cf. http://www.winehq.org/pipermail/wine-devel/2012-August/096642.html )
- Dan
On Wed, Aug 8, 2012 at 7:27 AM, Dan Kegel wrote:
> Testing vcomp100 does work, but I shouldn't need to
> do that until there's some vcomp100-specific code.
>
> msvcr90/tests just adds a manifest, and that works.
Heh. It does add a manifest, but I don't think it works.
Alexandre Julliard wrote:
> Explicit ok() calls are better than hiding them inside a macro.
Uh-oh. Want me to get rid of this macro
+#define CHECK_RET_ERRNO(ret, ex) \
+do { \
+ok(ret == ex, "ret is %d, expected %d\n", ret, ex); \
+ok(errno == ex, "errno is %d, expected %d\n"
On Sun, Aug 26, 2012 at 1:29 AM, Alexandre Julliard wrote:
>> But msvcr100's wmemmove_s/wmemcpy_s are different; they
>> do not change errno. Tests in my patch confirm this.
>
> They do set errno, the tests are broken.
Aw, foo. Thanks, resent with fixes.
I asked Alexandre what
http://source.winehq.org/patches/data/88732
needed before it could be reviewed. He said it needed to adapt
to the recent parameter checking changes. I see that
when he took my patch
http://www.winehq.org/pipermail/wine-patches/attachments/20120728/bea2581d/attachment.obj
an
Using varargs like Andre tried doesn't work because pushing a va_list
isn't the same as pushing a list of arguments.
So I think we need assembly. The assembly I gave earlier is wrong
because it cleans up the stack, which it's not allowed to do.
I've attached an updated patch to
http://bugs.winehq.
On Fri, Aug 10, 2012 at 7:37 PM, Dan Kegel wrote:
> Yes indeed, this works:
>
> extern void WINAPIV VCOMP__vcomp_fork(DWORD parallel, int ncount, void
> (__cdecl *helper)(__ms_va_list), ...);
> __ASM_GLOBAL_FUNC( VCOMP__vcomp_fork,
>"pop %eax\n\t&qu
Yes indeed, this works:
extern void WINAPIV VCOMP__vcomp_fork(DWORD parallel, int ncount, void
(__cdecl *helper)(__ms_va_list), ...);
__ASM_GLOBAL_FUNC( VCOMP__vcomp_fork,
"pop %eax\n\t" /* save return address */
"add $8,%esp\n\t"/* skip para
Yeah, it might be as simple as
_vcomp_vfork proc
add sp,4 ; skip parallel flag and arg count
ret ; jump to helper function, leaving its args on stack
or something like that.
I guess I should fire up a debugger and see what's going
on, but I don't want to accidentally see too much about
what native's doing.
Suggestions, anyone?
- Dan
Andre wrote:
> i'd something like in my attachment
Sorry, I should have linked to
http://testbot.winehq.org/JobDetails.pl?Key=20684
where I verified that testing vcomp100 did indeed work around the problem.
I guess that's where I'll put the tests until somebody hits me with a cluestick.
Testing vcomp100 does work, but I shouldn't need to
do that until there's some vcomp100-specific code.
msvcr90/tests just adds a manifest, and that works.
On Mon, Aug 6, 2012 at 8:47 AM, Dan Kegel wrote:
> On Mon, Aug 6, 2012 at 8:28 AM, Dan Kegel wrote:
>> Is vcomp{,90,100}.dll not installed by default on Windows?
>> If not, should we install it on a few of the VMs?
>
> Nevermind for the moment, I probably have a manifest p
On Mon, Aug 6, 2012 at 8:28 AM, Dan Kegel wrote:
> Is vcomp{,90,100}.dll not installed by default on Windows?
> If not, should we install it on a few of the VMs?
Nevermind for the moment, I probably have a manifest problem.
I'm trying to test a better set of stubs for vcomp.dll and its ilk,
but those dlls don't seem to be installed on testbot.
Is vcomp{,90,100}.dll not installed by default on Windows?
If not, should we install it on a few of the VMs?
I just ran into a CAD app whose 64 bit version runs better than its 32
bit version on Wine
(the 32 bit version hangs with http://bugs.winehq.org/show_bug.cgi?id=31358
but the 64 bit version gets past that and seems to actually do something).
Not very important, but kind of cool.
I'm running into a similar problem,
http://bugs.winehq.org/show_bug.cgi?id=23058
If you're using a different activex control,
please file a new bug, with a way
for others to reproduce the problem.
Any chance you could add an HTML5 mode?
http://praegnanz.de/html5video/
shows a bunch of HTML5 video
On Thu, Jul 26, 2012 at 5:54 AM, Dan Kegel wrote:
> On Tue, Jan 10, 2012 at 2:58 PM, Pau Garcia i Quiles
> wrote:
D'oh! Looks like I was fooled by a long-delayed message delivery. The
message I replied to is from *six months* ago. I've gotten several
of those from winehq in
been involved in several efforts to use wine in commercial products,
I might be able to put something together.
At the very least, I should update http://kegel.com/wine/isv/ a bit more.
- Dan
n you have a look at http://source.winehq.org/patches/data/88600 ?
It and the bug it points to, http://bugs.winehq.org/show_bug.cgi?id=27698 ,
should have an adequate explanation of what the class is there for.
- Dan
Groveling around, I found a few possibilities:
backtraces broken on gcc 4.7
http://bugs.winehq.org/show_bug.cgi?id=26791
ICE when compiling:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641056
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640864
https://bugs.launchpad.net/ubuntu/+source/gc
On Mon, Jul 23, 2012 at 8:33 AM, Alexandre Julliard wrote:
>>> You shouldn't need to put that in msvcrt.
>>
>> OK, I'll put it in msvcr90.
>
> It's not supposed to be there either.
Maybe I was grepping without the w prefix by accident, sorry.
I see now it's only in msvcr100.
- Dan
On Mon, Jul 23, 2012 at 5:56 AM, Alexandre Julliard wrote:
> You shouldn't need to put that in msvcrt.
OK, I'll put it in msvcr90.
> Also please check the parameters correctly like every other _s function does.
The wmemmove_s/wmemcpy_s I posted are exact copies of the existing
non-w implementat
"Initial checkin of afxapi, a class library aiming to provide
source-level compatibility with MFC."
http://www.openwatcom.org:4000/@md=d&cd=//depot/openwatcom/bld/afxapi/include/&cdf=//depot/openwatcom/bld/afxapi/include/afxcmn4.mnl&ra=s&rc=s&c=3Z1@/36051?ac=10
Wonder how that's going.
Piotr, can you review this, please? I've only tested this with two
apps on 32 bits,
I have not tested at all on 64 bits, and am only guessing on the
calling convention stuff.
Seems to fix http://bugs.winehq.org/show_bug.cgi?id=27698 for
Harvest and one other app (I can't reproduce the problem wit
Daniel Lehman wrote:
@@ -1949,7 +1949,7 @@ basic_string_char* __thiscall
basic_string_char_replace_cstr_len(basic_string_ch
-if(off+len > this->size)
+if(off+len < off || off+len > this->size)
len = this->size-off;
Wouldn't this be more elegant:
if(num > this->size-pos)
> Is it worth for working on patches for these issues, or is this
> completely impossible with the current architecture?
Do you know yet why no symlink is made
in dosdevices for /media/-?
I haven't heard any rumblings about the current architecture
being hopelessly broken.
960%28v=vs.85%29.aspx#_win32_Open_and_Save_As_Dialog_Box_Customization
> ?
Yeah, hooking was on my list of things to try, maybe I can intercept
the items as they're added to the listbox...
Thanks,
Dan
I'm creating a page of tips at
http://wiki.winehq.org/DisplayingUnixFilenames
for vendors shipping Windows apps on Linux with Wine
who want their apps to use Windows paths throughout
internally, but display Linux paths in the GUI
This is something I've been meaning to do ever since I helped port P
folks seen
>> this?
>
> This should be fixed by 45473a65a0a1fe2e61809d80f6d09bb96f923126.
Indeed it is. Thanks!
- Dan
No objection here. Seems like an obvious thing to do. I'll do it
later today if nobody objects.
/System.EnterpriseServices.Wrapper.dll
Not sure how serious it is that that's misplaced. Have other folks seen this?
- Dan
hile it was
running, and
you can run just the known good or known bad tests with
https://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests.sh
but that's overkill (or underkill) for you, and slightly out of date anyway.)
- Dan
xing.
On an administrivial note, you should send one patch per
email to wine-patches.
Do you think you could write a test that (semi-)reliably
causes the deadlock you're fixing?
> The patches have been tested by Dan Kegel (in CC) and are currently
> being used by many MacOSX and Linux users to r
On Mon, Jul 2, 2012 at 2:51 AM, Piotr Caban wrote:
> This patch looks correct. It's also good to fix other functions with similar
> bug.
Great, I'll have a bigger patchset for review in a few days.
Thanks,
Dan
I can add the fix and test for msvcp60 as well.
Thanks for all your hard work!
- Dan
Henri wrote:
-hr = wined3d_device_get_display_mode(ddraw->wined3d_device, 0, &mode);
-if (FAILED(hr))
+if (FAILED(hr = wined3d_get_adapter_display_mode(ddraw->wined3d,
WINED3DADAPTER_DEFAULT, &mode)))
Seems like a step back in readability to combine setting and testing hr.
- Dan
AJ sometimes kindly fixes problems in patches
while committing them (I guess it's easier than
rejecting the patch for small issues).
I wonder if these silent improvements would
be worth collecting as a sort of style-guide-by-example.
Anyone remember any good examples?
I've started a list at
http:/
Nozomi wrote:
+for (i = 0; i < order * order; i++)
I might have written
int n = order * order;
for (i=0; i < n; i++)
to avoid repeating the multiplication every time around the loop,
even though multiplication is cheap nowadays, and -O1 will optimize
it out anyway. Staying in the h
said,
the app developer will probably fix his (very old) bug now
that I've pointed it out.
- Dan
In at least one app, the hotkey control doesn't draw itself.
Invalidating its own window during HOTKEY_Paint gets the
control to draw properly, and makes the app happy.
Fixes http://bugs.winehq.org/show_bug.cgi?id=30486
(Unlike the patch attached to that bug, this one doesn't
also ask the backgrou
then we could get rid of all the defined()
calls, and the compiler could tell us when we'd misspelled a HAVE_XXX.
Oh, well.
- Dan
On Fri, Jun 8, 2012 at 11:51 AM, Francois Gouget wrote:
> On Fri, 8 Jun 2012, Dan Kegel wrote:
>> Isn't this a no-op? I thought that an undefined symbol was
>> treated as false by the preprocessor.
>
> Actually you may be right. But then this is the only place in Wine w
-#elif defined(HAVE_SYS_SYSCTL_H) && defined(IPCTL_STATS) &&
(HAVE_STRUCT_IPSTAT_IPS_TOTAL || HAVE_STRUCT_IP_STATS_IPS_TOTAL)
+#elif defined(HAVE_SYS_SYSCTL_H) && defined(IPCTL_STATS) &&
(defined(HAVE_STRUCT_IPSTAT_IPS_TOTAL) ||
defined(HAVE_STRUCT_IP_STATS_IPS_TOTAL))
Isn't this a no-op? I thoug
e http://source.winehq.org/source/programs/notepad/main.c#L616 ).
So, no, Wine doesn't translate arguments for you.
> FWIW the Windows app launches perfectly if I use execl() in the Linux app -
> and in fact, this has all worked perfectly for years.
That's great. Do you actually pass filenames?
- Dan
where I had to put the
commandline in a batch file and do
wine cmd.exe /c foo.bat
because there wasn't another other way to make the windows app
happy... something about the commandline that made me need
to use CreateProcess, and cmd.exe was the easiest way to use CreateProcess.
- Dan
install it again. (Until it's updated, anyway.)
- Dan
isn't really an
issue. From the user's point of view, having a single script to
get rid of all the !#&# download prompts is ideal, and splitting
it would add complexity.
- Dan
On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy
wrote:
> On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel wrote:
>> http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh now
>> also installs mono. ...
>
> Wouldn't it be better (and more acceptable for people
&g
..@humblebundle.com with any issues
and we'll make sure CodeWeavers hears about any LIMBO bugs that need
fixing.
-- snip --
So, no, they don't require games to be native, they just require them
to run well.
Regardless of whether a game is native, Java, or Wine,
it's going to run into some problems post-release,
and good game publishers will respond with fixes.
- Dan
Berillions wrote:
> the other petition does have a point about Wine not doing as well with
> sound as it should.
Yes, there are some issues.
For the record, here are a couple links to people talking about their
problems with the game:
http://askubuntu.com/questions/144915/limbo-game-has-no-sound
http://www.ipetitions.com/petition/use-wine-as-needed-in-future-humble-indie-bundles/
How's that look? If you agree with it, please sign and forward to your friends.
Thanks,
Dan
http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh now
also installs mono.
It should be probably be called wine-install-addons.sh now, maybe
I'll rename it that soon. If you have a better idea for the name,
let me know.
(I've also deprecated the copy that was in winezeug; that one n
On Wed, May 16, 2012 at 3:24 PM, Dan Kegel wrote:
> wget
> http://download.microsoft.com/download/3/2/2/3224B87F-CFA0-4E70-BDA3-3DE650EFEBA5/vcredist_x64.exe
> wine vcredist_x64
> installs fine... but only puts anything in c:\windows\syswow64,
And the things it puts there are
I'd like to try a real 64 bit app, so on a 64 bit Ubuntu 12.04, I tried
sudo apt-get install wine
rm -rf ~/.wine
export WINEARCH=win64
wget
http://download.microsoft.com/download/3/2/2/3224B87F-CFA0-4E70-BDA3-3DE650EFEBA5/vcredist_x64.exe
wine vcredist_x64
and that installs fine... but o
On Wed, May 16, 2012 at 1:50 PM, Alexey Loukianov wrote:
>> Really? IMHO they should still be silver. Patches are very hard for the
>> average user to deploy without a third party front end like POL, and appdb
>> is not about POL. - Dan
>
> I thinks that using silv
hard for the
average user to deploy without a third party front end like POL,
and appdb is not about POL.
- Dan
ake sure there's a "purist" bug
in wine's bugzilla describing what breaks if you force
wine to use its own builtin DLL for the game.
(And should then try to fix that bug. :-)
- Dan
I suspect most people don't use IDEs with wine.
Someone recently posted how to use eclipse during debugging, though:
http://www.winehq.org/pipermail/wine-devel/2012-April/095162.html
add it both ways, though,
so I wonder how the version without the asterisk got there.
Starting from a clean wineprefix should keep you from having multiple
entries. Does it?
That should be fine for the intended audience.
I've updated winetricks (r813) to add all missing dlls and
added a comment explaining how the list was generated.
Thanks,
Dan
What's the standard procedure for building both 32 and 64
bit wine together on Ubuntu 12.10?
Sadly, it seems you can't install both 32 and 64 bit development
files at the same time.
And trying to use a 32 bit chroot is awkward because wine's build
system tries to use the 64 bit makedep from inside
1 - 100 of 3082 matches
Mail list logo
