0.13 dev source build not completing under OS X Maverick

My build of 0.13 from 13/10/2013 (while still running Lion) loads and appears to work ok so far under Maverick.

Below is first step in actual build cmake ../.. plus messages, looking to work out what needs correction here.

IRON:~ alchymylab$ cd ~/Developer/Stellarium
IRON:Stellarium alchymylab$ cd builds/macosx
IRON:macosx alchymylab$ PATH=~/Qt5.1.1/5.1.1/clang_64/bin:$PATH
IRON:macosx alchymylab$ cmake ../..
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Clang 3.3
-- Looking for pow10
-- Looking for pow10 - not found
CMake Warning (dev) at /Users/alchymylab/Qt5.1.1/5.1.1/clang_64/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:123 (include):
  Syntax Warning in cmake code at

    /Users/alchymylab/Qt5.1.1/5.1.1/clang_64/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:8:56

  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  /Users/alchymylab/Qt5.1.1/5.1.1/clang_64/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:78 (find_package)
  /Users/alchymylab/Qt5.1.1/5.1.1/clang_64/lib/cmake/Qt5Declarative/Qt5DeclarativeConfig.cmake:78 (find_package)
  CMakeLists.txt:246 (FIND_PACKAGE)
This warning is for project developers. Use -Wno-dev to suppress it.

-- Found OpenGL: /System/Library/Frameworks/OpenGL.framework
-- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.5")
-- Found Gettext: /opt/local/bin/msgmerge (found version "0.18.3")
-- Found xgettext: /opt/local/bin/xgettext
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/alchymylab/Developer/Stellarium/builds/macosx
IRON:macosx alchymylab$

please try use export PATH=~/Qt5.1.1/5.1.1/clang_64/bin:$PATH at step 3

Thanks - I have not been using 'export PATH' until now and just 'PATH' worked under Lion, but I now understand the difference and that this may cure some of the issues. Will test this tonight.

"if you install XCode 5, including the command-line tools, the gcc compiler will get replaced with clang." - something I came across, not sure if it is significant.

Still investigating this issue, I am leaning more towards it being a cmake issue. I still had a GUI version of Cmake from before I used the macports version. This did not show these messages, although the build still failed at a later stage. I installed the lastest GUI version of cmake and that now shows the same error messages as above.

I notice there is also a beta version of Qt5.2 available, but they muddy the waters at this point.

I may go back and try building 12.4 as an experiment, as your build process has also changed.

NOTE: Users will get warnings now in Mavericks when downloading stellarium and trying to install. There is a new protection mechanism in Mavericks to control 'unauthorised' software being installed, but you can still install by holding down <Cntrl> key while clicking the package to open. Can get more detail if required.

But your buildbot makes package without troubles.

P.S. Maverick used digital signification for packages?

I must try and make progress with buildbot - this is a separate route. I think I now have the latest version from Macports.

Macports is updating the build of cmake to 2.8.12.1 at this time, will re-test existing build process once done.

Gone back as far as 12.4. Have got rid of 'Mac os unsupported' messages by tweak to qt 4.n (still installed alongside 5.1.1) by adding in extra line to qt file qglobal.h as below, I do not think message is relevant at this point. cmake works, but make only proceeds as far as 42% - error below.

[ 42%] Building CXX object src/CMakeFiles/stellarium.dir/core/renderer/StelQGLInterleavedArrayVertexBufferBackend.cpp.o
/Users/alchymylab/Developer/stellarium/src/core/renderer/StelQGLInterleavedArrayVertexBufferBackend.cpp:50:7: error:
      no type named 'free' in namespace 'std'
        std::free(vertices);
        ~~~~~^
1 error generated.
make[2]: *** [src/CMakeFiles/stellarium.dir/core/renderer/StelQGLInterleavedArrayVertexBufferBackend.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/stellarium.dir/all] Error 2
make: *** [all] Error 2
IRON:macosx alchymylab$

so make is still failing as before under mavericks!

amend to qtglobal.h to 'ignore 10.9' :

#ifdef Q_OS_DARWIN
# ifdef MAC_OS_X_VERSION_MIN_REQUIRED
# undef MAC_OS_X_VERSION_MIN_REQUIRED
# endif
# define MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_10_4
# include <AvailabilityMacros.h>
# if !defined(MAC_OS_X_VERSION_10_3)
# define MAC_OS_X_VERSION_10_3 MAC_OS_X_VERSION_10_2 + 1
# endif
# if !defined(MAC_OS_X_VERSION_10_4)
# define MAC_OS_X_VERSION_10_4 MAC_OS_X_VERSION_10_3 + 1
# endif
# if !defined(MAC_OS_X_VERSION_10_5)
# define MAC_OS_X_VERSION_10_5 MAC_OS_X_VERSION_10_4 + 1
# endif
# if !defined(MAC_OS_X_VERSION_10_6)
# define MAC_OS_X_VERSION_10_6 MAC_OS_X_VERSION_10_5 + 1
# endif
# if !defined(MAC_OS_X_VERSION_10_7)
# define MAC_OS_X_VERSION_10_7 MAC_OS_X_VERSION_10_6 + 1
# endif
# if !defined(MAC_OS_X_VERSION_10_8)
# define MAC_OS_X_VERSION_10_8 MAC_OS_X_VERSION_10_7 + 1
# endif
# if !defined(MAC_OS_X_VERSION_10_9)
# define MAC_OS_X_VERSION_10_9 MAC_OS_X_VERSION_10_8 + 1
# endif

