Compiling Qemu problems.

[666sheep]

Originally Posted by justperry

I don't think I agree here (politely), there is a fix which works for some people by mapping the Memory in Open Firmware, some got lucky, not me though.

Here is the link to that fix.

I could try to what you say but I am in Indonesia now and I do not have access to either a heat gun nor an oven.

I know this article, but one thing is against logic there: if it would be firmware issue, all PBs with certain firmware would be affected and it should happen right after update to this particular version.
Apple would rather release firmware update instead of this.

Second, these commands are only faking OF to "think", that there is RAM installed. If OS will start to use this "ghost" memory, it will crash, freeze or KP.

BTW, in similar way you can disable faulty soldered-in memory in iBooks and 12" PBs.

I've read some about this issue long ago and found few reports of users who fixed it with hot air. Even on MR was an old thread with such report AFAIR.

[Wildy]

git pull

should be in every version of git - it is, after all, one of the most common functions of git.

What is the output of

whereis xcodebuild

? If you have Xcode installed then you can cheat by simply creating a symlink to wherever Xcode utils are installed

sudo ln -s {location of xcodebuild} /usr/bin/xcodebuild

.

[MisterKeeks]

Originally Posted by rabidz7

If the emulator builds it should be able to run mountain lion.

No, you are wrong. It would be ridiculously slow if it runs at all which is extremely, extremely, extremely unlikely. Just because it can emulate a certain Intel processor does not mean it can emulate any Windows OS.

[rabidz7]

Originally Posted by MisterKeeks

No, you are wrong. It would be ridiculously slow if it runs at all which is extremely, extremely, extremely unlikely. Just because it can emulate a certain Intel processor does not mean it can emulate any Windows OS.

Sure it will be slow. But in theory it should work. Mac osx will run on any x86 cpu.

[justperry]

Originally Posted by 666sheep

I know this article, but one thing is against logic there: if it would be firmware issue, all PBs with certain firmware would be affected and it should happen right after update to this particular version.
Apple would rather release firmware update instead of this.

Second, these commands are only faking OF to "think", that there is RAM installed. If OS will start to use this "ghost" memory, it will crash, freeze or KP.

BTW, in similar way you can disable faulty soldered-in memory in iBooks and 12" PBs.

I've read some about this issue long ago and found few reports of users who fixed it with hot air. Even on MR was an old thread with such report AFAIR.

I got exactly what you say, as soon as it gets into the now allocated lower RAM memory the OS crashes, I gave up long ago.
When I got it a few years ago it was still working but soon thereafter it stopped working.
You're probable right, hardware failure.
I just live with it.

Originally Posted by Wildy

git pull

should be in every version of git - it is, after all, one of the most common functions of git.

What is the output of

whereis xcodebuild

? If you have Xcode installed then you can cheat by simply creating a symlink to wherever Xcode utils are installed

sudo ln -s {location of xcodebuild} /usr/bin/xcodebuild

.

Might be because this is an older PPC git version, 1.77.4 or something like this, Command pull is not found, I looked it up and it replaces fetch and merge so it must have been in the later versions that it was included.

git pull
git: 'pull' is not a git command. See 'git --help'.

Did you mean this?
shell


I have Xcode installed and it points to /usr/bin/xcodebuild, the problem is I need a newer version, minimum 3.1 as far as I recall.
Shame there is no simple update, just a complete install from Apple's developer pages.

[Wildy]

Ah ok, that is a shame. I'm afraid (as you mentioned), the only way is a complete install. I have MacPorts installed on my PowerBook, so I can try building QEMU for you if you want - but if you have an older Xcode, it is possible you have an older version of GCC/libc which may not work with my binary.

Oh, the other thing... last time I looked, Q has a bin folder which just has all the QEMU binaries in it for each architecture. You should be able to take the newly built QEMU binaries and drop them straight in!

[justperry]

Originally Posted by Wildy

Ah ok, that is a shame. I'm afraid (as you mentioned), the only way is a complete install. I have MacPorts installed on my PowerBook, so I can try building QEMU for you if you want - but if you have an older Xcode, it is possible you have an older version of GCC/libc which may not work with my binary.

Oh, the other thing... last time I looked, Q has a bin folder which just has all the QEMU binaries in it for each architecture. You should be able to take the newly built QEMU binaries and drop them straight in!

Don't think that will work, I have MacPorts too but the problem is it needs the newer Xcode, if you would compile that on your Powerbook it will most likely not work on mine.
In about two weeks time I am in Singapore, lots of free internet there, just download Xcode there.
But, after all that work it might all be for nothing, the version I have now doesn't really work, I'm afraid this one won't either, but I'll find out soon, more like a hobby project.

[Wildy]

All the MacPorts are configured to be compiled with some GCC version, x. Like we have both said, it's probable that it won't work for you. When you get the bandwidth and upgrade your Xcode you are welcome to use my QEMU binary, I shall post it here along with performance improvements (if any).

Enjoy your trip to Singapore - I am jealous!


It's going to be a long night

[Wildy]

QEMU finished compiling a while ago - testing it out now - will post the binary in a bit...

In the one test I did, without any configuration or controlled environment, the new binary seemed to be about 8% faster.

Just did a quick CPU-bound Whetstone benchmark using TinyCore. The benchmark is in Lua because that was the easiest thing to install.

Qemu 1.3.0

Running time: 64.43
Working memory: 28 Kbyte
Kwips (kilo-Whetstone Instructions for seconds): 15.52

