What have you done with an early Intel recently?

[Amethyst1]

the early '09 Mini gives me the option of running Leopard should I ever need it.

I'd be very surprised if Leopard didn't run on the late 2009, given it's identical to the early 2009 apart from a slightly faster CPU I even got Leopard to boot on a late 2010 MBA.

 

[B S Magnet]

That's really strange. Initially I suspected that it might be an issue with your location or ISP but the fact that you also experience this difficulty with TOR as well is a mystery. Perhaps more knowledgeable members can shed some light on what's happening?

I had intended to show you that your MacBook is definitely on-topic here - thanks to its C2D CPU.

Sidebar: I completely forgot until last day that there were Core i5/i7 iMacs from 2009. By other metrics, 2009–10 would be “early Intel” in my mind, but discussions on them would not fall under the scope, at present, of this forum.

Were I to nominate for future scope of inclusion to this forum, I’d want to include the first three generations of Core iX Macs (i.e., Lynnfield, Sandy Bridge, and Ivy Bridge) — all pre-Haswell/4th gen — as “Early Intel Macs”. With Lynnfield and Sandy Bridge, there was a significant, 2 1/2-year sales overlap with late-era Core 2 Duo Macs (e.g., the late 2010 MacBook Airs, sold until mid-2011, and the mid-2010 MacBook, sold until 2012). Also, these were the Core iX generations which came pre-bundled with Snow Leopard, Lion, and Mountain Lion — all OS X builds which are topical to this forum.

[Sidebar of sidebar: I didn’t know until just… five minutes ago there was a short-lived, education-only MacBook Air model sold only for a short time in 2012, which was shipped with a Sandy Bridge Core i5. This is leaving me wondering whether one could successfully boot 10.6.8 on it.]

 

[Amethyst1]

I completely forgot until last day that there were Core i5/i7 iMacs from 2009.

Yep, the first 27" was available with both Core 2 Duo and i5/i7. Were I asked, I’d count both as being early enough to be "discussable" here.

Were I to nominate for future scope of inclusion to this forum, I’d want to include the first three generations of Core iX Macs (i.e., Lynnfield, Sandy Bridge, and Ivy Bridge) — all pre-Haswell/4th gen — as “Early Intel Macs”.

Totally agree. I'm not sure about the 2012 Retina MBPs since they're Ivy Bridge yet... well, not exactly early to me LOL.

Regarding 1st-gen Core iX, Macs shipped with:

• Arrandale (mobile i5/i7): 2010 15"/17" MacBook Pro
• Clarkdale (desktop i3): 2010 21.5" and 27" iMac
• Lynnfield (desktop i5/i7): 2009 and 2010 27" iMac

Also, these were the Core iX generations which came pre-bundled with Snow Leopard, Lion, and Mountain Lion — all OS X builds which are topical to this forum.

The Haswell iMac and MacBook Air came with Mountain Lion (10.8.4).

[Sidebar of sidebar: I didn’t know until just… five minutes ago there was a short-lived, education-only MacBook Air model sold only for a short time in 2012, which was shipped with a Sandy Bridge Core i5. This is leaving me wondering whether one could successfully boot 10.6.8 on it.]

Very likely. It's just a lower-specced 2011 model and 10.6.8 does boot on 2011 MBAs (I've done it on my 11"). It doesn't run quite perfectly though.

With Lynnfield and Sandy Bridge, there was a significant, 2 1/2-year sales overlap with late-era Core 2 Duo Macs

