search

sanyaade-g2g-repos / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

Mac OS X Snow Leopard needs new SDL version #184

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is very strange. I had Grafx2 working on my Macbook for a good long while, 
but after a clean 
install of Leopard plus an update to 10.5.7 on a 2008 Intel Macbook, Grafx2 
refuses to launch. No 
errors, no crashes, just...nothing. I've also tried manually running the 
executable under Terminal:

$ cd Graphx2.app/Contents/MacOS
$ ./Grafx2
-bash: ./Grafx2: cannot execute binary file
$ ls -l
-rwxr-xr-x  1 pkmays  staff  1461088 Jun 11 19:27 Grafx2

I've tried deleting the Bundle, redownloading the .zip, moving the .app from 
/Applications to 
~/Desktop — nothing works.

Original issue reported on code.google.com by blumun...@gmail.com on 27 Jun 2009 at 10:09

GoogleCodeExporter commented 9 years ago

Original comment by pulkoma...@gmail.com on 27 Jun 2009 at 8:22

GoogleCodeExporter commented 9 years ago 
I hate giving useless error reports, so I've been attempting to page back my 
memory. I remember 10.5.6 
throwing some warnings about depreciated Carbon features when I ran ./Grafx2 
from the command line. That 
might be a good place to start.

Original comment by blumun...@gmail.com on 28 Jun 2009 at 1:11

GoogleCodeExporter commented 9 years ago 
Hello,
Unfortunately for you, the bug seems to be on SDL side : 
http://bugzilla.libsdl.org/show_bug.cgi?id=581

There is a patch available, but it needs an update to SDL :
http://permalink.gmane.org/gmane.comp.lib.sdl/36747

So... we can't do much about it... hhhikr will have to investigate and either 
apply 
this patch or switch his builds to sdl1.3 if he wants to support leopard...

Original comment by pulkoma...@gmail.com on 28 Jun 2009 at 8:52

GoogleCodeExporter commented 9 years ago 
don't work for me to... same problem 10.5.7 ... but earles versions vorks...
can somebody send me version before final, i need it.. i can't work ;(

jamon

Original comment by ja77...@gmail.com on 30 Jun 2009 at 8:03

GoogleCodeExporter commented 9 years ago 
Previous MacOSX version? It's still in "All downloads":
http://code.google.com/p/grafx2/downloads/detail?name=grafx2-2.00b98.0-svn503-
macosx.zip&can=1&q=mac

Original comment by yrizoud on 30 Jun 2009 at 8:50

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I have the exact same problem on Snow Leopard 10.6 build 10A394. Please look 
into
patching SDL or switching to 1.3.

Original comment by MagerV...@gmail.com on 6 Jul 2009 at 9:40

GoogleCodeExporter commented 9 years ago 
Issue 189 has been merged into this issue.

Original comment by pulkoma...@gmail.com on 6 Jul 2009 at 10:39

GoogleCodeExporter commented 9 years ago

Original comment by pulkoma...@gmail.com on 6 Jul 2009 at 10:40

GoogleCodeExporter commented 9 years ago 
I managed to build rev 900 with make and SDL 1.2, and I've uploaded a copy here:

http://www.paradroid.net/tmp/Grafx2-900MV.zip

Original comment by MagerV...@gmail.com on 7 Jul 2009 at 9:49

GoogleCodeExporter commented 9 years ago 
I'm not sure if it was meant for general use, but I tried running the above on 
Leopard and it's a no go.

$ ./Grafx2
dyld: unknown required load command 0x80000022
Trace/BPT trap

Original comment by blumun...@gmail.com on 7 Jul 2009 at 7:12

GoogleCodeExporter commented 9 years ago 
It's probably because I built it on Snow Leopard. Check out svn r904 or later 
and you
should be able to build it yourself.

Original comment by MagerV...@gmail.com on 7 Jul 2009 at 9:11

GoogleCodeExporter commented 9 years ago 
Can somebody build working wersion for Leopard ;) please?

Original comment by ja77...@gmail.com on 15 Jul 2009 at 12:07

GoogleCodeExporter commented 9 years ago 
Yes, someone please do. I tried building my own version but I'm having problems 
compiling SDL. Leopard users 
still don't have a binary for the stable 2.0 branch.

Original comment by blumun...@gmail.com on 15 Jul 2009 at 11:35

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by pulkoma...@gmail.com on 22 Jul 2009 at 3:20

GoogleCodeExporter commented 9 years ago 
Please! working version for OSX... PLEASE!

Original comment by ja77...@gmail.com on 28 Jul 2009 at 8:42