Qemu 0.9.1

Running time: 69.43
Working memory:  28 Kbyte
Kwips (kilo-Whetstone Instructions for seconds): 14.40

Reference system (2.00 GHz Core 2 Duo)

Running time: 19.32
Working memory: 928 Kbyte
Kwips (kilo-Whetstone Instructions for seconds): 51.77

[MisterKeeks]

Originally Posted by rabidz7

Sure it will be slow. But in theory it should work. Mac osx will run on any x86 cpu.

What is true in theory is not always true in practice. For example, Intel Macs use EFI, the emulator probably doesn't (in favor of BIOS). That is a major roadblock right there.

Anyway, there really is no point in doing it when it takes days to boot.

[justperry]

Originally Posted by Wildy

QEMU finished compiling a while ago - testing it out now - will post the binary in a bit...

In the one test I did, without any configuration or controlled environment, the new binary seemed to be about 8% faster.

Just did a quick CPU-bound Whetstone benchmark using TinyCore. The benchmark is in Lua because that was the easiest thing to install.

Qemu 1.3.0

Running time: 64.43
Working memory: 28 Kbyte
Kwips (kilo-Whetstone Instructions for seconds): 15.52

Qemu 0.9.1

Running time: 69.43
Working memory:  28 Kbyte
Kwips (kilo-Whetstone Instructions for seconds): 14.40

Reference system (2.00 GHz Core 2 Duo)

Running time: 19.32
Working memory: 928 Kbyte
Kwips (kilo-Whetstone Instructions for seconds): 51.77

How big is it in MB, if it's not to big I would like to try it out.

Cheers Perry

[Wildy]

I have a 4.4 MB archive which contains the i386 and x86-64 binaries along with all the bios blobs which you need to get it running. If you need any of the dynamic libraries to get it running then I can provide whichever ones you need also.

https://dl.dropbox.com/u/92600387/qe...ld/qemu.tar.gz

[goMac]

Originally Posted by rabidz7

Sure it will be slow. But in theory it should work. Mac osx will run on any x86 cpu.

Not true. It needs some specific CPU features that not all x86 CPUs have. It will run on any modern CPU, not necessarily what QEMU can run. It's not going to run at all on a Pentium 3, for example.

[Wildy]

This conversation is largely pointless as we know that OSX would be so slow running under emulation that it would be no use.

Technically it really isn't that difficult to get OSX up and running. Disable ACPI, use a special bootloader to circumnavigate the EFI issue, set CPU arch to x86_64, set CPU type to a model which supports all the latest bells and whistles (SSE etc.), patch the DSDT and install some custom kexts for anything which doesn't work.

[justperry]

Originally Posted by Wildy

I have a 4.4 MB archive which contains the i386 and x86-64 binaries along with all the bios blobs which you need to get it running. If you need any of the dynamic libraries to get it running then I can provide whichever ones you need also.

https://dl.dropbox.com/u/92600387/qe...ld/qemu.tar.gz

It says this with all of the included binaries

dyld: Library not loaded: /opt/local/lib/libgthread-2.0.0.dylib
Referenced from: /usr/local/bin/qemu....
Reason: image not found

[Wildy]

Alright, this is where we get into shaky ground.

Here you go (12KB) - needs to go in /opt/local/lib.

[justperry]

Originally Posted by Wildy

Alright, this is where we get into shaky ground.

Here you go (12KB) - needs to go in /opt/local/lib.

Yep, did not work.


dyld: Library not loaded: /opt/local/lib/libgthread-2.0.0.dylib
Referenced from: /usr/local/bin/qemu-system-i386
Reason: no suitable image found. Did find:
/opt/local/lib/libgthread-2.0.0.dylib: unknown file type, first eight bytes: 0x3F 0x92 0x9C 0xEB 0x12 0x0D 0x06 0x10
Trace/BPT trap
logout

I copied the text from your link, then pasted it in Hexedit, save it as libgthread-2.0.0.dylib and then used XRay to set creator and permissions as needed.

[Wildy]

That is strange that it's giving you that error. The first bytes are designated as the 'Magic number' to identify the filetype.

But yes, I don't think this is going to work unless you have the correct libraries installed. Sorry.

[justperry]

Originally Posted by Wildy

That is strange that it's giving you that error. The first bytes are designated as the 'Magic number' to identify the filetype.

But yes, I don't think this is going to work unless you have the correct libraries installed. Sorry.

Don't be sorry, you tried to help but the both of already knew it probably wouldn't work.

It was worth the try.
In two weeks I'll have access to faster internet, problem is, I normally don't take my laptop to SG, just another few Kg to take and I like to travel as light as I can.

Cheers

[MisterKeeks]

Originally Posted by Wildy

This conversation is largely pointless as we know that OSX would be so slow running under emulation that it would be no use.

Technically it really isn't that difficult to get OSX up and running. Disable ACPI, use a special bootloader to circumnavigate the EFI issue, set CPU arch to x86_64, set CPU type to a model which supports all the latest bells and whistles (SSE etc.), patch the DSDT and install some custom kexts for anything which doesn't work.

After that, wait for a day or two and it might boot!

[justperry]

I downloaded Developer tools in Singapore, downloaded 3.1.4 and still asks for theother software above.

But, I don't really have to care anymore, bought a Mac Mini in Singapore so I can run Windows natively.

Stupid me though, I bought a mini after downloading Dev. Tools, should have downloaded the latast Dev. Tools.

[Wildy]

Hehe, hindsight is a bitch!