The 2010 MacBook Pro was also either a Core 2 Duo (13") or an i5/i7 (15"/17").

 

[theMarble]

I installed Mavericks on my 2006 17" MBP using NexPostFacto so that there is support for the X1600. It's a rather simple process but I definitely need to upgrade the RAM to 4GB as 2GB has been quite slow compared to Snow Leopard though SL seems to never slow down.

Turns out this old beast can edit 1080p video at a semi-reasonable speed aswell.

 

[Resiema]

Yesterday I installed my Newly-Acquired MacBook Pro 15" Late 2007, it was a little bit tough at the beginning because It doesn't wanted to erase My SSD that I installed. But after I took it out again and erased it with my Mac Pro and then cleaned the ports of the Hard Drive Connection a little bit (it was dusty), it started to install El Cap. (I maybe install Snow Leopard or Tiger some time later on it too)

And now I'm Installing Logic Studio 9 on it.

It's interesting how fast this thing is and btw it has a Green Dot so I don't need to Worry about any Graphics Issues.

 

[B S Magnet]

So... It may or may fit this thread, but a very gracious Discord member sent me a 2010 macpro for the cost of shipping (which wasn't cheap, and i added an extra $70 to that because it's a nice machine). Well holy hell is this thing fast. My core 2 duos i was using to build interweb/spiderweb/arcticfox etc usually took 1.5 to 2.5 hours per browser build. This machine just built InterWeb in less than 10 minutes!!!! This will make trouble shooting failed backports much quicker to track down and rebuild. I'm stoked.

View attachment 1786695

Oh, and here's an updated InterWeb (60.9.4) and SpiderWeb (2.2.3) made possible by this machine.

Cheers

@wicknix , may I ask you a couple of questions relating to setting up a proper build environment for Interweb?

The first question relates to extracting the tar of UXP into ‘/spiderweb-snow/mozilla’:

Should the contents inside the UXP directory be held in their own directory within mozilla/ (e.g., ‘/spiderweb-snow/mozilla/UXP-RELBASE_20210608’), or should the contents within that UXP-RELBASE… directory be added to the mozilla/ directory itself, thus overwriting contents (subdirectories, files) which share the same name?


The second question pans back a bit:

Is it possible to build Interweb as an x86_64 binary that will work on Snow Leopard (for Macs booted into the 64-bit kernel), but by building it in a Snow Leopard 10.6.8 environment (which has only the final Xcode SDKs for 10.6, along with the appropriate ports needed for the build environment)? Following a fatal error during the configure stage of ./mach build — “MacOS X 10.7 SDK or later is required” — I gather the sense this may not be possible. Indeed, as I recursively searched for appearances of “MacOSX10.7.sdk” in the /spiderweb-snow directory, there were at least three build files which specifically cite an expectation that the 10.7 SDK be present (see attached).

If these are questions you’re not able to answer, that’s OK. I figure you might have some applied experience here which could be instructive. Thanks!

 

[wicknix]

Well.... I'll try to clear up what i can.
1) There is no need to extract anything in to the /spiderweb-snow/mozilla directory. The modified 10.6 code is already there and ready to be compiled or updated with bug fixes, back ports, etc.
1.1) No UXP releases will build on 10.6. 10.7 is the minimum requirement. (and the last few UXP releases have had Mac code ripped from it, and eventually it'll all be removed unfortunately. You'll probably want to go back to 29.1.1 to archive that version as i believe it's the last Mac release before the code removal started).
2) Sure. Building a 64-bit version is entirely possible. Just remove the i386 parts in the included mozconfig and comment out the cross-compile line. However it'd still need to be built with the 10.7sdk as the 10.6sdk lacks too many frameworks (like CoreMedia).

Cheers

 

[B S Magnet]

Well.... I'll try to clear up what i can.
1) There is no need to extract anything in to the /spiderweb-snow/mozilla directory. The modified 10.6 code is already there and ready to be compiled or updated with bug fixes, back ports, etc.

Excellent and good to know, thank you.

1.1) No UXP releases will build on 10.6. 10.7 is the minimum requirement. (and the last few UXP releases have had Mac code ripped from it, and eventually it'll all be removed unfortunately. You'll probably want to go back to 29.1.1 to archive that version as i believe it's the last Mac release before the code removal started).

Which means disregarding that component of the README instructions would be fine here.

2) Sure. Building a 64-bit version is entirely possible. Just remove the i386 parts in the included mozconfig and comment out the cross-compile line. However it'd still need to be built with the 10.7sdk as the 10.6sdk lacks too many frameworks (like CoreMedia).

That very last part was what I was afraid of. At present, I have nothing around here running Lion. (It probably doesn’t help Lion’s case that I’ve never warmed to using it.)

I think I’ll table this build experiment until I get something with Lion running on it, then give it a go at that time.

Thanks again!

 

[wicknix]

