Stellarium crash on start

Bug #1005155 reported by Alexander Wolf
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Stellarium
Fix Released
Critical
RalphBln

Bug Description

I downloaded the .dmg (sourceforge), opened it and copied Stellarium to my Applications folder. Stellarium crashes immediately when I try to start it. Seems to be some problem with QTOpenGL, but I have no idea what to do about it.

Thanks!

Crashreport:

Process: stellarium [8909]
Path: /Applications/Stellarium.app/Contents/MacOS/stellarium
Identifier: org.stellarium.Stellarium
Version: ??? (0.11.3)
Code Type: X86-64 (Native)
Parent Process: launchd [208]

Date/Time: 2012-05-27 07:22:59.334 -0400
OS Version: Mac OS X 10.7.4 (11E53)
Report Version: 9

Crashed Thread: 0

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: QtOpenGL.framework/Versions/4/QtOpenGL
  Referenced from: /Applications/Stellarium.app/Contents/MacOS/stellarium
  Reason: image not found

Binary Images:
       0x10d2a5000 - 0x10d90ffef +org.stellarium.Stellarium (??? - 0.11.3) <653046FD-BDB1-33BA-A940-2B8850418E80> /Applications/Stellarium.app/Contents/MacOS/stellarium
    0x7fff6cea5000 - 0x7fff6ced9baf dyld (195.6 - ???) <0CD1B35B-A28F-32DA-B72E-452EAD609613> /usr/lib/dyld
    0x7fff8c1e7000 - 0x7fff8c1f7ff7 com.apple.opengl (1.7.7 - 1.7.7) <0CA11278-746C-353A-923B-BCC0047190C3> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff8fecf000 - 0x7fff8fecffff com.apple.Cocoa (6.6 - ???) <021D4214-9C23-3CD8-AFB2-F331697A4508> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa

Tags: mac-os-x
Changed in stellarium:
importance: Undecided → High
assignee: nobody → treaves (treaves)
tags: added: mac-os-x
Changed in stellarium:
status: New → Confirmed
importance: High → Critical
Revision history for this message
treaves (treaves) wrote :

Th issue is getting the Frameworks modifed to be embedded; this broke with OS X 10.7. I have started to work on it, but it's a real pain.

Revision history for this message
RalphBln (schaef) wrote :

I don't know if this is of much help, but I managed to compile an intel-only .dmg of stellarium 11.3 (on an intel MBP, running 64-bit Mac OS 10.7.4).

Compiling and installing went smoothly. I ran into problems during make macosx_bundle.

One of the problems is that pkgApp.pl only checks for fat, ppc, and i386 when examining the embedded dynlibs. On 64-bit machines, /usr/bin/file shows "Mach-O 64-bit dynamically linked shared library x86_64". So pkgApp.pl should also look for "x86_64", otherwise, you get "what to do about $absname being $arch" messages (with $arch being empty) for every embedded library, and nothing is copied.

I just added the following lines to the architecture sub routine:

    elsif ( grep(m/x86_64/, @output) ) {
 $retval = $current_arch;
    }

This helped. Libraries got copied to the Frameworks directory, and install_name_tool changed the install names correctly.

(It's better to return $current_arch here, since uname returns i386 under Lion 64-bit, and the folders for the different architectures are created based on the output of uname).

Don't know about ppc though...

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Thanks for suggestion, I'm add patch but I can't try it.

Revision history for this message
RalphBln (schaef) wrote :

Another thing: The Qt plugins should be copied to the plugins directory (as stated in qt.conf) instead of the MacOS dir.

In macosx_bundle.sh:

Change line 22:
cp -pr /Developer/Applications/Qt/plugins/{imageformats,iconengines} ${CMAKE_INSTALL_PREFIX}/MacOS

to:
mkdir ${CMAKE_INSTALL_PREFIX}/plugins
cp -pr /Developer/Applications/Qt/plugins/{imageformats,iconengines} ${CMAKE_INSTALL_PREFIX}/plugins

Otherwise Qt finds and uses the plugins in /Developer/Applications/Qt/plugins on machines where Qt is installed. The plugins there in turn include links back to the Qt frameworks in /Library/Frameworks which leads to the Qt frameworks being loaded twice resulting in "Class XYZ is implemented in both .../stellarium-0.11.3/builds/macosx/Stellarium.app/Contents/MacOS/./../Frameworks/QtGui.framework/Versions/4/QtGui and /Library/Frameworks/QtGui.framework/Versions/4/QtGui. One of the two will be used. Which one is undefined." messages an stellarium crashing.

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Thanks for suggestion again! Please check a new revision.

Revision history for this message
RalphBln (schaef) wrote :

Oh, I forgot: The next line (23, now 24) must also be changed

from:
for f in ${CMAKE_INSTALL_PREFIX}/MacOS/{imageformats,iconengines}/*.dylib; do

to:
for f in ${CMAKE_INSTALL_PREFIX}/plugins/{imageformats,iconengines}/*.dylib; do

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Fixed, please check it.

Revision history for this message
RalphBln (schaef) wrote :

Ah, sorry, I should have tested before posting.

The plugins should not reside in subfolders of the plugins dir. My mistake.

So lines 22-24 in macosx_bundle.sh should be:

mkdir ${CMAKE_INSTALL_PREFIX}/plugins
cp -pr /Developer/Applications/Qt/plugins/{imageformats,iconengines}/* ${CMAKE_INSTALL_PREFIX}/plugins
for f in ${CMAKE_INSTALL_PREFIX}/plugins/*.dylib; do

This is tested in working on my machine with Qt frameworks installed.

Apologies for the confusion.

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Fixed too, please check it again.

Revision history for this message
RalphBln (schaef) wrote :

Okay, checked. The plugin depencies are okay.

However, copying of framworks and libraries still fails, because under Lion /usr/bin/arch can give inaccurate information (i386 instead of x86_64), leading to the creation of a "i386" directory and the subsequent attempt to copy to a (non-existing) "x86_64" directory.

This is why I recommended returning $current_arch rather than "x86_64" from the architecture sub routine in pkgApp.pl. I agree, however, that this is a rather dirty fix.

A maybe better fix would be to use "uname -m" instead of "arch" for detecting the current architecture (this seems to return the correct architecture on Lion systems):

Change pkgApp.pl, line 16 from:

my $current_arch = `/usr/bin/arch`;

to:

my $current_arch = `/usr/bin/uname -m`;

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Hmm... can you write patch for fully building working package?

Revision history for this message
RalphBln (schaef) wrote :

Here's the patch with my changes since rev 5457. If you need a patch with all changes mentioned in the last comments, pls. let me know (I have to go now, so I won't be able to do this right now).

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Yes, I need a full patch

Revision history for this message
RalphBln (schaef) wrote :

Okay, here's the complete patch.

Revision history for this message
Alexander Wolf (alexwolf) wrote :

I'm add your patch, thanks! Can you check it now?

Changed in stellarium:
status: Confirmed → In Progress
assignee: treaves (treaves) → RalphBln (schaef)
milestone: none → 0.11.4
Revision history for this message
RalphBln (schaef) wrote :

Checked. Works perfectly.

Revision history for this message
Alexander Wolf (alexwolf) wrote :
Changed in stellarium:
status: In Progress → Fix Committed
Revision history for this message
Alexander Wolf (alexwolf) wrote :

We upload new version of Stellarium - please check it.

URL: https://launchpad.net/stellarium/0.11/0.11.3/+download/Stellarium-0.11.3.dmg

Changed in stellarium:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.