Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » The Future - ARM CPU's(Eclipse support if Mac's switch from Intel )
The Future - ARM CPU's [message #1827336] Wed, 13 May 2020 09:18 Go to next message
David Garratt is currently offline David GarrattFriend
Messages: 42
Registered: July 2011
Member
A few weeks back I looked for the latest release of Eclipse on a Raspberry Pi and concluded there was nothing newer than version 3.x

With all the rumours about Apple switching to their own risk CPU's what does this mean for Eclipse in the future and that platform - or indeed any non-Intel CPU?

If it's unlikely to be ported I might consider getting a Linux laptop when I'm next updating.

Sorry if this is the wrong forum group - there are so many to choose from.
Re: The Future - ARM CPU's [message #1827448 is a reply to message #1827336] Thu, 14 May 2020 15:51 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
Have a look at a similar question on the platform-dev mailing list:
https://www.eclipse.org/lists/platform-dev/msg01891.html
Re: The Future - ARM CPU's [message #1827459 is a reply to message #1827448] Thu, 14 May 2020 22:26 Go to previous messageGo to next message
Nitin Dahyabhai is currently offline Nitin DahyabhaiFriend
Messages: 4430
Registered: July 2009
Senior Member

Fedora for ARM has been building recent releases for years at this point.

_
Nitin Dahyabhai
Eclipse Web Tools Platform
Re: The Future - ARM CPU's [message #1827463 is a reply to message #1827336] Fri, 15 May 2020 01:37 Go to previous messageGo to next message
David Garratt is currently offline David GarrattFriend
Messages: 42
Registered: July 2011
Member
Going back to my original question - does this mean that a version for a Raspberry pi would be easy to port now or more importantly a Apple version in the future if/when they switch CPUs - sorry if it's a daft question - not my area of expertise. What is eclipse written in itself ? Are plugins like window builder pro platform independent byte code or would they need recompiling for a different CPU ?

Thanks

Dave
Re: The Future - ARM CPU's [message #1827474 is a reply to message #1827463] Fri, 15 May 2020 09:15 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
The majority of the Eclipse code is written in Java. As such, that code should run on any platform without modification.

Native code is used for some (core) parts, for instance SWT. There are currently different implementations for Linux/GTK, Windows and Mac OS, other platforms have been supported in the past. Also different CPU architectures are supported, currently x86 64-bit and Power 64-bit LE, other architectures have been supported in the past. For the current overview look at https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_15.xml#target_environments
I expect that all major OSes on major Architectures will be supported by Eclipse.

Third parties can provide compiled binaries/ports for other platforms/architectures, such as Fedora does for ARM. When the target environment is close to the Eclipse supported platforms, porting should be easy, otherwise it is more involved.
Re: The Future - ARM CPU's [message #1830637 is a reply to message #1827474] Thu, 30 July 2020 09:10 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=565690 has been opened to track progress on this.
Re: The Future - ARM CPU's [message #1842608 is a reply to message #1830637] Fri, 25 June 2021 13:32 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
I was trying to compile Eclipse from source on Raspberry Pi, and to do that I've started with compiling SWT - since Eclipse needs SWT to run (and this is the sole platform dependent component as far as I understand)

And guess what - you need Eclipse to compile SWT! Chicken and egg. Insane!

Does anyone know how to compile SWT from command line, or whether it's even remotely possible?
Any help is appreciated.
Re: The Future - ARM CPU's [message #1842612 is a reply to message #1842608] Fri, 25 June 2021 14:26 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
Check the SWT FAQ: https://www.eclipse.org/swt/faq.php#howbuildjar

Also the current thread on platform-dev mailing list about building the full Eclipse SDK from source on a unsupported platform: https://www.eclipse.org/lists/platform-dev/msg03037.html

Which finally resulted in this bug being created: https://bugs.eclipse.org/bugs/show_bug.cgi?id=574358
Re: The Future - ARM CPU's [message #1842620 is a reply to message #1842612] Fri, 25 June 2021 15:45 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
Rolf Theunissen wrote on Fri, 25 June 2021 14:26
Check the SWT FAQ: https://www.eclipse.org/swt/faq.php#howbuildjar

First thing I did.
It says precisely "NOTE: These instructions require you to use Eclipse"
And of course it's very vague. For example, how to figure out what this means:
"2. Compile the project. This will create a folder called bin under the org.eclipse.swt project."