I can build you a 64bit IW if you want that will run on 10.6. Or maybe you just want the whole experience of getting a dev environment set up and building stuff. Let me know and I'll whip out a 64bit build later today if needed.

Cheers

 

[B S Magnet]

I can build you a 64bit IW if you want that will run on 10.6. Or maybe you just want the whole experience of getting a dev environment set up and building stuff. Let me know and I'll whip out a 64bit build later today if needed.

Cheers

After replying to you last night, I tried being crafty and used Pacifist to extract the OSX10.7.sdk from Xcode 4.3.1 (I think) and stuffed that directory into the SDKs directory (alongside 10.5.sdk and 10.6.sdk), thinking that would be enough to make magic happen on 10.6.8. Then I remembered, after it failed again, that when the build relies on frameworks, it is literally going into /System/Library/Frameworks to find those header files. And of course, CoreMedia.framework isn’t a thing in 10.6.8. So I put it aside, foiled by my own inexperience.

My eventual goal is to have the build environment set up properly to compile things like, I don’t know, a browser, in and/or for 10.6.8 (now that I have a working A1261 to try out new things). In the meanwhile, as to your offer: if it doesn’t take up more than five minutes of your time to set and run a 64-bit compile of Interweb for 10.6, then I’d totally be down for testing that (and quite grateful to boot). But if it’s gonna take you longer than that, then don’t sweat it.

 

[wicknix]

I'm set up for multiarch (32/64bit), so just a quick edit to my mozconfig is all it'll take. I'll pump a 64bit build out tonight for ya.

You could always try just plopping the 10.7sdk in to /Developer/SDK next to the 10.6sdk. Then just tell xcode or mozconfig to use that sdk. That's how I use to build AF on 10.6 before I decided 10.7 made a better "all around" dev environment.

Cheers

 

[Wowfunhappy]

Does the last 10.6 version of xCode not come with the 10.7 SDK? I ask because the last 10.9 xCode comes with the 10.10 SDK, the last 10.13 one comes with the 10.14 SDK, etc

 

[wicknix]

@Wowfunhappy I don't recall. I believe the 10.6sdk came with 10.5sdk though. At any rate, you can grab any SDK from here.

@B S Magnet Yeah you have to edit configure.in to bypass the frameworks if they aren't available. Not the best idea. When building AF on 10.6 it will bypass CoreMedia and build (we added a configure switch to disable apple media), but the results are less than stellar. AF wont play most audio streams like shoutcast and such. Building with the 10.7sdk solves this. Anyway... here is your 64bit IW build to play around with.

Cheers

 

[B S Magnet]

@Wowfunhappy I don't recall. I believe the 10.6sdk came with 10.5sdk though. At any rate, you can grab any SDK from here.

@B S Magnet Yeah you have to edit configure.in to bypass the frameworks if they aren't available. Not the best idea. When building AF on 10.6 it will bypass CoreMedia and build (we added a configure switch to disable apple media), but the results are less than stellar. AF wont play most audio streams like shoutcast and such. Building with the 10.7sdk solves this. Anyway... here is your 64bit IW build to play around with.

Cheers

I’ll have to look this over once more. After I last posted, I went through the OSX10.7.sdk directory to, yes, find its own set of frameworks (including CoreMedia.framework). Which… then looking over the “mozcfg-interweb” file, seems to point correctly to the MacOSX10.7.sdk directory I brought over from Xcode 4.3.1 using Pacifist. I would think that would be sufficient (yes?) — unless there’s another pointer in another config-related file I’ve yet to pinpoint which points not to the /Developer/SDKs/MacOSX10.7.sdk/S/L/Frameworks directory, but to /S/L/Frameworks instead. I’ll keep looking!

But in the meanwhile, thank you generously for building a 64-bit Snow Leopard build of Interweb! I’ll give this a spin!

 

[wicknix]

No problem. You'll need a few adjustments to your mozconfig. Here's mine adjusted for the 64bit build:

export HOST_CC=/opt/local/bin/clang-mp-3.7
export HOST_CXX=/opt/local/bin/clang++-mp-3.7
#TARGET_CPU=i386
TARGET_CPU=x86_64
CC="clang -arch $TARGET_CPU"
CXX="clang++ -arch $TARGET_CPU"