GoogleCodeExporter commented 9 years ago 
Please avoid this kind of useless comments. We don't forget you, but we can't 
do 
anything, none of us having a MacOSX install available, except hitchhikr who 
seems 
to be away for now. I'll try to find him. If you think this issue is important 
you 
can star it. (click on the little grey star at the top of the page so it 
becomes 
yellow). We actually look at the number of people starring each issue to 
prioritize 
our work.

Original comment by pulkoma...@gmail.com on 28 Jul 2009 at 8:46

GoogleCodeExporter commented 9 years ago 
There's now 2 Mac OS X distributions, one for Tiger and Leopard and another one 
for
Snow Leopard, the former one works perfectly on my Tiger i don't know if it 
works on
Leopard.

Original comment by hhhikr@gmail.com on 31 Jul 2009 at 11:09

GoogleCodeExporter commented 9 years ago 
Issue 200 has been merged into this issue.

Original comment by pulkoma...@gmail.com on 31 Jul 2009 at 7:36

GoogleCodeExporter commented 9 years ago 
Does not work on Leopard PPC:
-bash: ./Grafx2: Malformed Mach-o file

Original comment by cameron...@comcast.net on 31 Jul 2009 at 9:13

GoogleCodeExporter commented 9 years ago 
As stated on issue 200, building from makefile generated a working app bundle on
Leopard.  Do you want me to upload a copy to you?

Original comment by samueldc...@gmail.com on 31 Jul 2009 at 10:19

GoogleCodeExporter commented 9 years ago 
If you managed to get a working binary for leopard with the makefile, running 
"make 
ziprelease" will create a .zip file ready for release. Please send it to me so 
I can 
upload it :)
(and please tell me what name I should call you in the About box :))
(this also apply to MagerValp, i'll add both of you as Leopard and Snow Leopard 
maitainers).

Original comment by pulkoma...@gmail.com on 1 Aug 2009 at 9:01

