Bugzilla – Full Text Bug Listing
| Summary: | Main download page doesn't auto-detect 32 vs 64-bit Mac | ||
|---|---|---|---|
| Product: | Community | Reporter: | Milos Kleint <mkleint> |
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | darin.eclipse, david_williams, jeffmcaffer, kim.moir, nathan, remy.suen |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Milos Kleint
You Mac configuration is likely defaulting to a JRE that runs 64 bit mode by default. The eclipse launcher handles this with you run your 32 bit IDE but when you launch an app from inside Eclipse the 64 bit JRE will run. As youve seen, with a 32 bit target the JRE gets upset. Try adding -d32 to the VM Args of the launch configuration or product you are running. That tells the 64 bit JRE to run in 32 bit mode. Which download page are you offered the 32 bit version by default? I see that you can select the version you want to download on this page. http://www.eclipse.org/downloads/ yes, I can pick the correct one on that page. However when I click just the distribution name, I get the wrong one. I can reproduce this. on my 64bit snow leopard machine, simply clicking on Eclipse Classic on the download page gets 32 bit Cocoa. I suspect the main download page uses a PHP script to auto-detect your OS and it is not handling 32 vs. 64-bit Mac. This is an issue that i'm also trying to address for Windows 64. Currently we're doing our detection based on your user agent string from your browser. Could you folks post what your user agent strings are? Here's a handy url -> http://whatsmyuseragent.com/ This would help greatly in getting this bug fixed as i don't have a Mac to test on. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4 HTTP_CONNECTION:keep-alive HTTP_ACCEPT:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_CHARSET:ISO-8859-1,utf-8;q=0.7,*;q=0.3 HTTP_ACCEPT_ENCODING:gzip,deflate,sdch HTTP_ACCEPT_LANGUAGE:en-US,en;q=0.8 HTTP_HOST:whatsmyuseragent.com HTTP_USER_AGENT:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4 > Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4
> (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4
Is it just me, or does nothing in that string clearly identify a 32-bit or 64-bit browser?
is there a 32 bit version of 10_6_3? I think snow leopard is only 64 bit. (while leopard was only 32 bit) but i'm not entirely sure here.. (In reply to comment #8) > > Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4 > > (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4 > > Is it just me, or does nothing in that string clearly identify a 32-bit or > 64-bit browser? This is what i'm having an issue with for Windows 64-bit. The agent string is based on your browser. If you're using a 32-bit browser (Firefox only ships 32-bit versions) it will be reported as such. I'm thinking we may have to use Javascript to determine this more reliably. I may be wrong, but I think this bug is now invalid. When it was opened, there was a main download link which used the user-agent string to determine OS/platform. Now we use the user-agent string to determine OS only, and offer up 32-bit and 64-bit links (ie, we no longer attempt to auto-detect 32 or 64 bit platforms, and we shouldn't either, in the case of a user using a 32-bit browser on a 64-bit platform, or a 32-bit JRE on a 64-bit platform, etc). I'll close this as WONTFIX. Please reopen if my assessment is incorrect. |