# These must be set for cross builds, and don't hurt straight builds.
RANLIB="${TOOLCHAIN_PREFIX}ranlib"
AR="${TOOLCHAIN_PREFIX}ar"
AS=$CC
LD=ld
STRIP="${TOOLCHAIN_PREFIX}strip"
OTOOL="${TOOLCHAIN_PREFIX}otool"
export CC CXX HOST_CC HOST_CXX RANLIB AR AS LD STRIP OTOOL

#CROSS_COMPILE=1
#ac_add_options --target=i386-apple-darwin10.8.0
ac_add_options --enable-macos-target=10.7
ac_add_options --enable-application=browser
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.7.sdk
ac_add_options --disable-tests
ac_add_options --enable-optimize=-O2
ac_add_options --disable-debug
ac_add_options --disable-crashreporter
#ac_add_options --disable-updater
ac_add_options --disable-necko-wifi
ac_add_options --disable-safe-browsing
ac_add_options --disable-gamepad

export MOZ_TELEMETRY_REPORTING=0
export MOZ_ADDON_SIGNING=0
export MOZ_REQUIRE_SIGNING=0

Comment out the cross compile line, target= line and updater line. Changing or enabling those breaks the build process on my end for 64bit.

Cheers

 

[B S Magnet]

No problem. You'll need a few adjustments to your mozconfig. Here's mine adjusted for the 64bit build:

export HOST_CC=/opt/local/bin/clang-mp-3.7
export HOST_CXX=/opt/local/bin/clang++-mp-3.7
#TARGET_CPU=i386
TARGET_CPU=x86_64
CC="clang -arch $TARGET_CPU"
CXX="clang++ -arch $TARGET_CPU"

# These must be set for cross builds, and don't hurt straight builds.
RANLIB="${TOOLCHAIN_PREFIX}ranlib"
AR="${TOOLCHAIN_PREFIX}ar"
AS=$CC
LD=ld
STRIP="${TOOLCHAIN_PREFIX}strip"
OTOOL="${TOOLCHAIN_PREFIX}otool"
export CC CXX HOST_CC HOST_CXX RANLIB AR AS LD STRIP OTOOL

#CROSS_COMPILE=1
#ac_add_options --target=i386-apple-darwin10.8.0
ac_add_options --enable-macos-target=10.7
ac_add_options --enable-application=browser
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.7.sdk
ac_add_options --disable-tests
ac_add_options --enable-optimize=-O2
ac_add_options --disable-debug
ac_add_options --disable-crashreporter
#ac_add_options --disable-updater
ac_add_options --disable-necko-wifi
ac_add_options --disable-safe-browsing
ac_add_options --disable-gamepad

export MOZ_TELEMETRY_REPORTING=0
export MOZ_ADDON_SIGNING=0
export MOZ_REQUIRE_SIGNING=0

Comment out the cross compile line, target= line and updater line. Changing or enabling those breaks the build process on my end for 64bit.

Cheers

Update: it’s… compiling. Oddly, it is doing all this in a directory titled obj-i386-apple-darwin10.8.0.

But it’s compiling:

Update of update: First attempt failed with a mess of warnings along the way. I couldn’t figure out for the life of me why the build failed (after almost four hours… the joys of running half-speed on the MBP, without a battery). I went ahead, ditched the spiderweb-snow directory, untar’d the archive, and started over. This time, I happened to catch something I’d failed to see before: a “.mozconfig” hidden from a glance in Finder, but visible from a command line. This whole time I’d been only modifying the “mozconfig-interweb” file. The “.mozconfig” file is where I found the default i386 still showing, along with none of the commented-out lines you advised. Currently, the compile is running a lot less noisily, only the occasional warning from time to time, and it’s working from an x86_64 directory. 🤞 [fingers crossed]

 

[B S Magnet]

No problem. You'll need a few adjustments to your mozconfig. Here's mine adjusted for the 64bit build:

export HOST_CC=/opt/local/bin/clang-mp-3.7
export HOST_CXX=/opt/local/bin/clang++-mp-3.7
#TARGET_CPU=i386
TARGET_CPU=x86_64
CC="clang -arch $TARGET_CPU"
CXX="clang++ -arch $TARGET_CPU"

