Martin Bochnig
2007-Jan-04 18:50 UTC
[qemu-discuss] Hi: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin
²Š'
Martin Bochnig
2007-Jan-05 12:53 UTC
[qemu-discuss] Re: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin
Martin Bochnig wrote:>soon > > >(Sorry for cross-posting, but too many people are waiting for one or another thing.) Merging several small and bigger diffs into the CVS was not so much of a problem. But they at qemu (i.e. Thiemo Seufer) have professionally reimplemented DMA support into hw/ide.c and hw/dma.c , rather than just using the working solution Juergen Keil has written. Using the default dma.c and ide.c breaks DMA support for Solaris guests once again. One gets the best results for Solaris-guest dma-support, when simpliy using the old Solaris-patched ide.c and dma.c from http://www.martux.org/qemu/RELEASES/sparc/qemu-0.8.2__default_FabriceB__versus__qemu-0.8.2-solaris__20061013fri__MB.gdiff or http://opensolaris.org/os/project/qemu/downloads/qemu-0.8.2-solaris_src_20061013fri.tar.bz2 However: cdrom support is currently completely broken for Win9x guests, no matter whether I use Oct14''s patched ide.c/dma.c, unpatched cvs20070102tue ones, or patched cvs20070102tue ones with the old JuergenKeil-written code merged into as best as now possible. Unfortunately doesn''t it core dump - it just doesn''t work. Ben Taylor is also "unimpressed" by the current cvs. Problem: I cannot exclusively offer something that broken as SUNWqemu packages. I will therefore have to offer experimental cvs20070102tue packages for sparc and x86/x64 *plus* mature and 99% stable updated (i.e. Juergen Keil''s Info patch, Sittichai''s Tunnel patches etc. etc.) packages built from the old cvs20061014. Damn, next homework is due Wednesday and still no Xorg patch created. That homework is a biggie and I should already have started. Martin
Ben Taylor
2007-Jan-09 20:44 UTC
[qemu-discuss] Re: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin
> Martin Bochnig wrote: > > > Merging several small and bigger diffs into the CVS > was not so much of a > problem. > But they at qemu (i.e. Thiemo Seufer) have > professionally reimplemented > DMA support into hw/ide.c and hw/dma.c , rather than > just using the > working solution Juergen Keil has written.I hacked around with this today, and have been unable to boot a Solaris Express B54 ISO image with DMA enabled, even with some of the hacks that Juergen had orginally written. I will go back to my 0.8.0 hacks to see if there''s something in the ide_atapi registered that I messed around with, but it looks like the changes that happened in the IO subsystem is causing some big problems for Solaris (and other OS''s requiring DMA from a CDROM).> Using the default dma.c and ide.c breaks DMA support > for Solaris guests > once again.yep.> One gets the best results for Solaris-guest > dma-support, when simpliy > using the old Solaris-patched ide.c and dma.c from > http://www.martux.org/qemu/RELEASES/sparc/qemu-0.8.2__ > default_FabriceB__versus__qemu-0.8.2-solaris__20061013 > fri__MB.gdiff > or > http://opensolaris.org/os/project/qemu/downloads/qemu- > 0.8.2-solaris_src_20061013fri.tar.bz2 > > However: cdrom support is currently completely broken for Win9x guests, > no matter whether I use Oct14''s patched ide.c/dma.c, unpatched > cvs20070102tue ones, or patched cvs20070102tue ones > with the old JuergenKeil-written code merged into as best as now > possible. Unfortunately doesn''t it core dump - it just doesn''t work.Yep.> Ben Taylor is also "unimpressed" by the current cvs.Actually, the latest CVS code is showing release 0.8.3, and since they integrated the patch for block-raw.c the current code base compiles fine with Solaris now. -- This message posted from opensolaris.org
Bernd Schemmer
2007-Jan-09 22:44 UTC
[qemu-discuss] Re: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin
Hi,> Actually, the latest CVS code is showing release 0.8.3, > and since they integrated the patch for block-raw.c the > current code base compiles fine with Solaris now. >And the dma issue mentioned by Martin and you is not there anymore in this release? regards Bernd> -- > This message posted from opensolaris.org > _______________________________________________ > qemu-discuss mailing list > qemu-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/qemu-discuss > >-- Bernd Schemmer, Frankfurt am Main, Germany http://home.arcor.de/bnsmb/index.html M?s temprano que tarde el mundo cambiar?. Fidel Castro
Martin Bochnig
2007-Jan-10 00:40 UTC
[qemu-discuss] Re: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin
/* Note: 2nd try to send msg., this time without the oversized attachment (url instead). Eric: I cannot cancel the original msg. (bad confirmation string, after I reloaded page). Please reject it, thanks. */ Bernd Schemmer wrote:> Hi, > >> Actually, the latest CVS code is showing release 0.8.3, >> and since they integrated the patch for block-raw.c the >> current code base compiles fine with Solaris now. >> > > > And the dma issue mentioned by Martin and you is not there anymore in > this release?yep, currently, still. But I made minor progress when I last had time for it (a week ago). The problems must (partially) be outside of ide.c and dma.c (bridge or chipset or new ide vs. scsi disk support). My next step will be to systematically narrow down the field, where the problem can potentially be expected: First will I have to test the behaviour on different HOST os''s. If it does work on linUX HOSTs (sparc, x86/64), for example, then only #ifdef''ed stuff like header files and other characteristics can be the problem. Again, a status summary: (A) With the old ide.c and dma.c from our Oct14 patched src tree (inside a patched cvs20070102tue) I get: Solaris11_b54-guest: [ X] CDROM works [X] DMA works Win9x guest [ ] CDROM works [ ] DMA works ############## (B) With the unpatched default cvs20070102 ide.c and dma.c files I get: Solaris11_b54-guest: [ X] CDROM works [ ] DMA works Win9x guest [ ] CDROM works [ ] DMA works ############## (C) With Juergen Keil''s old dma patch merged into ide.c (of course by hand, as much as it now fits) I currently get: Solaris11_b54-guest: [ X] CDROM works [partially] DMA works Win9x guest [ ] CDROM works [ ] DMA works ############## (--) With the old Oct14 SUNWqemu package, on the other hand, we used to get: Solaris11_b46-guest: [ X] CDROM works [X] DMA works Win9x guest [X] CDROM works [X] DMA works It''s all just code and is therefore solvable. ... that is, literally, a.s.a.p. Regards, Martin p.s. Again, status from last week, the old Oct14 patch merged into cvs20070102tue: http://www.opensolaris.org/jive/servlet/JiveServlet/download/13-21321-81940-1888/qemu_cvs20070102tue__solaris__MB.gdiff.bz2 Note: The other patches to be included are not yet inside, as we first need to get the basics running - reliably enough.> > regards > > Bernd > >> -- >> This message posted from opensolaris.org >> _______________________________________________ >> qemu-discuss mailing list >> qemu-discuss at opensolaris.org >> http://opensolaris.org/mailman/listinfo/qemu-discuss >> >> > > >
Ben Taylor
2007-Jan-10 20:35 UTC
[qemu-discuss] Re: Re: New SUNWqemu cvs20070102tue in the works .... rgds. -Martin
> Bernd Schemmer wrote: > > > Hi, > > > >> Actually, the latest CVS code is showing release > 0.8.3, > >> and since they integrated the patch for > block-raw.c the > >> current code base compiles fine with Solaris now. > >> > > > > > > And the dma issue mentioned by Martin and you is > not there anymore in > > this release?Yeah. The old patches I had, and the stuff martin has used to work, but there has been substantial work in the last 6 months on the io subsystem. IDE was enhanced, and SCSI was added, and then there was a DMA and AIO subsystem put in place (which I think is where the crux of the problem is). The changes that Martin have against the current code base shows the amount of change that has occured in hw/ide.c in the last couple of months, specifically around IDE/DMA and CD DMA. The stock CVS code can boot a Solaris NVX B54 ISO image, but sees DMA timeout messages and eventually fails to complete when it can''t see/mount the file system where the Solaris packages are. I then tried a basic, text mode, SUNWCuser install, disabling atapi-cd-dma-enabled at the grub boot prompt, and that completed, but has yet to actually boot completely into Solaris. I let it go for 30-40 minutes after it complted the SMF initialization, but it never got the root prompt. All I see are DMA timeouts. I''m trying to boot it with -B atapi-cd-dma-enabled=0 to see if it will actually come up.> yep, currently, still. > But I made minor progress when I last had time for it > (a week ago). > The problems must (partially) be outside of ide.c and > dma.c (bridge or > chipset or new ide vs. scsi disk support).Some SCSI disk stuff went back in again today.... <sigh>> My next step will be to systematically narrow down > the field, where the > problem can potentially be expected: First will I > have to test the > behaviour on different HOST os''s. > If it does work on linUX HOSTs (sparc, x86/64), for > example, then only > #ifdef''ed stuff like header files and other > characteristics can be the > problem.I''d like to see us take specific subsets of your patches and get them submitted to the QEMU CVS. They are more willing to take tiny patches that fix one specific thing, than a big hairy patch like we have now. I see like 4-5 things that could be separate patches for CVS, but there may be some intermingling of areas that require more effort to separate. 1) sparcv7/v8/v8plus configure changes. I understand why the CFLAGS/LDFLAGS need to be defined in the configure script (specifically so the libsdl test gets linked correctly at configure time) 2) x86_64 kqemu support. This looks like it needs some tuning, especially since kqemu only works with Solaris Express/Open Solaris (not Solaris 10) 3) Sparc V9 support (dyngen.c, elf.h) 4) Sparc/Arm changes 5) Sparc RTDC support (vl.c) - didn''t we already have rtdc support here, or is this specific to the hw machine types? 6) ide.c - I think we''ll probably have to work within the current changes. The patches that martin have that are working are drastically different from the current CVS code, and I don''t think we''re going to be able to make a case on why it should stay the same without proving the pbrook, theimo and fabrice otherwise. Does this look about right?> Again, a status summary: > > (A) > With the old ide.c and dma.c from our Oct14 patched > src tree (inside a > patched cvs20070102tue) I get: > Solaris11_b54-guest: > [ X] CDROM works > [X] DMA works > > Win9x guest > [ ] CDROM works > [ ] DMA works > > ############## > > (B) > With the unpatched default cvs20070102 ide.c and > dma.c files I get: > Solaris11_b54-guest: > [ X] CDROM works > [ ] DMA works > > Win9x guest > [ ] CDROM works > [ ] DMA works > > ############## > > (C) > With Juergen Keil''s old dma patch merged into ide.c > (of course by hand, > as much as it now fits) I currently get: > Solaris11_b54-guest: > [ X] CDROM works > [partially] DMA works > > Win9x guest > [ ] CDROM works > [ ] DMA works > > ############## > > (--) > With the old Oct14 SUNWqemu package, on the other > hand, we used to get: > Solaris11_b46-guest: > [ X] CDROM works > [X] DMA works > > Win9x guest > [X] CDROM works > [X] DMA works > > It''s all just code and is therefore solvable. > ... that is, literally, a.s.a.p. > > > Regards, > Martin > p.s. Again, status from last week, the old Oct14 > patch merged into > cvs20070102tue: > http://www.opensolaris.org/jive/servlet/JiveServlet/do > wnload/13-21321-81940-1888/qemu_cvs20070102tue__solari > s__MB.gdiff.bz2 > Note: The other patches to be included are not yet > inside, as we first > need to get the basics running - reliably enough.I understand that the code from 3 months ago is working with patches, but the IDE/DMA stuff is very different now. Ben -- This message posted from opensolaris.org
Dear (qemu@)opensolaris community,
I played a bit with porting virtualbox.de to Nevada_x86.
But I''m losing ways too much time there and will stop now.
The ROI doesn''t justify the effort required (at least not, if one has
more urgent things to get finished, as most of us do).
It can''t be done in a "day".
Then: The speed improvement, if any, wouldn''t be noticable over
qemu/kqemu_userMode, except some brilliant person would additionally
port vbox''s kernel module, too:
http://www.virtualbox.de/wiki/Mac%20OS%20X%20build%20instructions
"" Running VirtualBox ?
<http://www.virtualbox.de/wiki/Mac%20OS%20X%20build%20instructions#RunningVirtualBox>
As mentioned elsewhere, the Mac OS X port of VirtualBox is work in
progress. Only the very basic GUI (VBoxBFE) is available and because the
supporting kernel extension (trunk/src/VBox/HostDrivers/Support
<http://www.virtualbox.de/browser/trunk/src/VBox/HostDrivers/Support>)
isn''t ported yet, the guest performance is quite terrible.
1. VirtualBox must be instructed not to try use the missing kernel
extension.
export VBOX_SUPLIB_FAKE="fake" ""
Plus: VirtualBox _is_ in fact based on a tuned version of qemu.
You see it here:
http://virtualbox.de/browser/trunk/src/recompiler
http://virtualbox.de/browser/trunk/src/recompiler/vl.h
Where it reads:
"" /vl.h
<http://virtualbox.de/browser/trunk/src/recompiler/vl.h>
View revision:
Revision 1 <http://virtualbox.de/changeset/1>, 31.1 kB (checked in by
vboxsync, 0 seconds ago)
import
* Property *svn:eol-style* set to /|native|/
Line
1 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L1> //*/
2 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L2> / * QEMU
System Emulator header/
3 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L3> / * /
4 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L4> / *
Copyright (c) 2003 Fabrice Bellard/
5 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L5> / * /
6 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L6> / *
Permission is hereby granted, free of charge, to any person obtaining a
copy/
7 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L7> / * of
this software and associated documentation files (the "Software"), to
deal/
8 <http://virtualbox.de/browser/trunk/src/recompiler/vl.h#L8> / * in
the Software without restriction, including without limitation the rights/
""
So we all (at least on x86/x64) _will_ benefit from virtualbox having
gone GPL: Whether directly (if someone ever ports it to Solaris_x86), or
indirectly, just exactly because the qemu developers are striving to
re-import vbox''s speed tricks and enhanced device matrix back into
vanilla qemu:
http://lists.gnu.org/archive/html/qemu-devel/2007-01/msg00168.html
"" For what I have seen in the sources, that''s based on
qemu, sligthly
modified
in order to be somehow "modular", thus allowing them to distribute
additional
proprietary extensions (list at
http://www.virtualbox.org/wiki/Closed-source%20features ) ::
Sigh, I finally have to release the updated cvs20070120sat SUNWqemu pkgs
for SPARC and x86/x64 (which already were 98% ready, before I moved over
to vbox for two days).
FYI, below is a _tiny_ excerpt, from how far I progressed after two days
of vbox porting work.
I cannot continue at this point, because I ran out of time.
Nor did I want to (because qemu runs quite fine already) :
include/VirtualBoxErrorInfoImpl.h:74: error: `nsresult'' does not name a
type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:47:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:86:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:148:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:
In member function `void
ProgressBase::protectedUninit(util::AutoLock&)'':
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:175:
error: request for member `setNull'' in
`((ProgressBase*)this)->ProgressBase::mInitiator'', which is of
non-class
type `int''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:
At global scope:
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:194:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:208:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:222:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:246:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:258:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:278:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:290:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:302:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:318:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:334:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:346:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:358:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:370:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:389:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:420:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:470:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:548:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:611:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:674:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:700:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:722:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:756:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:837:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:879:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:908:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1002:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1026:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1041:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1056:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1071:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1086:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1101:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1116:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1141:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1200:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1287:
error: `NS_IMETHODIMP'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1313:
error: `nsresult'' does not name a type
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h: In
static member function `static void ComStrongRef<C>::release(C*) [with C
IProgress]'':/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:188:
instantiated from `void ComPtrBase<C, RefOps>::release() [with C
IProgress, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:102:
instantiated from `ComPtrBase<C, RefOps>::~ComPtrBase() [with C IProgress,
RefOps = ComStrongRef]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_construct.h:107:
instantiated from `void std::_Destroy(_Tp*) [with _Tp ComPtr<IProgress,
ComStrongRef>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_construct.h:120:
instantiated from `void std::__destroy_aux(_ForwardIterator,
_ForwardIterator, __false_type) [with _ForwardIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_construct.h:152:
instantiated from `void std::_Destroy(_ForwardIterator,
_ForwardIterator) [with _ForwardIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/vector.tcc:122:
instantiated from `typename std::vector<_Tp, _Alloc>::iterator
std::vector<_Tp, _Alloc>::erase(__gnu_cxx::__normal_iterator<typename
_Alloc::pointer, std::vector<_Tp, _Alloc> >,
__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp,
_Alloc> >) [with _Tp = ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_vector.h:701:
instantiated from `void std::vector<_Tp, _Alloc>::clear() [with _Tp
ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:994:
instantiated from here
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:61:
error: invalid use of undefined type `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ErrorInfo.h:31:
error: forward declaration of `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h: In
static member function `static void ComStrongRef<C>::addref(C*) [with C
= IProgress]'':
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:194:
instantiated from `void ComPtrBase<C, RefOps>::safe_assign(C*) [with C
IProgress, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:105:
instantiated from `ComPtrBase<C, RefOps>& ComPtrBase<C,
RefOps>::operator=(const ComPtrBase<C, RefOps>&) [with C =
IProgress,
RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:218:
instantiated from `ComPtr<I, RefOps>& ComPtr<I,
RefOps>::operator=(const
ComPtr<I, RefOps>&) [with I = IProgress, RefOps =
ComStrongRef]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:247:
instantiated from `_OutputIterator std::__copy(_RandomAccessIterator,
_RandomAccessIterator, _OutputIterator, std::random_access_iterator_tag)
[with _RandomAccessIterator = ComPtr<IProgress, ComStrongRef>*,
_OutputIterator = ComPtr<IProgress, ComStrongRef>*]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:266:
instantiated from `_OutputIterator std::__copy_aux2(_InputIterator,
_InputIterator, _OutputIterator, __false_type) [with _InputIterator
ComPtr<IProgress, ComStrongRef>*, _OutputIterator = ComPtr<IProgress,
ComStrongRef>*]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:296:
instantiated from `_OutputIterator std::__copy_ni2(_InputIterator,
_InputIterator, _OutputIterator, __true_type) [with _InputIterator
ComPtr<IProgress, ComStrongRef>*, _OutputIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:317:
instantiated from `_OutputIterator std::__copy_ni1(_InputIterator,
_InputIterator, _OutputIterator, __true_type) [with _InputIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > > >,
_OutputIterator __gnu_cxx::__normal_iterator<ComPtr<IProgress,
ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_algobase.h:358:
instantiated from `_OutputIterator std::copy(_InputIterator,
_InputIterator, _OutputIterator) [with _InputIterator
__gnu_cxx::__normal_iterator<ComPtr<IProgress, ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > > >,
_OutputIterator __gnu_cxx::__normal_iterator<ComPtr<IProgress,
ComStrongRef>*,
std::vector<ComPtr<IProgress, ComStrongRef>,
std::allocator<ComPtr<IProgress, ComStrongRef> > >
>]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/vector.tcc:121:
instantiated from `typename std::vector<_Tp, _Alloc>::iterator
std::vector<_Tp, _Alloc>::erase(__gnu_cxx::__normal_iterator<typename
_Alloc::pointer, std::vector<_Tp, _Alloc> >,
__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp,
_Alloc> >) [with _Tp = ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/stl_vector.h:701:
instantiated from `void std::vector<_Tp, _Alloc>::clear() [with _Tp
ComPtr<IProgress, ComStrongRef>, _Alloc
std::allocator<ComPtr<IProgress, ComStrongRef> >]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:994:
instantiated from here
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:60:
error: invalid use of undefined type `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ErrorInfo.h:31:
error: forward declaration of `struct IProgress''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h: In
static member function `static void ComStrongRef<C>::release(C*) [with C
= IVirtualBoxErrorInfo]'':
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:188:
instantiated from `void ComPtrBase<C, RefOps>::release() [with C
IVirtualBoxErrorInfo, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:102:
instantiated from `ComPtrBase<C, RefOps>::~ComPtrBase() [with C
IVirtualBoxErrorInfo, RefOps = ComStrongRef]''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main/ProgressImpl.cpp:1386:
instantiated from here
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ptr.h:61:
error: invalid use of undefined type `struct IVirtualBoxErrorInfo''
/export/home/PROJECTS/VIRTUALBOX/000/vbox/include/VBox/com/ErrorInfo.h:32:
error: forward declaration of `struct IVirtualBoxErrorInfo''
kmk[2]: ***
[/export/home/PROJECTS/VIRTUALBOX/000/vbox/out/SunOS.x86/release/obj/src/VBox/Main/VBoxC/ProgressImpl.o]
Error 1
kmk[2]: Leaving directory
`/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox/Main''
kmk[1]: *** [pass_dlls_before] Error 2
kmk[1]: Leaving directory
`/export/home/PROJECTS/VIRTUALBOX/000/vbox/src/VBox''
kmk: *** [pass_dlls_before] Error 2
bash-3.00#
Regards,
Martin Bochnig
On a side-note: Precompiled vbox linux binaries might potentially work under LXrun or inside a linux zone (at least qemu does). However, since LKMs are not supported by those environments, you could never benefit from vbox''s better performance (over qemu), as the speed can only be achieved by the associated vbox''s kernel module. VMware doesn''t run at all under LXrun (nor under Janus), because it cannot even be started without its LKMs loaded.> >Regards, >Martin Bochnig >