• Editor
  • OS X 1.1.0 won't launch - here's a fix.

  • تم التحرير

The run.sh script had a few problems in it:

  • dirname $0 doesn't seem to work on my system, not sure why.
  • Space in the path names were causing problems.
  • Setting $APP to basename $APP seemed like it was breaking things.

The below run.sh script works for me when I do an "open Spine.app" on the command line, as well as launching it from the finder by double clicking.

#!/bin/bash

APP=`dirname "${BASH_SOURCE[0]}"` # run.sh -> MacOS
APP=`dirname "${APP}"` # MacOS -> Contents
APP=`dirname "${APP}"` # Contents -> Xxx.app
cd `dirname "${APP}"` # cd to Xxx.app parent dir
"${APP}/Contents/MacOS/launcher/jre/bin/java" \
    -server \
    -Xdock:name="Spine" \
    -Xdock:icon=../Resources/icon.icns \
    -Dapple.laf.useScreenMenuBar=true \
    -Dcom.apple.macos.useScreenMenuBar=true \
    -Dapple.awt.showGrowBox=false \
    -Dfile.encoding=UTF-8 \
	-Dapp="${APP}" \
    ${EXTRAARGS} \
    -Xmx512m \
    -jar "${APP}/Contents/MacOS/launcher/launcher.jar" \
    com.esotericsoftware.spine.editor.launcher.Launcher \
    "$@" \
    2>&1

exit 0
Related Discussions
...
  • تم التحرير

My fixes were:

  • Changed dirname $0 to dirname "${BASH_SOURCE[0]}"
  • God rid of "" quotes around `` calls, they're unnecessary.
  • Put quotes around "${APP}" otherwise it breaks when spaces are in file paths.
  • Got rid of the basename stuff... not sure why it was there, but it was setting $APP to Spine.app, which prevented the app from loading.

Here, this one fixes the icon problem, too:

#!/bin/bash

APP=`dirname "${BASH_SOURCE[0]}"` # run.sh -> MacOS
APP=`dirname "${APP}"` # MacOS -> Contents
APP=`dirname "${APP}"` # Contents -> Xxx.app
cd `dirname "${APP}"../` # cd to Xxx.app parent dir
#APP=`basename "${APP}"`
"${APP}/Contents/MacOS/launcher/jre/bin/java" \
    -server \
    -Xdock:name="Spine" \
    -Xdock:icon="${APP}/Contents/Resources/icon.icns" \
    -Dapple.laf.useScreenMenuBar=true \
    -Dcom.apple.macos.useScreenMenuBar=true \
    -Dapple.awt.showGrowBox=false \
    -Dfile.encoding=UTF-8 \
	-Dapp="${APP}" \
    ${EXTRAARGS} \
    -Xmx512m \
    -jar "${APP}/Contents/MacOS/launcher/launcher.jar" \
    com.esotericsoftware.spine.editor.launcher.Launcher \
    "$@" \
    2>&1

exit 0

$0 should work, that is strange.
basename is needed to set the -Dapp=... parameter to the Xxx.app file name.

I've updated the Mac downloads. They are now a DMG that contains a PKG installer. I've also updated the run.sh slightly differently from what you have. Could you please test and let me know if it works for you? I've tried to test it extensively on multiple Macs and I think it is working well.

I have no idea why $0 didn't expand properly, but there's nothing about my system that should be causing problems. When I debugged it, the $APP variable was set to "/", which makes no sense at all, but I assume that it might have something to do with the app package itself.

When I try using $0 in its own shell, it works properly:

Brighid:~ terry$ ./foo.sh
./foo.sh
Brighid:~ terry$ cd ..
Brighid:Users terry$ ./terry/foo.sh
./terry/foo.sh

That's actually the reason I went searching for another way to get at the $0 data.

The new application bundle does seem to behave, so thanks!

Cool, thanks for checking it out and reporting back! 🙂

Hi, and thank you for creating this wonderful tool. I use Flash+Scaleform in my day job and have been waiting a long time for something with Spine's workflow and indie-friendliness for my own use.

The latest build (with the installer) unfortunately doesn't work with my mac anymore. I'm running OSX Snow Leopard 10.6.8 on one of the last 32-bit Macbook Pros. I found this error in the console app:

3/2/13 8:02:23 PM [0x0-0x1bc1bc].Spine[3231] /Applications/Spine/Spine.app/Contents/MacOS/run.sh: line 10: Spine.app/Contents/MacOS/launcher/jre/bin/java: Bad CPU type in executable

The java binary must be 64-bit only with no 32-bit version. I'm not sure how I could go about hooking up a working java binary again.

