Ha, you got one of the intermediate builds where I hadn't quite got the library packaging correct. There's a reason why the 0.7.x version are not official releases, and this was one of them :-)

Download 0.7.3 from here and read the warning about the odd bogus error message you'll need to ignore in the every last comment in the 64 bit thread ", its designed get to help me debug an issue that I couldn't recreate.

Dave

Right that means the libjpeg error is a red herring as 0.7.3 does not load libjpeg.dylib. It also means I've got nothing to go on if you're not getting any crash reports.

Is there anything in /Applications/Utilities/Console.app's Console messages or in its CRash Reporter Section.

Dave

Interesting. Yes it's supposed to be i386, no idea how it got to be ppc as I've haven't set it to that for ages :-)

Can you have look in the following directory in the source code folder

oxidizer_0_7_3_1/build_folder_for_flam3/include

and see if the file jpeglib.h is in there ? Thats is where it's supposed to be.

also what is in oxidizer_0_7_3_1/build_folder_for_flam3/lib, it should have these files…

libflam3.0.0.0.dylib libflam3.a libflam3.la libjpeg.a libjpeg.la libpng.dylib libpng14.14.dylib libpng14.dylib pkgconfig
libflam3.0.dylib libflam3.dylib libjpeg.8.dylib libjpeg.dylib libpng.a libpng.la libpng14.a libpng14.la

Finally, in oxidizer_0_7_3_1/flam3 there should be a file called config.log, a few lines into that file that should be a line like…
$ ./configure –disable-dependency-tracking –prefix=/Users/Skinnybill/Desktop/oxidizer_0_7_3_1/build_folder_for_flam3 –enable-shared

If it doesn't match that can you post it please.

Ok,
all that at least matches with the error messages, the question is why are we getting into that situation.
Basically what seems to be happening is that the jpeg and png libraries are not being installed into the build_folder_for_flam3 for some reason.

What I need you to do now is to open terminal and use the following commands.

cd /Users/Skinnybill/Desktop/oxidizer_0_7_3_1/libpng
make clean
make
make install

And post any errors that pop up or the results of the last step if they all work.

By the way if I'm teaching you to suck eggs with any of this stuff just let me know .

Dave

Hmmm, had to resort to google for that one, and a lot of reading between the lines.

Try this…

cd /Users/Skinnybill/Desktop/oxidizer_0_7_3_1/libpng
make clean

Now edit the Makefile in that directory. There you'll find a couple of lines like this

CFLAGS = -O -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch ppc -arch x86_64
LDFLAGS = -arch i386 -arch ppc -arch x86_64

Edit those to remove the -arch ppc

CFLAGS = -O -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64
LDFLAGS = -arch i386 -arch x86_64

then back on the command line

make

If that gets rid of the errors then run

make clean

in ../jpeg-8a and ../flam3 then back in XCode load the project, and in the tree view on the left open the Target tree and double-click on "Run Script" item. A window will pop up with a Script in it.

Edit the line

ARCH_FLAGS="-arch i386 -arch ppc -arch x86_64″

to remove -arch ppc

ARCH_FLAGS="-arch i386 -arch x86_64″

Close the window, that will save the script, and press the build button again and let me know what happens.

Dave

Hi,
Yes I knew about open, but it detaches the Application from the command line, which I didn't want to do.

The first question is did Oxidizer fall over from the command line ?

The next thing to check is what permissions are on the /Users/Skinnybill/Library/Application Support/Oxidizer
it should be rwx for the user.

Now let's try running directly in the debugger from the command line.

On the command line run

gdb /Users/Skinnybill/Desktop/oxidizer_0_7_3_1/build/Debug/Oxidizer.app/Contents/MacOS/Oxidizer

After a copyright and warranty message you should see…

This GDB was configured as "i386-apple-darwin"…Reading symbols for shared libraries ………….. done

(gdb)

at the prompt enter

run

and Oxidizer will start to run.

If Oxidizer fails, enter

bt

and post the output here.

It it works, I've got some homework to do to try and find out a why of working out exactly where it fails.

Dave

Hi,
The difference in output is due to me still being stuck on 32 bits :-)

Been on holiday so sorry for the lack of updates. I've been trying to think about how to get some debugging info. As the only debugging aid we've managed to get Oxidizer to fall over in is Instruments, it look like dtrace / dtruss is the only option.

As running dtrace / dtruss from the command line would mean running Oxidizer as root we'll dodge that for the time being and use Instruments, its not as friendly to describe on a forum but I'm sure we'll manage.

Start up instruments and choose the Blank template.
In the main window, choose the Instruments menu, and select the Build New Instrument menu item.
In the sheet that pops up change the Probe line so it looks like

Probe | Probe 1 | of type ( Objective-c )

by changing the drop down that says User Process to Objective-C

Under the "Record the following data" area
Change the second drop down to say 'Caller' then use the + button to
add two more options to Record the Module then Function.

Then Save.

Back in the main window, double click on the instrument we've just created .

In the Probe line chenge the 'entry' drop down to return, then proess the 'Save Copy' button

Choose the Oxidizer as the default target to to run, and then press the record button.

Oxidzer will slowly run (it took 4 minutes to start up here).

Once its crashed, click on the first instrument and scroll down the list of function calls. make sure it at the end as the list is very big and the scroll bar can look like it's at the end but it isn't.

select the last call then in the menu select the 'Extended Detail' item from the view menu. Another
view should be added to the window showing a stack trace. You can select the items on the stack trace
so select the whole thing and paste it here.

After that select the other instrument and do the same.

Dave