Compile the project? How? Ant, Maven? Both build.xml and pom.xml are present, none work of course - build fails from cli for these.
Probably they mean to compile it in Eclipse. Which is again, a weird requirement to have (why would one even build SWT if they already have one bundled with Eclipse?)

Rolf Theunissen wrote on Fri, 25 June 2021 14:26
Also the current thread on platform-dev mailing list about building the full Eclipse SDK from source on a unsupported platform: https://www.eclipse.org/lists/platform-dev/msg03037.html

I'm sorry, but I find mailing lists to be unusable. The forum is much, much better platform for communication.

[Updated on: Fri, 25 June 2021 15:47]

Report message to a moderator

Re: The Future - ARM CPU's [message #1842628 is a reply to message #1842620] Fri, 25 June 2021 17:26 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
Sorry, I was reading the JAR instructions, indeed the native build refers to using Eclipse.

However, you should be able to trigger the local build using maven. I don't have instructions for you. But the exact same question is asked in the mailing list. So you might not like that in communication, you will find (parts of) your answer there. Moreover, hardly any of the Platform developers monitor the forum so you will not get much of an answer here.
A better overview of the mailing list thread: https://www.eclipse.org/lists/platform-dev/threads.html#03037

Some inspiration can be found here too, but don't use the chromium parts: https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt.browser.chromium/README.md
Re: The Future - ARM CPU's [message #1842631 is a reply to message #1842628] Fri, 25 June 2021 19:54 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
I wonder - how do they even build their own stuff on a build server? They don't run Eclipse on a build server - do they?
This is just weird and incomprehensible.

Since these are native, why not just use make like everybody else?..

[Updated on: Fri, 25 June 2021 19:54]

Report message to a moderator

Re: The Future - ARM CPU's [message #1842632 is a reply to message #1842631] Fri, 25 June 2021 21:22 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
Ok, now I'm getting somewhere myself

Turns out one has to build from binaries repo anyway. At least it seems so to me at this point

I'm not sure which dependencies are needed for build, so far I've got these, but some of them may be irrelevant:
sudo apt install libswt-gtk-4-java libswt-cairo-gtk-4-jni
sudo apt install libequinox-osgi-java
sudo apt install maven ant
sudo apt install make gcc
sudo apt install libwebkit2gtk-4.0-dev


I've cloned source and binaries repo to /home/pi/tmp:
git clone https://git.eclipse.org/r/platform/eclipse.platform.swt.git
git clone https://git.eclipse.org/r/platform/eclipse.platform.swt.binaries.git


Next I took these steps:
1. In /home/pi/tmp/eclipse.platform.swt.binaries/bundles
copy org.eclipse.swt.gtk.linux.aarch64
to org.eclipse.swt.gtk.linux.armv7l
2. in org.eclipse.swt.gtk.linux.armv7l
grep -r "aarch64" . -l | xargs -I FN sed -i "s/aarch64/armv7l/g" FN
3. export JAVA_HOME=/usr/lib/jvm/java-1.11.0-openjdk-armhf
Do this or build will fail with inability to import jni.h
4. Run
ant -f ./eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.armv7l/build.xml build_libraries


This works, but compilation fails so far because of long type for pointers, that apparently has to be changed to int. I'm figuring out now how to change that.

[Updated on: Fri, 25 June 2021 21:39]

Report message to a moderator

Re: The Future - ARM CPU's [message #1842634 is a reply to message #1842632] Fri, 25 June 2021 21:43 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
Fixed pointer sizes in c.c file in source repo - bundles/org.eclipse.swt/Eclipse SWT PI/common/library/c.c
diff --git a/bundles/org.eclipse.swt/Eclipse SWT PI/common/library/c.c b/bundles/org.eclipse.swt/Eclipse SWT PI/common/library/c.c
index b626890a69..4a29874471 100644
--- a/bundles/org.eclipse.swt/Eclipse SWT PI/common/library/c.c
+++ b/bundles/org.eclipse.swt/Eclipse SWT PI/common/library/c.c
@@ -37,7 +37,7 @@ JNIEXPORT jint JNICALL C_NATIVE(PTR_1sizeof)

 #ifndef NO_free
 JNIEXPORT void JNICALL C_NATIVE(free)