GoogleCodeExporter commented 9 years ago 
make ziprelease failed with a "syntax error near unexpected token `('" when 
executing
"`echo `sed "s/.*=\"\(.*\)\";/\1/" pversion.c`.`svnversion` | tr " :" "_-" | 
sed -e
s/\\(wip\\)\\\\./\\1/I > obj/macosx/versiontag'"

I'll look into the problem and get back to you.

Original comment by samueldc...@gmail.com on 1 Aug 2009 at 4:19

GoogleCodeExporter commented 9 years ago 
Strange, this one even worked on amiga ?

Original comment by pulkoma...@gmail.com on 1 Aug 2009 at 4:21

GoogleCodeExporter commented 9 years ago 
I'm not familiar enough with sed to figure out what this is supposed to do.  If 
you
could send me a list of commands to type or a shell script to execute that will 
do
the same thing as make ziprelease, I'll do that and get it back to you.

BTW, I've updated to the latest SVN and it still compiles and runs.

Original comment by samueldc...@gmail.com on 21 Aug 2009 at 2:45

GoogleCodeExporter commented 9 years ago 
The bash error is because of improper quoting. Using

echo `sed "s/.*=\"\(.*\)\";/\1/" pversion.c`.`svnversion` | tr " :" "_-" | sed 
-e
"s/\(wip\)\./\1/" > $(OBJDIR)/versiontag

fixes it. However, I'm not sure if it produces the intended output. pversion.c 
contains:

  char Program_version[]="2.1wip";

and svnversion is

  1001M

and this snippet outputs

  2.1wip1001M

However, the tr command doesn't do anything (there's no " :" to replace), and 
the
last sed command only removes the dot that is added inbetween pversion and 
svnversion
in the first sed command. This command has the exact same effect:

echo `sed "s/.*=\"\(.*\)\";/\1/" pversion.c``svnversion`

Original comment by MagerV...@gmail.com on 21 Aug 2009 at 7:19

GoogleCodeExporter commented 9 years ago 
Sorry I didn't see this before. I wrote this part of Makefile (and the sed / tr
commands) on MSYS (Windows), this can explain why it doesn't work everywhere.
svnversion can produce a string with ':' like "325:328", and the label could 
have
spaces, so TR replaces any occurrence of them by - and _ respectively.

Original comment by yrizoud on 21 Aug 2009 at 7:56

GoogleCodeExporter commented 9 years ago 
That gets me past the sed problem.  Now I need to find a version of tar that 
supports
the --transform option because that brought me to the next error.  Any 
suggestions of
where to look?

Original comment by samueldc...@gmail.com on 21 Aug 2009 at 3:38

GoogleCodeExporter commented 9 years ago 
That'd be GNU tar, possibly available on your system as gtar.

It'd probably be a better idea to create a temporary directory and copy the 
files
before tarring instead of using a non-standard tar option.

And using a variable instead of using a versiontag tempfile would make for a 
cleaner
makefile.

Original comment by MagerV...@gmail.com on 21 Aug 2009 at 4:08

GoogleCodeExporter commented 9 years ago 
I've redownloaded the source to a fresh directory and, except for the 
non-functioning
Makefile built and redid the zip archive.  The new app bundle works.  Take a 
look at
the attached archives and let me know what you think.

Keep in mind that this was built using the makefile rather than the XCode 
project so
it might be Intel only.  I only know it works on my Mac Mini running MacOSX 
10.5.8.

If you need me to build it differently, let me know.

Original comment by samueldc...@gmail.com on 21 Aug 2009 at 5:28

Attachments:

GoogleCodeExporter commented 9 years ago 
The goal of the "ziprelease" target is to create a binary archive (users unpack 
it,
read the README, and run the program), and at the same time the generic source
archive (source+data, all you need on linux or even windows if you have 
compilation
tools).
End-users will never need to "make ziprelease", so it's not big problem if itr
doesn't work on all OSes. It's a tool I made to automate the packaging, so that 
I
avoid any error in the filename and the archive content: missing files, extra 
useless
files, outdated executable, executable showing wrong version in About, etc. I'm 
also
lazy and in the long run it has saved me lots of time.

If MacOSX builds don't happen often, maybe it's not worth trying to make an 
automatic
tool.

If you're still interested, read on.

The binary archive for any platform should contain:
- Executable, any non-shared libraries (ex: SDL.Framework/* for MacOSX, SDL.DLL 
on
Windows) and all files needed at runtime: I got the impression that Grafx2.app 
is
exactly that. Does it need to be inside an embedded zip, even when installed?
- The "documentation" : readme, license docs. Normally appears under "docs/"
- All the sources that were involved in compiling this version. If the sources 
are
not exactly straight from the SVN repository (ie: svn version ends in "M"), 
including
the source is required to comply with GPL license. Even if it's exactly svn 
(and the
archive name tells which svn number), it's still strongly advised, in case a 
giant
meteor destroys the svn repository. Currently, this archive even repeats the svn
number, it's not a requirement, but it's helpful in finding out how old the 
archive is.

For MacOSX, there needs to be different packages for different OS versions.
Unfortunately the $(PLATFORM) will return "Darwin" in either case... If there's 
no
way to automate detection, the person who makes a binary package will have to 
choose
the name himself anyway :(

Original comment by yrizoud on 21 Aug 2009 at 5:37

GoogleCodeExporter commented 9 years ago 
Here's a better archive.  I've replaced the executable with the app bundle and
renamed the archive directory with the MacOSX version it's intended for.  The 
source
archive is included.

Original comment by samueldc...@gmail.com on 21 Aug 2009 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for the build, and I'm still very confused with how many different 
versions
exist. An attempt at synthesis, please correct me when needed:

10.4 = Tiger : PPC or Intel
10.5 = Leopard: PPC or Intel
10.6 = Snow Leopard: Intel

Building with XCode produces an Universal binary that supports both PPC&Intel.
Otherwise gcc natively compiles for your own CPU only.

Putting files in a "Grafx2.app" is mandatory or not? This "bundle" seemed to 
contain
SDL libs, this should be needed on target machine, and maybe CPU-dependant too.

Original comment by yrizoud on 21 Aug 2009 at 5:58

GoogleCodeExporter commented 9 years ago 
The one I just made is probably Intel only.  I don't know why XCode is screwing 
up
with the project files but I didn't even try to do it that way since somebody 
else
said that the project files were screwed up.

The app bundle is necessary to run things from an icon.  If it has just the
executable it usually can't find the files it is looking for.  It will usually 
launch
from the terminal as a text-based app if you try to launch just the executable 
by itself.

The only time that the frameworks are not needed within the bundle are if they 
are
installed in a global frameworks directory.  It's usually safer just to bundle 
the
frameworks in the app.  This is equivalent to putting the .dll files in the same
directory with a windows program.

I just wish I could remember how to set the icon on a Mac app bundle.  :-(

Original comment by samueldc...@gmail.com on 21 Aug 2009 at 6:16

GoogleCodeExporter commented 9 years ago 
HitchHikr fixed the project files so you should be able to use the XCode 
project.

As for the version, apple is great for doing cross platform executables, but 
they 
don't care about old versions of the os and often break binary compatibility in 
some 
way...

Original comment by pulkoma...@gmail.com on 21 Aug 2009 at 7:07

GoogleCodeExporter commented 9 years ago 
Ok, I'm running 10.5.6 and none of the newest versions work for me. I'm having 
to use the 2.0b98 edition. Any 
ideas?

Original comment by thedaemo...@gmail.com on 21 Aug 2009 at 10:39

GoogleCodeExporter commented 9 years ago 
The XCode project still seems to rely on things on nonstandard things on the
developer's machine, e.g. SDL_image.h and Png.h are missing. They need to be 
included
in the XCode project.

Original comment by MagerV...@gmail.com on 22 Aug 2009 at 8:13

GoogleCodeExporter commented 9 years ago 
Sorry for the messed up editing there :)

I thought I should point out that I have the SDL_image framework in
/Library/Frameworks, and of course libpng is included with Mac OS X. The Xcode
project just doesn't seem to reference them correctly.

Original comment by MagerV...@gmail.com on 22 Aug 2009 at 1:17

GoogleCodeExporter commented 9 years ago 
I've tried to draw a map of which version works for who, and... whoa. It seems 
that
anybody who compiles a version can only have it work on his own machine :(
Thedaemonofid, can you tell if you have an Intel or PPC cpu? The versions 
uploaded in
comments 32 and 34 are supposed to work for 10.5.7 (but I can't say if it's from
console and/or desktop)

Original comment by yrizoud on 22 Aug 2009 at 2:12

GoogleCodeExporter commented 9 years ago 
No, you can create universal binaries from Makefiles, see the SDL sources for 
how to
do it. Xcode automates it though, so it'd be a huge help if that was fixed.

Original comment by MagerV...@gmail.com on 22 Aug 2009 at 4:54

GoogleCodeExporter commented 9 years ago 
I have an intel cpu. I have xcode installed but haven't used it at all yet, so 
if there is something I could test by 
compiling, I'm all for it.

Original comment by thedaemo...@gmail.com on 22 Aug 2009 at 5:58

GoogleCodeExporter commented 9 years ago 
Yves: that's because when it works people don't come here :)

Original comment by pulkoma...@gmail.com on 22 Aug 2009 at 6:23

GoogleCodeExporter commented 9 years ago 
So apparently a program compiled on 10.5.7 doesn't work on 10.5.6 
(thedaemonofid) ???

And the 2.0b98 compiled by hhhikr on 10.4 works on 10.5.6 (thedaemonofid) and 
10.5.7
(Jamon), but when he compiles newer sources, it doesn't work for any user of 
10.5.x ???

If somebody understands anything....

Original comment by yrizoud on 22 Aug 2009 at 7:30

GoogleCodeExporter commented 9 years ago 
With a correctly configured Xcode project, and the universal 10.4 SDK, you can
compile a binary that works on 10.4 and up, on both Intel and PPC. The patched 
SDL
frameworks will also need to be compiled with the same SDK, and included in the 
project.

Original comment by MagerV...@gmail.com on 22 Aug 2009 at 7:58

GoogleCodeExporter commented 9 years ago 
I built the latest svn with make and it's working now. Took a bit of piddling 
but I'm now running 2.1wip. Thanks 
all.

Original comment by thedaemo...@gmail.com on 29 Aug 2009 at 8:44

GoogleCodeExporter commented 9 years ago 
/Users/thedaemon/Desktop/Grafx2\ 20-37-17.app/Contents/MacOS/Grafx2 ; exit;
Mac:~ thedaemon$ /Users/thedaemon/Desktop/Grafx2\ 
20-37-17.app/Contents/MacOS/Grafx2 ; exit;
Error number 12 occured in file main.c, line 539, function Init_program.
Error: File gfx2.ini is corrupt!
It contains bad values at line 343.
You can re-generate it by deleting the file and running GrafX2 again.
logout

I can't find any gfx2.ini files anywhere. This happened after Grafx2 wouldn't 
respond to my keyboard in 
fullscreen mode. the old 98 version works, but even when I compile a new 
version this one is still producing 
the same error. Any ideas?

Original comment by thedaemo...@gmail.com on 31 Aug 2009 at 1:59

GoogleCodeExporter commented 9 years ago 
gfx2.ini and gfx.cfg are in ~/Library/Preferences/com.googlecode.grafx2

Original comment by MagerV...@gmail.com on 31 Aug 2009 at 6:39

GoogleCodeExporter commented 9 years ago 
Thedaemonofid, perhaps you need to erase the old gfx2.ini file, and the new 
version
will make it's own.

Original comment by ilija.melentijevic on 3 Sep 2009 at 7:17