Re: [PATCH v13 2/7] net/vmnet: add vmnet backends to qapi/net

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Montag, 24. Januar 2022 18:49:53 CET Roman Bolshakov wrote:
> On Mon, Jan 24, 2022 at 12:27:40PM +0100, Christian Schoenebeck wrote:
> > On Montag, 24. Januar 2022 10:56:00 CET Roman Bolshakov wrote:
> > > On Thu, Jan 13, 2022 at 08:22:14PM +0300, Vladislav Yaroshchuk wrote:
> > > >  net/vmnet-bridged.m |  25 +++++++++
> > > >  net/vmnet-common.m  |  20 +++++++
> > > 
> > > It seems the last two files should have .c extension rather than .m.
> > 
> > I would not do that. Mind cross-compilers, please.
> 
> Hi Christian,
> 
> Cross-compilers for Apple platforms can be constructed using à la carte
> approach where toolchain comes from the source, SDK from Apple and a
> port of cctools from GitHub (mind all library dependencies of QEMU).
> That's quite an effort!
> 
> I very much doubt this is a relevant and typical case for QEMU on macOS.
> And if cross-compiler is constructed properly it'll pass required flags
> that enable blocks and will link block runtime in its default build
> recipe like all cross-compilers do for the platform of interest.
> 
> Gladly, there's osxcross [1] and crossbuild image with Darwin support [2].
> They can deal with blocks just fine:
> 
>   # CROSS_TRIPLE=i386-apple-darwin
>   $ cc block.c && file a.out
>   a.out: Mach-O i386 executable,
> flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|NO_HEAP_EXECUTION>
> 
>   # CROSS_TRIPLE=x86_64-apple-darwin
>   $ cc block.c && file a.out
>   $ file a.out
>   a.out: Mach-O 64-bit x86_64 executable,
> flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
> > > Unlike Cocoa UI code, the files do not contain Objective-C classes. They
> > > are just C code with blocks (which is supported by compilers shipped
> > > with Xcode SDK), e.g this program can be compiled without extra
> > > compiler flags:
> > > 
> > > $ cat block.c
> > > int main() {
> > > 
> > >         int (^x)(void) = ^{
> > >         
> > >                 return 0;
> > >         
> > >         };
> > >         
> > >         return x();
> > > 
> > > }
> > > $ cc block.c && ./a.out
> > > $
> > 
> > Such blocks are still Objective-C language specific, they are not C and
> > therefore won't work with GCC.
> 
> I'm not sure why blocks are Objective-C specific. All the data I have
> shows the opposite [3][4][5]. They're just extensively used in Apple APIs.

Because blocks are automatically available if you are using an Objective-C or 
Objective-C++ frontend, but not necessarily if you use a C or C++ frontend.

> > $ gcc block.c
> > 
> > block.c: In function ‘main’:
> > block.c:2:14: error: expected identifier or ‘(’ before ‘^’ token
> > 
> >          int (^x)(void) = ^{
> >          
> >               ^
> > 
> > block.c:6:16: warning: implicit declaration of function ‘x’ [-Wimplicit-
> > function-declaration]
> > 
> >          return x();
> >          
> >                 ^
> 
> You might do this on Linux and it'll work:
> 
> $ clang -g -fblocks -lBlocksRuntime block.c && ./a.out

Yes, which is an unnecesary complicated & limiting variant of just:

	clang/gcc block.m

Don't get me wrong, I don't care too much about this issue. It's just that I 
really see no advantage in renaming this into a C file, but I do see 
disadvantages. That's all.

> However, vmnet code won't be compiled on non-Apple platforms because the
> compilation happens only if vmnet is available which happens only if
> appleframeworks dependency is available, that is not available on
> non-OSX hosts [6]:
> 
>   "These dependencies can never be found for non-OSX hosts."
> 
> 1. https://github.com/tpoechtrager/osxcross
> 2. https://github.com/multiarch/crossbuild
> 3. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1370.pdf
> 4. https://clang.llvm.org/docs/BlockLanguageSpec.html
> 5. https://clang.llvm.org/docs/Block-ABI-Apple.html
> 6. https://mesonbuild.com/Dependencies.html#appleframeworks
> 
> Regards,
> Roman