-	(JNIEnv *env, jclass that, jlong arg0)
+	(JNIEnv *env, jclass that, jint arg0)
 {
 	C_NATIVE_ENTER(env, that, free_FUNC);
 	free((void *)arg0);
@@ -46,14 +46,14 @@ JNIEXPORT void JNICALL C_NATIVE(free)
 #endif

 #ifndef NO_getenv
-JNIEXPORT jlong JNICALL C_NATIVE(getenv)
+JNIEXPORT jint JNICALL C_NATIVE(getenv)
 	(JNIEnv *env, jclass that, jbyteArray arg0)
 {
 	jbyte *lparg0=NULL;
-	jlong rc = 0;
+	jint rc = 0;
 	C_NATIVE_ENTER(env, that, getenv_FUNC);
 	if (arg0) if ((lparg0 = (*env)->GetByteArrayElements(env, arg0, NULL)) == NULL) goto fail;
-	rc = (jlong)getenv((const char *)lparg0);
+	rc = (jint)getenv((const char *)lparg0);
 fail:
 	if (arg0 && lparg0) (*env)->ReleaseByteArrayElements(env, arg0, lparg0, 0);
 	C_NATIVE_EXIT(env, that, getenv_FUNC);
@@ -62,12 +62,12 @@ fail:
 #endif

 #ifndef NO_malloc
-JNIEXPORT jlong JNICALL C_NATIVE(malloc)
+JNIEXPORT jint JNICALL C_NATIVE(malloc)
 	(JNIEnv *env, jclass that, jlong arg0)
 {
-	jlong rc = 0;
+	jint rc = 0;
 	C_NATIVE_ENTER(env, that, malloc_FUNC);
-	rc = (jlong)malloc(arg0);
+	rc = (jint)malloc(arg0);
 	C_NATIVE_EXIT(env, that, malloc_FUNC);
 	return rc;
 }
@@ -75,7 +75,7 @@ JNIEXPORT jlong JNICALL C_NATIVE(malloc)

 #ifndef NO_memmove__JJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__JJJ)
-	(JNIEnv *env, jclass that, jlong arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jint arg1, jlong arg2)
 {
 	C_NATIVE_ENTER(env, that, memmove__JJJ_FUNC);
 	memmove((void *)arg0, (const void *)arg1, (size_t)arg2);
@@ -85,7 +85,7 @@ JNIEXPORT void JNICALL C_NATIVE(memmove__JJJ)

 #ifndef NO_memmove__J_3BJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__J_3BJ)
-	(JNIEnv *env, jclass that, jlong arg0, jbyteArray arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jbyteArray arg1, jlong arg2)
 {
 	jbyte *lparg1=NULL;
 	C_NATIVE_ENTER(env, that, memmove__J_3BJ_FUNC);
@@ -99,7 +99,7 @@ fail:

 #ifndef NO_memmove__J_3CJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__J_3CJ)
-	(JNIEnv *env, jclass that, jlong arg0, jcharArray arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jcharArray arg1, jlong arg2)
 {
 	jchar *lparg1=NULL;
 	C_NATIVE_ENTER(env, that, memmove__J_3CJ_FUNC);
@@ -113,7 +113,7 @@ fail:

 #ifndef NO_memmove__J_3DJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__J_3DJ)
-	(JNIEnv *env, jclass that, jlong arg0, jdoubleArray arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jdoubleArray arg1, jlong arg2)
 {
 	jdouble *lparg1=NULL;
 	C_NATIVE_ENTER(env, that, memmove__J_3DJ_FUNC);
@@ -127,7 +127,7 @@ fail:

 #ifndef NO_memmove__J_3FJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__J_3FJ)
-	(JNIEnv *env, jclass that, jlong arg0, jfloatArray arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jfloatArray arg1, jlong arg2)
 {
 	jfloat *lparg1=NULL;
 	C_NATIVE_ENTER(env, that, memmove__J_3FJ_FUNC);
@@ -141,7 +141,7 @@ fail:

 #ifndef NO_memmove__J_3IJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__J_3IJ)
-	(JNIEnv *env, jclass that, jlong arg0, jintArray arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jintArray arg1, jlong arg2)
 {
 	jint *lparg1=NULL;
 	C_NATIVE_ENTER(env, that, memmove__J_3IJ_FUNC);
@@ -155,7 +155,7 @@ fail:

 #ifndef NO_memmove__J_3JJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__J_3JJ)
-	(JNIEnv *env, jclass that, jlong arg0, jlongArray arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jlongArray arg1, jlong arg2)
 {
 	jlong *lparg1=NULL;
 	C_NATIVE_ENTER(env, that, memmove__J_3JJ_FUNC);
@@ -169,7 +169,7 @@ fail:

 #ifndef NO_memmove__J_3SJ
 JNIEXPORT void JNICALL C_NATIVE(memmove__J_3SJ)
-	(JNIEnv *env, jclass that, jlong arg0, jshortArray arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jint arg0, jshortArray arg1, jlong arg2)
 {
 	jshort *lparg1=NULL;
 	C_NATIVE_ENTER(env, that, memmove__J_3SJ_FUNC);
@@ -183,7 +183,7 @@ fail:

 #ifndef NO_memmove___3BJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove___3BJJ)
-	(JNIEnv *env, jclass that, jbyteArray arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jbyteArray arg0, jint arg1, jlong arg2)
 {
 	jbyte *lparg0=NULL;
 	C_NATIVE_ENTER(env, that, memmove___3BJJ_FUNC);
@@ -214,7 +214,7 @@ fail:

 #ifndef NO_memmove___3CJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove___3CJJ)
-	(JNIEnv *env, jclass that, jcharArray arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jcharArray arg0, jint arg1, jlong arg2)
 {
 	jchar *lparg0=NULL;
 	C_NATIVE_ENTER(env, that, memmove___3CJJ_FUNC);
@@ -228,7 +228,7 @@ fail:

 #ifndef NO_memmove___3DJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove___3DJJ)
-	(JNIEnv *env, jclass that, jdoubleArray arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jdoubleArray arg0, jint arg1, jlong arg2)
 {
 	jdouble *lparg0=NULL;
 	C_NATIVE_ENTER(env, that, memmove___3DJJ_FUNC);
@@ -242,7 +242,7 @@ fail:

 #ifndef NO_memmove___3FJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove___3FJJ)
-	(JNIEnv *env, jclass that, jfloatArray arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jfloatArray arg0, jint arg1, jlong arg2)
 {
 	jfloat *lparg0=NULL;
 	C_NATIVE_ENTER(env, that, memmove___3FJJ_FUNC);
@@ -256,7 +256,7 @@ fail:

 #ifndef NO_memmove___3IJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove___3IJJ)
-	(JNIEnv *env, jclass that, jintArray arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jintArray arg0, jint arg1, jlong arg2)
 {
 	jint *lparg0=NULL;
 	C_NATIVE_ENTER(env, that, memmove___3IJJ_FUNC);
@@ -287,9 +287,9 @@ fail:

 #ifndef NO_memmove___3JJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove___3JJJ)
-	(JNIEnv *env, jclass that, jlongArray arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jlongArray arg0, jint arg1, jlong arg2)
 {
-	jlong *lparg0=NULL;
+	jint *lparg0=NULL;
 	C_NATIVE_ENTER(env, that, memmove___3JJJ_FUNC);
 		if (arg0) if ((lparg0 = (*env)->GetPrimitiveArrayCritical(env, arg0, NULL)) == NULL) goto fail;
 	memmove((void *)lparg0, (const void *)arg1, (size_t)arg2);
@@ -301,7 +301,7 @@ fail:

 #ifndef NO_memmove___3SJJ
 JNIEXPORT void JNICALL C_NATIVE(memmove___3SJJ)
-	(JNIEnv *env, jclass that, jshortArray arg0, jlong arg1, jlong arg2)
+	(JNIEnv *env, jclass that, jshortArray arg0, jint arg1, jlong arg2)
 {
 	jshort *lparg0=NULL;
 	C_NATIVE_ENTER(env, that, memmove___3SJJ_FUNC);
@@ -314,12 +314,12 @@ fail:
 #endif

 #ifndef NO_memset
-JNIEXPORT jlong JNICALL C_NATIVE(memset)
-	(JNIEnv *env, jclass that, jlong arg0, jint arg1, jlong arg2)
+JNIEXPORT jint JNICALL C_NATIVE(memset)
+	(JNIEnv *env, jclass that, jint arg0, jint arg1, jlong arg2)
 {
-	jlong rc = 0;
+	jint rc = 0;
 	C_NATIVE_ENTER(env, that, memset_FUNC);
-	rc = (jlong)memset((void *)arg0, arg1, (size_t)arg2);
+	rc = (jint)memset((void *)arg0, arg1, (size_t)arg2);
 	C_NATIVE_EXIT(env, that, memset_FUNC);
 	return rc;
 }
@@ -346,7 +346,7 @@ fail:

 #ifndef NO_strlen
 JNIEXPORT jint JNICALL C_NATIVE(strlen)
-	(JNIEnv *env, jclass that, jlong arg0)
+	(JNIEnv *env, jclass that, jint arg0)
 {
 	jint rc = 0;
 	C_NATIVE_ENTER(env, that, strlen_FUNC);
Re: The Future - ARM CPU's [message #1842635 is a reply to message #1842634] Fri, 25 June 2021 21:59 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
Next is making callback.c to compile - so far it worked with this barbaric method:
sed -i 's/jlong/jint/g' "./eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/common/library/callback.c"

+ fixing jint back to jlong in
jlong *elements = (*env)->GetLongArrayElements(env, argsArray, NULL);

at line 1934

Now I get a bunch of jlong/jint errors in os.c
Looks like way too many to fix for me though

Guess this is where I'm stuck now

[Updated on: Fri, 25 June 2021 22:04]

Report message to a moderator

Re: The Future - ARM CPU's [message #1842664 is a reply to message #1842635] Mon, 28 June 2021 06:34 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
Note that the code you are changing is generated and/or only supported on 64-bit systems. 32-bit support in SWT was dropped with release 4.10 [1], you are building for a 32-bit processor architecture. If you insist on building Eclipse on that platform, you will have most success by using version 4.9 (2018-09).

[1] https://www.eclipse.org/eclipse/news/4.10/platform.php#java32-removal
Re: The Future - ARM CPU's [message #1842736 is a reply to message #1842664] Wed, 30 June 2021 08:08 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
Thanks, I'll try to downgrade.
I don't see any useful branches or releases in github though, and there are so many releases and tags... even downgrading to 4.9 is a challenge :-(
Re: The Future - ARM CPU's [message #1842738 is a reply to message #1842736] Wed, 30 June 2021 09:06 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
The main source is hosted on Eclipse infrastructure and not on Github, the 4.9 maintenance branches are here:

https://git.eclipse.org/c/gerrit/platform/eclipse.platform.swt.git/log/?h=R4_9_maintenance
https://git.eclipse.org/c/gerrit/platform/eclipse.platform.swt.binaries.git/log/?h=R4_9_maintenance
Re: The Future - ARM CPU's [message #1842742 is a reply to message #1842738] Wed, 30 June 2021 10:46 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
Right, I actually see R4_9_maintenance branch on GitHub as well
Thanks for the hint!
Re: The Future - ARM CPU's [message #1842877 is a reply to message #1842742] Sun, 04 July 2021 22:08 Go to previous messageGo to next message
Mykola Makhin is currently offline Mykola MakhinFriend
Messages: 50
Registered: July 2018
Member
Stuck with this issue now:
https://i.postimg.cc/28tK5sbX/Screenshot-2021-07-03-at-04-16-03.png
Re: The Future - ARM CPU's [message #1842887 is a reply to message #1842877] Mon, 05 July 2021 08:08 Go to previous messageGo to next message
Rolf Theunissen is currently offline Rolf TheunissenFriend
Messages: 260
Registered: April 2012
Senior Member
Looks like creating of the org.eclipse.jdt feature is failing, probably due to an earlier error while building the org.eclipse.jdt.core.manipulation plugin. Check the full log for errors and warnings to see where the problem occurs.
Re: The Future - ARM CPU's [message #1846939 is a reply to message #1842887] Sat, 09 October 2021 14:13 Go to previous message
David Garratt is currently offline David GarrattFriend
Messages: 42
Registered: July 2011
Member
I'll be getting a MacBook with M1 processor in the non too distant future but I suppose I will still be able to run the intel version of Eclipse via Rosetta2 for the time being.
Previous Topic:Part Descriptor with Tag "View" not visible in "Show Views" since 2021.06
Next Topic:electronic signature
Goto Forum:
  


Current Time: Thu Mar 28 08:13:03 GMT 2024

Powered by FUDForum. Page generated in 0.05522 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top