Please help testing upcoming openMSX release!

Page 26/41
19 | 20 | 21 | 22 | 23 | 24 | 25 | | 27 | 28 | 29 | 30 | 31

By Manuel

Ascended (16614)

Manuel's picture

25-05-2020, 19:42

donluca, did you solve your compilation issues?

By donluca

Expert (69)

donluca's picture

25-05-2020, 23:20

Nope.

No matter what: using old school ./config make is a no-go because for some reason it can't find the 64-bit part of the TCL binary
(from less derived/x86_64-darwin-opt/config/probe.log)

TCL: Found header
linker command: clang++ derived/x86_64-darwin-opt/config/TCL.o -o derived/x86_64-darwin-opt/config/TCL.bin -arch x86_64 -mmacosx-version-min=10.7 -stdlib=libc++ -m64
Undefined symbols for architecture x86_64:
  "_Tcl_CreateInterp", referenced from:
      _f in TCL.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
return code from linker: 1
TCL: Missing lib

and staticbindinst throws an error at:

Compiling events/Keys.cc...
src/events/Keys.cc:54:14: error: no viable constructor or deduction guide for
      deduction of template arguments of 'array'
        auto keys = std::array{
                    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tuple:223:64: note: 
      candidate function template not viable: requires 0 arguments, but 152 were
      provided
template  struct _LIBCPP_TEMPLATE_VIS array;
                                                               ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tuple:223:64: note: 
      candidate function template not viable: requires 1 argument, but 152 were
      provided
src/events/Keys.cc:54:7: error: variables defined in a constexpr function must
      be initialized
        auto keys = std::array{
             ^
2 errors generated.
make[1]: *** [derived/x86_64-darwin-opt-3rd/obj/events/Keys.o] Error 1
make: *** [staticbindist] Error 2

This happens in all my macs I have at home which are all on macOS 10.13

I *might* do a test by stripping the 32-bit part of my TCL library so that only the 64-bit part remains, but that wouldn't solve anything.

It triggers me a bit, but since everyone can just download the nightly builds straight from github is kind of a non-issue.

By Manuel

Ascended (16614)

Manuel's picture

25-05-2020, 23:50

The staticbindist should really work. Can you try to use a newer Xcode?
Which Xcode are you using now anyway?

Maarten says it may also be due to the libc++ version being too old. Which version are you using?

By donluca

Expert (69)

donluca's picture

26-05-2020, 00:04

I'm using the latest XCode available on macOS 10.13 which is 10.1. Newer ones won't work on High Sierra, you have to upgrade to newer versions of macOS.

I theoretically could just update my toolchain using homebrew, but that might lead to a major screw up in my developing environment.

The version of libc++ I'm using is

luca@Cougar /u/lib> otool -L libc++.1.dylib 
libc++.1.dylib:
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
	/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 400.8.2)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

By Manuel

Ascended (16614)

Manuel's picture

26-05-2020, 22:28

Well, I have no idea how I can see how old this is...

But my best guess is that it's too old.

By donluca

Expert (69)

donluca's picture

26-05-2020, 23:18

Don't waste too much time looking into this.

If there were no ways of compiling the nightlies through github I'd definitely look into this issue because "you're using old XCode/libc++/whatever" is, strictly IMHO, a prime example of excruciatingly bad coding decisions during software development/maintenance, especially when your application is meant to run on those old OSes.

But then, macOS is the perfect example of dishearteningly garbage decisions, aimed at platform obsolescence and forcing your customer to update to newer OSes (ie: buy a new machine, thank you very much), so, in this particular context, it's all kind of a moot point.

And that's why I'd personally leave it as it is and focus your efforts elsewhere (although I must say again that I'm really happy with openMSX and can't really think of what I'd add – or fix, since all the bugs I've found have already been fixed).

By Manuel

Ascended (16614)

Manuel's picture

26-05-2020, 23:44

Ah, well, we just like to use modern C++ for the fun of it (coding must also be fun for the coder!). And then a little more modern compilers and libs are required.

Thanks for the compliments and please let us know if you find anything later on.

Anyone else who has encountered issues that need fixing before the release?

By friguron

Master (162)

friguron's picture

27-05-2020, 22:27

As far as I can understand the aim seems to keep 32 and 64 bits support at the same time, for MacOS, am I right?

In such case anyone having upgraded to XCode 11.X (for example me) will be unable to create a 32 bits version (as far as I understood when upgrading to Xcode 11)...

By donluca

Expert (69)

donluca's picture

28-05-2020, 00:19

Yeah, I mean... 64-bit support was introduced in Snow Leopard 10.6 which was a LONG time ago and I believe that the minimum macOS required for openMSX is Mavericks 10.9 which is already full 64-bits with support for 32-bit software, so I can't see why you'd want to compile 32-bit software on macOS (especially openMSX).

By Manuel

Ascended (16614)

Manuel's picture

28-05-2020, 00:23

Our official Mac builds are 64-bit only, so I'm not sure what you mean.
The code will be compileable for 32-bit, we're not going to block that.

Do you think it's even useful to have a 32-bit binary for Mac or Windows?

Page 26/41
19 | 20 | 21 | 22 | 23 | 24 | 25 | | 27 | 28 | 29 | 30 | 31