HaxeFoundation / neko

The Neko Virtual Machine
https://nekovm.org
Other
554 stars 107 forks source link

Build Failure on Xcode (Clang) 12 #215

Closed carlocab closed 3 years ago

carlocab commented 3 years ago

I recently tried to upgrade Homebrew's version of mbedtls here: https://github.com/Homebrew/homebrew-core/pull/66819

Homebrew CI runs tests on all packages that depend on mbedtls, and that included neko. This revealed a build failure using the system (macOS) compiler (Clang):

FAILED: libs/std/CMakeFiles/std.ndll.dir/process.c.o 
/usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -D_GNU_SOURCE -Dstd_ndll_EXPORTS -I. -Ivm -Ilibs/common -DNDEBUG -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -fPIC -fno-omit-frame-pointer -MD -MT libs/std/CMakeFiles/std.ndll.dir/process.c.o -MF libs/std/CMakeFiles/std.ndll.dir/process.c.o.d -o libs/std/CMakeFiles/std.ndll.dir/process.c.o -c libs/std/process.c
libs/std/process.c:461:2: error: implicit declaration of function 'kill' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        kill(val_process(vp)->pid,9);
        ^
1 error generated.

This can, of course, be fixed by passing -Wno-implicit-function-declaration. However, I hope this is something you'd want to fix here too.

CI run logs available here: https://github.com/Homebrew/homebrew-core/runs/1544327702

Incidentally, while I'm here, I should mention that we've been unable to build Neko for Big Sur. I think it could be a CMake issue, so I haven't opened a separate issue.

The problem appears to be that cmake has trouble finding system libiconv, because system libraries no longer exist in the file system on Big Sur. (They can only be found by, say,dlopen.) Details available on request, or in the linked CI run above.

carlocab commented 3 years ago

Separate issue for Big Sur build failure opened here: https://github.com/HaxeFoundation/neko/issues/216

mitchblank commented 3 years ago

Yes, after:

#ifdef NEKO_WINDOWS
#       include <windows.h>
#else
#       include <sys/types.h>
#       include <unistd.h>
#       include <errno.h>

... it should have #include <signal.h> It's available on any UNIX machine so safe to include there.

However that is just one of the issues I had building neko with Xcode12.

Another -Wimplicit-function-declaration issue is in libs/ui/ui.c which has:

libs/ui/ui.c:197:2: error: implicit declaration of function 'RunApplicationEventLoop' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        GRunApplicationEventLoop();
        ^
libs/ui/ui.c:217:2: error: implicit declaration of function 'QuitApplicationEventLoop' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        QuitApplicationEventLoop();
        ^

... I don't know much about the carbon UI interface but it seems those APIs are semi-private(?) However I added:

extern void GRunApplicationEventLoop(void);
extern void QuitApplicationEventLoop(void);

...and it at least compiled OK.

Another issue I hit was with lock_try/lock_acquire/lock_release which seemed to hit a naming conflict with something deep in the mach headers:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/usr/include/mach/lock_set.h:98:15: error: conflicting types for 'neko_lock_try'
kern_return_t lock_try
              ^
./neko.h:400:20: note: expanded from macro 'lock_try'
#define lock_try                        neko_lock_try
                                        ^
./neko.h:474:13: note: previous declaration is here
        EXTERN int lock_try( mt_lock *l );
                   ^
./neko.h:400:20: note: expanded from macro 'lock_try'
#define lock_try                        neko_lock_try
                                        ^
3 errors generated.

Just renaming those symbols seemed to work for me.

Finally I hit this warning that wasn't causing an actual build failure but definitely looks like it could cause a problem, but MSG_NOSIGNAL was giving warnings about re-defintion due to this code in libs/std/socket.c:

#if defined(NEKO_WINDOWS) || defined(NEKO_MAC)
#       define MSG_NOSIGNAL 0
#endif

I don't know why it is trying to define that in the NEKO_MAC case since at least recent OS/X SDKs had a MSG_NOSIGNAL flag. I believe that should be wrapped in an #ifndef MSG_NOSIGNAL block

tobil4sk commented 3 years ago

This should be resolved now.

carlocab commented 3 years ago

Thanks!