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