# These must be set for cross builds, and don't hurt straight builds.
RANLIB="${TOOLCHAIN_PREFIX}ranlib"
AR="${TOOLCHAIN_PREFIX}ar"
AS=$CC
LD=ld
STRIP="${TOOLCHAIN_PREFIX}strip"
OTOOL="${TOOLCHAIN_PREFIX}otool"
export CC CXX HOST_CC HOST_CXX RANLIB AR AS LD STRIP OTOOL

#CROSS_COMPILE=1
#ac_add_options --target=i386-apple-darwin10.8.0
ac_add_options --enable-macos-target=10.7
ac_add_options --enable-application=browser
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.7.sdk
ac_add_options --disable-tests
ac_add_options --enable-optimize=-O2
ac_add_options --disable-debug
ac_add_options --disable-crashreporter
#ac_add_options --disable-updater
ac_add_options --disable-necko-wifi
ac_add_options --disable-safe-browsing
ac_add_options --disable-gamepad

export MOZ_TELEMETRY_REPORTING=0
export MOZ_ADDON_SIGNING=0
export MOZ_REQUIRE_SIGNING=0

Comment out the cross compile line, target= line and updater line. Changing or enabling those breaks the build process on my end for 64bit.

Cheers

Hours later…

Well, it built. As SpiderWeb. The version number threw me for a loop. But it built.

 

[wicknix]

Ahh thanks for the reminder. I need to upload the current sources. 2.2.2 is 1 version behind my current release.

Now the confusing part....
SpiderWeb builds comm style (outside of the /Mozilla directory like seamonkey does)
To clean your build, run ./mach clobber && rm configure.

To build interweb copy your .mozconfig to /Mozilla and build from inside the /Mozilla directory.

Cheers

 

[B S Magnet]

Ahh thanks for the reminder. I need to upload the current sources. 2.2.2 is 1 version behind my current release.

Now the confusing part....
SpiderWeb builds comm style (outside of the /Mozilla directory like seamonkey does)
To clean your build, run ./mach clobber && rm configure.

To build interweb copy your .mozconfig to /Mozilla and build from inside the /Mozilla directory.

Cheers

So I proceeded to try this method to build Interweb, when I hit my first barrier:

 0:14.35   --enable-macos-target=10.6
 0:14.35   --enable-application=projects/navigator
 0:14.35   --with-macos-sdk=/Developer/SDKs/MacOSX10.7.sdk
 0:14.35   --disable-tests
 0:14.35   --enable-optimize=-O2
 0:14.35   --disable-debug
 0:14.35   --disable-crashreporter
 0:14.35   --disable-necko-wifi
 0:14.36   --disable-safe-browsing
 0:14.36   --disable-gamepad
 0:14.36   OTOOL=otool
 0:14.36   LD=ld
 0:14.36   MOZ_TELEMETRY_REPORTING=0
 0:14.36   CC=clang -arch x86_64
 0:14.36   MOZ_ADDON_SIGNING=0
 0:14.36   MOZ_REQUIRE_SIGNING=0
 0:14.36   RANLIB=ranlib
 0:14.37   CXX=clang++ -arch x86_64
 0:14.37   AS=clang -arch x86_64
 0:14.37   AR=ar
 0:14.37   STRIP=strip
 0:14.37   HOST_CC=/opt/local/bin/clang-mp-3.7
 0:14.37   HOST_CXX=/opt/local/bin/clang++-mp-3.7
 0:14.37   TARGET_CPU=x86_64
 0:14.45 ERROR: Cannot find project projects/navigator
 0:14.49 *** Fix above errors and then restart with\
 0:14.49                "/opt/local/bin/gmake -f client.mk build"
 0:14.49 gmake: *** [client.mk:379: configure] Error 1

No problem! I copied over the navigator directory from root level. (I suppose I could have also symlinked it).

Next run:

IOError: [Errno 2] No such file or directory: u'/Users/foo/Downloads/spiderweb-snow/mozilla/mozilla/toolkit/moz.configure'
*** Fix above errors and then restart with\
               "/opt/local/bin/gmake -f client.mk build"