# if (MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_9)
# warning "This version of Mac OS X is unsupported"
# endif
#endif

Hmm... Can you download latest revisions from lp:stellarium/0.12 and check it again?

Downloaded and checked again, same result.

Sent from my iPad

> On 3 Nov 2013, at 14:06, Alexander Wolf <email address hidden> wrote:
>
> Your question #238210 on Stellarium changed:
> https://answers.launchpad.net/stellarium/+question/238210
>
> Alexander Wolf requested more information:
> Hmm... Can you download latest revisions from lp:stellarium/0.12 and
> check it again?
>
> --
> To answer this request for more information, you can either reply to
> this email or enter your reply at the following page:
> https://answers.launchpad.net/stellarium/+question/238210
>
> You received this question notification because you asked the question.

I have kept a log of the messages output from the whole process when it did compile correctly at 12.4, it may not have been from the very final source I used for the official release, but pretty close. The compiler has probably changed under Mavericks and it looks like Apple are controlling the version now. Does this last error look legitimate or does the code appear correct as far as can be determined ?

Have a Buildbot demo running on OS X now, but I wonder if this is just another way to get the source code automatically, and that if it then follows the rest of the process (cmake etc) just as I do manually, then it will still fail.

Will try and get rid of the error messages re 'OS Version not supported' in the 0.13 build to then see what is left more clearly.

OK, you need Qt 5.2 and cmake 2.8.12 for Mavericks (bugs in Qt & cmake).

I've compiled 0.12.4 on Mavericks with QT4.8.5 (see my recent post about playing video with Phonon support)

There's nothing particularly bad, but just some minor tweaks needed.

The most annoying is the one mentioned above about std namespace. It's likely not the right way to really deal with it, but all I did was get rid of the "std::" before "free" (also same needed elsewhere for "malloc" and "realloc").

There was also a problem with "abs" not liking the ints (in hoursToHmsStr in StelUtils.cpp and in testConversions.cpp), so I just cast to float, and it was happy. And LC_NUMERIC was unknown in main.cpp, so I put "#include <clocale>" up top.

The "Argument not separated from preceding token by whitespace" looks like a bug in cmake, but it's only a warning, so it's benign (and not too hard to fix - just some mixed up quotes and backslashes in the Qt5GuiConfigExtras.cmake file).

Can't recall offhand if there was anything else, but whatever, it wasn't hard to get around...

However, building bzr on OSX10.9 was a different story (I had QT5.1.1, must try 5.2) - I can get it to compile, but then nothing renders when launched (just get blank white screen, and it crashes when I hit cmd-Q to quit).

IIRC, compiling that didn't have the std namespace problems with free/alloc/realloc, but it did need the float tweak for abs, and include of clocale so it knew LC_NUMERIC (those issues may be fixed in bzr by now? -haven't checked...)

Curious to know if the blank screen issue is fixed with QT5.2 and latest bzr?
(I currently have 0.12.4 working as I want, apart from video via Phonon - which is much further than I got with bzr before. If someone can advise whether video support is working fine for latest bzr in 10.9, then I'll move back to trying with that instead...)

Adrian

Adrian, can you make patch for 0.12.4?

I may be able to make 0.12.4 compile under 10.9 with the source tweaks I mentioned, but I've got no idea if they're really the right way to go about fixing the issues (I've hardly ever used C++ before, only C and Obj-C).

In particular, the removal of "std::" for free/malloc/realloc... is that really OK? Does it have any knock-on effect on other platforms and/or previous OSX? It'd be nice to know exactly why "std::free/malloc/realloc" was (presumably?) OK for previous OSX (and presumably on other platforms, too?), but isn't in this case for Mavericks.

Surely there must be other codes that have come across this with Mavericks? (If not, why not?) But after some searching around the 'net, I've still not managed to really understand what causes the problem.

The issue with using ints in "abs" is similar (presumably, it used to work...?), though in that case I can't imagine adding the cast to "float" will cause issues elsewhere, so I'd assume that's OK to change.

As for "#include <clocale>", I don't understand why that's not been needed before, including on other platforms? Does it somehow get included from elsewhere on previous OSX and all other Linux/Windows? Though, I'd guess that including it mostly likely has no ill effects for elsewhere, I can't really say for sure...

Is there anyone else out there with Linux/Windows/earlier-OSX who could test such changes to ensure they don't break the build for everyone else?

Thanks,

Adrian

I am looking at build process under Linux, as above, but having to install all the dependencies first. All under VirtualBox in OS X 10.9.

Have retrieved and built latest lp:Stellarium today under Mavericks and saved build log. App starts but gives a white screen and then crashes - as mentioned above.

The app does not crash right away now and there is some content in the start up log under the user directory.

Will put logs linked to my project page soon.

Linux test build still in development.

The lastest lp:stellarium source now builds under OS X 10.9 with no errors, but on startup it crashes after producing part of the start log in the user library. Alexander Wolf confirmed this is due to an issue with QtQuick1 code, as the problem is now identified I will await a fix.