Home » Eclipse Projects » Rich Client Platform (RCP) » 32-bit and 64-bit fat binaries on the Mac
| 32-bit and 64-bit fat binaries on the Mac [message #487443] |
Wed, 23 September 2009 09:45  |
Eclipse User |
|
|
|
Originally posted by: jppellet.gmail.com
Hi,
I'm about to distribute the Mac version of my RCP app, for which I have
native libraries compiled for both x86 and x86_64. Everything works
fine when I create two separate versions of my app -- one for x86 and
another one for x86_64. What I would like to do, however, is create a
single, well-behaved Mac app, which can start in both 32-bit and 64-bit
modes.
Can I do this, or should I open a bug requesting it?
BTW, it would be great that the Cocoa version of Eclipse behaves like
this as well.
And another question on the side: I'm highly unfamiliar with Windows
64-bit issues. Once I package a 64-bit RCP app, it will only run on a
64-bit Windows, right? Can a 64-bit Windows run a 32-bit RCP app?
Thanks,
J.-P.
|
|
|
| Re: 32-bit and 64-bit fat binaries on the Mac [message #487520 is a reply to message #487443] |
Wed, 23 September 2009 13:58  |
 Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
Hi,
If your app does not require JRE 1.6 then you could just release your 32-bit
version, as it will work on 64-bit OS X as well (add launcher VM arg -d32 to
ensure that a 32-bit JRE is used). If your app does require JRE 1.6 then
doing this will only work on OSX 10.6, because the JRE 1.6 implementation on
OS X 10.5 is 64-bit only. The eclipse/rcp launcher does not currently
provide a way to load libraries based on the detected architecture, so I
don't think there's a single-app solution that would work on OS X 10.5 if
JRE 1.6 is needed. The existing request for this is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=266576 .
On the Windows side, you can just distribute a 32-bit version of your app,
and it will work on 64-bit Windows as long as a 32-bit JRE is used.
Grant
"J.-P. Pellet" <jppellet@gmail.com> wrote in message
news:h9cqo9$ngu$1@build.eclipse.org...
> Hi,
>
> I'm about to distribute the Mac version of my RCP app, for which I have
> native libraries compiled for both x86 and x86_64. Everything works
> fine when I create two separate versions of my app -- one for x86 and
> another one for x86_64. What I would like to do, however, is create a
> single, well-behaved Mac app, which can start in both 32-bit and 64-bit
> modes.
>
> Can I do this, or should I open a bug requesting it?
>
> BTW, it would be great that the Cocoa version of Eclipse behaves like
> this as well.
>
> And another question on the side: I'm highly unfamiliar with Windows
> 64-bit issues. Once I package a 64-bit RCP app, it will only run on a
> 64-bit Windows, right? Can a 64-bit Windows run a 32-bit RCP app?
>
> Thanks,
> J.-P.
>
|
|
|
| Re: 32-bit and 64-bit fat binaries on the Mac [message #487534 is a reply to message #487520] |
Wed, 23 September 2009 14:30 |
| Eclipse User |
|
|
|
Originally posted by: jppellet.gmail.com
Hi Grant,
Thanks for the explanation. I have to provide a 64-bit version as well,
as the native C++ part of the app must be able to address a lot of RAM
(huge files must be able to be loaded).
I suppose an intermediate solution (on the Mac) would be to provide two
separate .app application bundles, say "App (32-bit).app" and "App
(64-bit).app" that both use the same plugin and feature folders. In
plugins I'd put both the 32-bit and 64-bit fragments.
One could even write a tiny Cocoa wrapper that would launch one
executable or the other, depending on its own detected architecture or
user setting in the Finder's Get Info window. Both the executables and
the plugins/features/configuration/etc. folders could be hidden in the
new wrapper app bundle. Does this sound feasible to you, or would there
be obvious conflicts of some kind?
Cheers,
J.-P.
> Hi,
>
> If your app does not require JRE 1.6 then you could just release your 32-bit
> version, as it will work on 64-bit OS X as well (add launcher VM arg -d32 to
> ensure that a 32-bit JRE is used). If your app does require JRE 1.6 then
> doing this will only work on OSX 10.6, because the JRE 1.6 implementation on
> OS X 10.5 is 64-bit only. The eclipse/rcp launcher does not currently
> provide a way to load libraries based on the detected architecture, so I
> don't think there's a single-app solution that would work on OS X 10.5 if
> JRE 1.6 is needed. The existing request for this is
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=266576 .
>
> On the Windows side, you can just distribute a 32-bit version of your app,
> and it will work on 64-bit Windows as long as a 32-bit JRE is used.
>
> Grant
|
|
|
| Re: 32-bit and 64-bit fat binaries on the Mac [message #487578 is a reply to message #487534] |
Wed, 23 September 2009 16:01 |
Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
J.P.,
The simplest thing might just be to modify the eclipse launcher code and
compile the launcher yourself (and submit the patch on the bug :) ).
All we need is the launcher itself to choose the correct launcher.so
shared library in the correct launcher fragment and you just include
both fragments.
Look at eclipseCommon.c and the initialization of the osArchArg
variable. Currently there are ifdefs to set for ppc vs x86 based on
endian-ness. Adding another for 64 bit should be all that is required.
(And of course, modify the makefile to compile all the platforms into
one binary).
Of course this says nothing about what happens when we get into java.
p2 currently only installs for a particular platform (ie x86, ppc or
x86_64), what you really need is a superset of all the platforms, you
currently can't manage and update this with p2.
-Andrew
* dev.eclipse.org
/cvsroot/rt/org.eclipse.equinox/framework/bundles/org.eclips e.equinox.executable
J.P. Pellet wrote:
> Hi Grant,
>
> Thanks for the explanation. I have to provide a 64-bit version as well,
> as the native C++ part of the app must be able to address a lot of RAM
> (huge files must be able to be loaded).
>
> I suppose an intermediate solution (on the Mac) would be to provide two
> separate .app application bundles, say "App (32-bit).app" and "App
> (64-bit).app" that both use the same plugin and feature folders. In
> plugins I'd put both the 32-bit and 64-bit fragments.
>
> One could even write a tiny Cocoa wrapper that would launch one
> executable or the other, depending on its own detected architecture or
> user setting in the Finder's Get Info window. Both the executables and
> the plugins/features/configuration/etc. folders could be hidden in the
> new wrapper app bundle. Does this sound feasible to you, or would there
> be obvious conflicts of some kind?
>
> Cheers,
> J.-P.
>
>> Hi,
>>
>> If your app does not require JRE 1.6 then you could just release your
>> 32-bit
>> version, as it will work on 64-bit OS X as well (add launcher VM arg
>> -d32 to
>> ensure that a 32-bit JRE is used). If your app does require JRE 1.6 then
>> doing this will only work on OSX 10.6, because the JRE 1.6
>> implementation on
>> OS X 10.5 is 64-bit only. The eclipse/rcp launcher does not currently
>> provide a way to load libraries based on the detected architecture, so I
>> don't think there's a single-app solution that would work on OS X 10.5 if
>> JRE 1.6 is needed. The existing request for this is
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=266576 .
>>
>> On the Windows side, you can just distribute a 32-bit version of your
>> app,
>> and it will work on 64-bit Windows as long as a 32-bit JRE is used.
>>
>> Grant
>
|
|
|
| Re: 32-bit and 64-bit fat binaries on the Mac [message #487590 is a reply to message #487578] |
Wed, 23 September 2009 16:35 |
| Eclipse User |
|
|
|
Originally posted by: jppellet.gmail.com
Hi Andrew,
I'll gladly try to do so. Looks like I'm unable to get the source code
for the launcher, through; can't set cvs or svn checkout to work. For
instance:
svn co
svn://dev.eclipse.org/svnroot/rt/org.eclipse.equinox/framewo rk/bundles/org.eclipse.equinox.executable
->
svn: No repository found in
' svn://dev.eclipse.org/svnroot/rt/org.eclipse.equinox/framewo rk/bundles/org.eclipse.equinox.executable'
Can
you help me? Sorry for the very basic question…
J.-P.
> J.P.,
> The simplest thing might just be to modify the eclipse launcher code
> and compile the launcher yourself (and submit the patch on the bug :) ).
>
> All we need is the launcher itself to choose the correct launcher.so
> shared library in the correct launcher fragment and you just include
> both fragments.
>
> Look at eclipseCommon.c and the initialization of the osArchArg
> variable. Currently there are ifdefs to set for ppc vs x86 based on
> endian-ness. Adding another for 64 bit should be all that is required.
> (And of course, modify the makefile to compile all the platforms into
> one binary).
>
> Of course this says nothing about what happens when we get into java.
> p2 currently only installs for a particular platform (ie x86, ppc or
> x86_64), what you really need is a superset of all the platforms, you
> currently can't manage and update this with p2.
>
> -Andrew
>
> * dev.eclipse.org
> /cvsroot/rt/org.eclipse.equinox/framework/bundles/org.eclips e.equinox.executable
>
|
|
| | |
| Re: 32-bit and 64-bit fat binaries on the Mac [message #487628 is a reply to message #487578] |
Wed, 23 September 2009 19:48 |
| Eclipse User |
|
|
|
Originally posted by: jppellet.gmail.com
Indeed, the modification is quite simple. At some point, the launcher
fragment name is determined, by appending os.ws.arch to
"org.eclise.equinox.launcher". And actually, for the Mac, .arch is only
added when arch is "x86_64", as both ppc and i386/x86 were also in the
past compiled as fat/universal binaries into the same
org.eclise.equinox.launcher.macosx.carbon or
org.eclise.equinox.launcher.macosx.cocoa folder. So compiling all three
architectures into the eclipse executable and shared library plus
omitting the .arch extension is all that is required (and I guess it
only makes sense for Cocoa, as we're not going to have 64-bit Carbon
anyway).
(Formally, I suppose we should modify the fragment's manifest to tell
it that it also supports x86_64, although the manifest is simply
ignored by the native launcher… Anything else we should do in order to
be "clean"?)
Now, from the Finder's Get Info window, we can make Eclipse start as
PPC in Rosetta, or Intel 32 or 64 bit, and the shared library loads
normally.
Now, please tell me if I'm wrong: I was under the impression that most
things the native launcher does, the Java launcher does as well, so
that both launchers have to be modified similarly. Is it true? In that
case, we should also not append .arch in the Java launcher…
I suspect that things are not so easy when we get into Java, and we
need more testing, in particular on earlier versions of Mac OS X (I'm
using 10.6.1). Maybe some more checks about system version, Java
version, and availability of 32/64-bit Java on the current system.
Where would that kind of things be done? And other than that, should
other elements be changed outside of org.eclipse.equinox.launcher?
Thanks a lot for your help!
J.-P.
On 2009-09-23 18:01:03 +0200, Andrew Niefer <aniefer@ca.ibm.com> said:
> J.P.,
> The simplest thing might just be to modify the eclipse launcher code
> and compile the launcher yourself (and submit the patch on the bug :) ).
>
> All we need is the launcher itself to choose the correct launcher.so
> shared library in the correct launcher fragment and you just include
> both fragments.
>
> Look at eclipseCommon.c and the initialization of the osArchArg
> variable. Currently there are ifdefs to set for ppc vs x86 based on
> endian-ness. Adding another for 64 bit should be all that is required.
> (And of course, modify the makefile to compile all the platforms into
> one binary).
>
> Of course this says nothing about what happens when we get into java.
> p2 currently only installs for a particular platform (ie x86, ppc or
> x86_64), what you really need is a superset of all the platforms, you
> currently can't manage and update this with p2.
>
> -Andrew
|
|
|
| Re: 32-bit and 64-bit fat binaries on the Mac [message #488094 is a reply to message #487628] |
Fri, 25 September 2009 14:23 |
Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
There is java code in Eclipse (Main, build, p2, maybe other places) that
have special cases for the "macosx.x86_64" vs just "macosx". To avoid
having to find and change all these, it would be simplest to still have
2 shared libraries in their respective fragments.
As long as the executable itself has all three platforms, I don't know
if there is much to gain from merging the shared libraries as well.
-Andrew
J.P. Pellet wrote:
> Indeed, the modification is quite simple. At some point, the launcher
> fragment name is determined, by appending os.ws.arch to
> "org.eclise.equinox.launcher". And actually, for the Mac, .arch is only
> added when arch is "x86_64", as both ppc and i386/x86 were also in the
> past compiled as fat/universal binaries into the same
> org.eclise.equinox.launcher.macosx.carbon or
> org.eclise.equinox.launcher.macosx.cocoa folder. So compiling all three
> architectures into the eclipse executable and shared library plus
> omitting the .arch extension is all that is required (and I guess it
> only makes sense for Cocoa, as we're not going to have 64-bit Carbon
> anyway).
>
> (Formally, I suppose we should modify the fragment's manifest to tell it
> that it also supports x86_64, although the manifest is simply ignored by
> the native launcher… Anything else we should do in order to be "clean"?)
>
> Now, from the Finder's Get Info window, we can make Eclipse start as PPC
> in Rosetta, or Intel 32 or 64 bit, and the shared library loads normally.
>
> Now, please tell me if I'm wrong: I was under the impression that most
> things the native launcher does, the Java launcher does as well, so that
> both launchers have to be modified similarly. Is it true? In that case,
> we should also not append .arch in the Java launcher…
>
> I suspect that things are not so easy when we get into Java, and we need
> more testing, in particular on earlier versions of Mac OS X (I'm using
> 10.6.1). Maybe some more checks about system version, Java version, and
> availability of 32/64-bit Java on the current system. Where would that
> kind of things be done? And other than that, should other elements be
> changed outside of org.eclipse.equinox.launcher?
>
> Thanks a lot for your help!
>
> J.-P.
>
> On 2009-09-23 18:01:03 +0200, Andrew Niefer <aniefer@ca.ibm.com> said:
>
>> J.P.,
>> The simplest thing might just be to modify the eclipse launcher code
>> and compile the launcher yourself (and submit the patch on the bug :) ).
>>
>> All we need is the launcher itself to choose the correct launcher.so
>> shared library in the correct launcher fragment and you just include
>> both fragments.
>>
>> Look at eclipseCommon.c and the initialization of the osArchArg
>> variable. Currently there are ifdefs to set for ppc vs x86 based on
>> endian-ness. Adding another for 64 bit should be all that is
>> required. (And of course, modify the makefile to compile all the
>> platforms into one binary).
>>
>> Of course this says nothing about what happens when we get into java.
>> p2 currently only installs for a particular platform (ie x86, ppc or
>> x86_64), what you really need is a superset of all the platforms, you
>> currently can't manage and update this with p2.
>>
>> -Andrew
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:45:14 GMT 2024
Powered by FUDForum. Page generated in 0.03755 seconds |
] 
Search
Help
Register
Login
Home