Of course most software is jumping off of 32-bit Mac system compatibility these days due to Apple's relentless pushing, but I was really hopeful I'd be able to continue to use Spine on my current system due to its Java-ness. Do you guys have any ideas/possible fixes?

You can try running it without using the embedded JRE. To do that try running it this way:

java -server -jar Spine.app/Contents/MacOS/launcher/launcher.jar

Change to the directory that contains Spine.app, then run that. Alternatively, you can editor Spine.app/Contents/MacOS/run.sh and remove "${APP}/Contents/MacOS/launcher/jre/bin/".

If you are using the trial then replace "Spine.app" with "Spine Trial.app" in the above (but then you may need quotes or to escape the space with backslash).

Thank you for the quick response 🙂

I was able to start Spine from the terminal using your suggestion. (I had to give the complete path and add the Spine/ directory the default installer uses, like this: )

java -server -jar /Applications/Spine/Spine.app/Contents/MacOS/launcher/launcher.jar 

I was able to enter my license number at the splash screen, and Spine proceeded to download a newer version. Unfortunately, it failed when the progress bar reached the end:

Apollo:~ log$ java -server -jar /Applications/Spine/Spine.app/Contents/MacOS/launcher/launcher.jar 
Spine Launcher 1.0.03-full
Mac OS X i386 10.6.8
Updated to: 1.1.04
Uncaught
java.lang.NoSuchMethodError: java.net.URLClassLoader.close()V
	at com.esotericsoftware.spine.editor.launcher.Launcher.f(SourceFile:250)
	at com.esotericsoftware.spine.editor.launcher.Launcher.e(SourceFile:570)
	at l.e.run(SourceFile:556)

I hit ctrl+c at the console to break, and re-ran Spine, which now opens a pop-up error, with this at the console:

Spine Launcher 1.0.03-full
Uncaught
java.lang.NoSuchMethodError: java.net.URLClassLoader.close()V
	at com.esotericsoftware.spine.editor.launcher.Launcher.f(SourceFile:250)
	at com.esotericsoftware.spine.editor.launcher.Launcher.<init>(SourceFile:207)
	at com.esotericsoftware.spine.editor.launcher.Launcher.main(SourceFile:671)

My spine.log is:

Spine 1.0.18-full
Licensed to: [EDIT: Removed]
Mac OS X i386 10.6.8
ATI Technologies Inc.
ATI Radeon X1600 OpenGL Engine
2.0 ATI-1.6.36
Java 1.6.0_41
Apple Inc.
Java HotSpot(TM) Client VM
Started.

As you can see my system's version of java is 1.6, which I'm guessing is the root of the problem with the new network calls.

Hmm, wow URLClassloader is really bad prior to Java 7, no good, for sure way to clean up the resources it uses... I've rewritten a portion of the launcher so it works fine on Java 6. I don't really feel like repackaging the whole Mac stuff at 4:30am, so I will PM you the file you need.

Thank you, I really appreciate the fix (PM response sent.) It works great!

I'm having exactly the same problem as Logarhythm.

When will a fixed build be out?

New build for the launcher is up. Note the JAR is now named launcher-full.jar, so the name in the command above needs to be changed.

Actually I decided I can do better than that... just updated again. Now it should run using the system Java if it detects the OS is 32bit. Can you guys try downloading the latest launcher and see if it runs on your 32bit Mac just by clicking the Spine.app?

I just downloaded/installed the latest launcher, and Spine runs when clicking the .app again. Thanks again.

Great! Thanks for trying it out. 🙂

I'm still getting the "Install X11" prompt. Am I missing something? Spine used to run just fine.

Are you able to install the X11 stuff? Should work after that.

I don't want to, to be completely honest. Spine is the only app that (now) needs it, and I like to keep my OS as clean as possible. The required download is 66Mb, which will expand to considerably more. This seems more than a little excessive just to run Spine.

So I'm left in a position where Spine no longer runs on my system. When I pledged on Kickstarter, the trial worked just fine (i.e. no X11 requirement). The previous versions worked just fine too. Hmmm...

Then use the command I posted to run it. :think:

java -server -jar /Applications/Spine/Spine.app/Contents/MacOS/launcher/launcher-full.jar

Well, I made it a little easier to use an alternate Java. If you define an environment variable called SPINE_JAVA, it will use that when Spine.app is run. To use the system Java, you'd set it to "java" (without quotes). Eg, from the command line...

export SPINE_JAVA=java
open Spine.app

There are various ways to set environment variables in OS X:
http://stackoverflow.com/questions/1356 ... es-in-os-x
You can use the RCEnvironment tool if you want a GUI for doing it:
http://www.rubicode.com/Software/Bundle ... nvironment

Thanks Nate. That's a cleaner solution, and one that I'm happy with.