gmake[2]: *** [/Users/foo/Downloads/spiderweb-snow/mozilla/client.mk:379: configure] Error 1
gmake[2]: Leaving directory '/Users/foo/Downloads/spiderweb-snow/mozilla'
gmake[1]: *** [/Users/foo/Downloads/spiderweb-snow/mozilla/client.mk:392: /Users/foo/Downloads/spiderweb-snow/mozilla/obj-x86_64-apple-darwin10.8.0/Makefile] Error 2
gmake[1]: Leaving directory '/Users/foo/Downloads/spiderweb-snow/mozilla'
gmake: *** [client.mk:170: build] Error 2

No problem! I symlinked the mozilla directory from root level (copying would have taken time).

Next run, 3 hours later:

gmake[4]: Leaving directory '/Users/foo/Downloads/spiderweb-snow/obj-x86_64-apple-darwin10.8.0/projects/navigator/app'
gmake[3]: Leaving directory '/Users/foo/Downloads/spiderweb-snow/obj-x86_64-apple-darwin10.8.0'
gmake[2]: Leaving directory '/Users/foo/Downloads/spiderweb-snow/obj-x86_64-apple-darwin10.8.0'
if test -d dist/bin ; then touch dist/bin/.purgecaches ; fi
gmake[1]: Leaving directory '/Users/foo/Downloads/spiderweb-snow/obj-x86_64-apple-darwin10.8.0'

Hurrah! I go to the obj-x86_64-apple-darwin10.8.0 directory:

Oh no! What happened?

I go up a level to root and noticed the same-named directory has a modify time around when the build finished:

SpiderWeb? Again?

OK, so that symlink of the mozilla directory sent all the activity (I think) to the root level and built from there.

But clearly I did something wrong.

 

[swamprock]

Installed Elementary OS "Hera" on my Macbook2,1. Digging it

 

[Eithanius]

2010 MBP 15" here, relegated to crunching duties 24/7 ever since I got my M1 MBA earlier this year. Battery was swollen and has been removed so CPU is throttled just nice enough without having to worry about overheating nor noisy spinning fans. Currently running on Mojave even though it officially maxed out at High Sierra. Maybe at some point in the future will restore it back to Snow Leopard, provided I can find replacement SL discs - the bundled discs no longer readable.



77 days uptime and counting...

 

[wicknix]

But clearly I did something wrong.

Yes, and no. Heh. There is no need to symlink, or copy anything over anything. The extracted source directory has everything needed to build both spiderweb and interweb. As mentioned Spiderweb is built from outside of the the /mozilla directory. Interweb is built from inside the /mozilla directory. I noticed one mistake. Your mozconfig is set to build spiderweb, not interweb. The --enable-application=/projects/navigator = spiderweb, you want --enable-application=browser instead for interweb.

To clarify a bit more....
To build spiderweb extract the source archive then cd ~/path/to/spiderweb-snow
Adjust the default .mozconfig if needed for 64bit vs the 32bit default.

To build interweb, cd ~/path/to/spiderweb-snow/mozilla
Copy your .mozconfig to that directory and change --enable-application=browser (instead of =/projects/navigator)

Cheers

 

[B S Magnet]

Yes, and no. Heh. There is no need to symlink, or copy anything over anything. The extracted source directory has everything needed to build both spiderweb and interweb. As mentioned Spiderweb is built from outside of the the /mozilla directory. Interweb is built from inside the /mozilla directory. I noticed one mistake. Your mozconfig is set to build spiderweb, not interweb. The --enable-application=/projects/navigator = spiderweb, you want --enable-application=browser instead for interweb.

To clarify a bit more....
To build spiderweb extract the source archive then cd ~/path/to/spiderweb-snow
Adjust the default .mozconfig if needed for 64bit vs the 32bit default.

To build interweb, cd ~/path/to/spiderweb-snow/mozilla
Copy your .mozconfig to that directory and change --enable-application=browser (instead of =/projects/navigator)

Cheers

AH! that --enable-application=browser flag is the part I was missing! (and by now, it should be apparent that none of this comes naturally for me.) Thank you!

Currently:

 

[wicknix]

No prob. You'll be a seasoned vet by the time you are done.

 

[Tratkazir_the_1st]

BTW, how long it takes to compile browser? (Asking as gentoo user ).