Sorry Nate - I've added the environment variable (using the GUI tool you linked to), but I'm still getting the X11 prompt. I've rebooted, just to be sure the variable was active.

I'm running Spine v1.1.0.7, in OSX 10.8.2.

Any ideas?

Hmm. If you open the Console app, do you see a message from Spine when it starts? It should say "Spine: Using Java: xxx" where xxx is the SPINE_JAVA you set. What happens if you try:

export SPINE_JAVA=java
open /Applications/Spine.app

If that doesn't work, then I don't think you have the latest Spine launcher, you should download it again. If that works then it means however you are launching Spine isn't seeing your environment variable. I've read that launching via Spotlight may not see your variable:
http://www.digitaledgesw.com/node/31

I'm definitely running the latest build (I just re-installed to be sure).

Even when I run those commands, I'm still presented with the X11 prompt. Weird.

I can see the SPINE_JAVA entry in my exports:

...
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x SPINE_JAVA="java"
declare -x SSH_AUTH_SOCK="/tmp/launch-65LXli/Listeners"
declare -x TERM="xterm-256color"
...
Nate wrote

If you open the Console app, do you see a message from Spine when it starts? It should say "Spine: Using Java: xxx" where xxx is the SPINE_JAVA you set.

^
|

If you just want to get it working, you can right click Spine.app, Show Package Contents, expand Contents/MacOS, and edit run.sh with TextEdit. Where it says:

"$SPINE_JAVA" \

Check that to:

java \
Nate wrote

If you open the Console app, do you see a message from Spine when it starts? It should say "Spine: Using Java: xxx" where xxx is the SPINE_JAVA you set.

I didn't understand what you meant by "console". Are you referring to terminal? If so, I don't see that text, no.

By Console app I mean an app that comes with OSX called Console. You can find it by clicking Spotlight (the magnifying glass in the upper right of the screen) and typing console.

However, I found a problem in another thread... the builds I've been pushing don't actually have the changes they should. If you could please download the launcher again, I think you'll find it works. Sorry about this mess! :bang:

  • تم التحرير

Sorry Nate - I'm still getting the X11 prompt, and nothing appears in the console window when I run the app.

This is what I see when I launch via the java command:

Spine Launcher 1.0.08-full
Mac OS X x86_64 10.8.2
Java 1.6.0_43 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Up to date: 1.1.07
Spine 1.1.07-full
ATI Technologies Inc.
ATI Radeon HD 5750 OpenGL Engine
2.1 ATI-1.0.29
Started.

Well, at least my Spine stuff is doing the right thing. 🙂 Your logs show that it's using "Java 1.6.0_43 Apple Inc.". That is your system Java installation, not the Java bundled with Spine (which would say "OpenJDK unofficial"), so it is using the environment variable. Nothing in Spine shows that X11 popup, and you aren't using the Java bundled with Spine so I guess even the Apple Java is requiring X11, doesn't look like there is a way around it. I know you said that Spine used to run without X11, but I'm not sure how that is possible. Maybe you did a system update and Apple changed things? Maybe you started using a different system Java? You can choose which system Java to use by opening Java Preferences (use Spotlight, the magnifiying glass in the upper right of the screen, to find it).

The trial and the initial, post-Kickstart campaign releases worked just fine on my system. I'm still using the same system, so I can only assume that the recent Apple Java update changed something? I dont know.

I've never seen X11 be required in any Java interaction on OS X.

I can try to take a look on my system a bit later and see if I can reproduce the issue with the latest installer.

terrymisu wrote

I've never seen X11 be required in any Java interaction on OS X.

I can try to take a look on my system a bit later and see if I can reproduce the issue with the latest installer.

In fact, it should be mentioned that X11 is no longer maintained by Apple. It's all now here.

Do you have an old version of X11? It might be a good idea to grab the latest XQuartz build and install that, just to make sure it's not some weird interaction.

That said, I don't see how Apple could be requiring Java to interact with components that aren't bundled with the OS anymore... seems mysterious indeed.

Here's an official Apple Support KB about it: http://support.apple.com/kb/HT5293

Apple no longer maintains Java for OSX. In a recent update, Apple has removed Java 6 (formerly maintained by Apple) and replaced it with Java 7 (maintained by OpenJDK).

Nate wrote

Apple no longer maintains Java for OSX. In a recent update, Apple has removed Java 6 (formerly maintained by Apple) and replaced it with Java 7 (maintained by OpenJDK).

1.6 is still being actively maintained by Apple in terms of security patches and whatnot for 10.8.x.

I think the OS will now redirect to the Oracle stuff for systems that don't have Java installed, but I haven't verified this.

So it's a bit of a mixed bag at the moment... unfortunately.