TipsAndTricks/RunningEclipseAgainstBuiltImage - Revision history

Bavery at 20:59, 14 September 2017

2017-09-14T20:59:38Z

← Older revision		Revision as of 20:59, 14 September 2017
Line 89:		Line 89:
	** At the bottom of the DEbug Configuration page, by default, you will be in "Using GDB (DSF) Automatic Remote Debugging Launcher" - Select other...		** At the bottom of the DEbug Configuration page, by default, you will be in "Using GDB (DSF) Automatic Remote Debugging Launcher" - Select other...
	** Click on "Select other..." and you can choose GDB (DSF) Automatic REmove Debugging via TCF/TE Launcher. This is the oxygen equivalent of a TCF connection.		** Click on "Select other..." and you can choose GDB (DSF) Automatic REmove Debugging via TCF/TE Launcher. This is the oxygen equivalent of a TCF connection.
			** If they cannot be selected, you may need to select the "Use configuration specific settings" checkbox at the top of the dialog box.
	*** at this point, your connection will be of type tcf		*** at this point, your connection will be of type tcf
			** I found the neon implementation of tcf to be buggy...
	===== Back to Using the Connection whether it be ssh or tcf =====		===== Back to Using the Connection whether it be ssh or tcf =====
	* Browse to where the prog will go. I tend to use /home/root.		* Browse to where the prog will go. I tend to use /home/root.

Bavery at 20:21, 14 September 2017

2017-09-14T20:21:42Z

← Older revision		Revision as of 20:21, 14 September 2017
Line 90:		Line 90:
	** Click on "Select other..." and you can choose GDB (DSF) Automatic REmove Debugging via TCF/TE Launcher. This is the oxygen equivalent of a TCF connection.		** Click on "Select other..." and you can choose GDB (DSF) Automatic REmove Debugging via TCF/TE Launcher. This is the oxygen equivalent of a TCF connection.
	*** at this point, your connection will be of type tcf		*** at this point, your connection will be of type tcf
			===== Back to Using the Connection whether it be ssh or tcf =====
	* Browse to where the prog will go. I tend to use /home/root.		* Browse to where the prog will go. I tend to use /home/root.
	** Remote Absolute File Path for C/C++ Application -> click Browse...		** Remote Absolute File Path for C/C++ Application -> click Browse...

Bavery: /* Put the binary on the Qemu instance and debug it */

2017-09-14T20:21:04Z

Put the binary on the Qemu instance and debug it

← Older revision		Revision as of 20:21, 14 September 2017
Line 84:		Line 84:
	** name it		** name it
	** click finish		** click finish
			===== Eclipse Oxygen and TCF =====
			* In Mars, TCF would appear as a connection type alongside ssh.
			* In Oxygen, this is no longer true. If you want to use tcf as the connection type you need to do the following:
			** At the bottom of the DEbug Configuration page, by default, you will be in "Using GDB (DSF) Automatic Remote Debugging Launcher" - Select other...
			** Click on "Select other..." and you can choose GDB (DSF) Automatic REmove Debugging via TCF/TE Launcher. This is the oxygen equivalent of a TCF connection.
			*** at this point, your connection will be of type tcf
	* Browse to where the prog will go. I tend to use /home/root.		* Browse to where the prog will go. I tend to use /home/root.
	** Remote Absolute File Path for C/C++ Application -> click Browse...		** Remote Absolute File Path for C/C++ Application -> click Browse...
Line 94:		Line 100:
	*** make sure that the proxies eclipse knows about in Window->Preferences->Network Connections is not "eating" the ssh connection traffic. On Oxygen, for instance, I need to switch the network connection to manual and add 192.168.7.2 as a Proxy bypass host.		*** make sure that the proxies eclipse knows about in Window->Preferences->Network Connections is not "eating" the ssh connection traffic. On Oxygen, for instance, I need to switch the network connection to manual and add 192.168.7.2 as a Proxy bypass host.
	* click Apply		* click Apply
	* click Debug and open the Debug Perspective.		* click Debug and open the Debug Perspective.





	== Other Useful Info ==		== Other Useful Info ==

Bavery at 23:19, 13 September 2017

2017-09-13T23:19:52Z

← Older revision		Revision as of 23:19, 13 September 2017
Line 89:		Line 89:
	** double click root		** double click root
	** click ok		** click ok
			** If the browse to Remote Absolute File Path for C/C++ Application hangs or errors out Check
			*** qemu is running
			*** you can ssh root@<address> from a terminal window
			*** make sure that the proxies eclipse knows about in Window->Preferences->Network Connections is not "eating" the ssh connection traffic. On Oxygen, for instance, I need to switch the network connection to manual and add 192.168.7.2 as a Proxy bypass host.
	* click Apply		* click Apply
	* click Debug and open the Debug Perspective.		* click Debug and open the Debug Perspective.

Tim Orling: /* Other Useful Info */

2017-01-13T22:34:13Z

Other Useful Info

← Older revision		Revision as of 22:34, 13 January 2017
Line 142:		Line 142:
	</code>		</code>
	But this might affect other programs as well.		But this might affect other programs as well.

			=== XWayland workaround with <code>gtk3</code> (Fedora-25) ===

			If you see bizarre screen layout of controls in Eclipse Neon, it is probably because the Neon (4.6.x) release of Eclipse is not fully compatible with straight Wayland.

			Fedora-25 now has Wayland by default. To enable the XWayland backend:

			<code>export GDK_BACKEND=x11</code>

			This will still use gtk3, but will use the XWayland bridge rather than straight Wayland. This is expected to be fixed in the Oxygen (4.7) release of Eclipse to support straight Wayland.(https://bugs.eclipse.org/bugs/show_bug.cgi?id=496923)

			Thanks to Roland Grunber (Red Hat Linux Tools team) for pointing me in the right direction on #fedora-linux (freenode IRC).

			[Source] https://coffeeorientedprogramming.com/2016/10/06/make-applications-eclipse-use-x11-backend-on-wayland-fedora-25/#more-502

			==== How to know what version of <code>gtk</code> is being used in your session? ====
			<code>Help -> About -> Installation Details -> Configuration Tab</code>

			Look for something like:

			<code>org.eclipse.swt.internal.gtk.version=3.22.6</code>

			[Source] https://coffeeorientedprogramming.com/2014/10/27/how-to-tell-if-you-are-running-eclipse-on-gtk2-or-on-gtk3/

			==== How do you know you are running Wayland? ====
			<code>loginctl</code> which should show you a list of sessions, one of which will be <code>gdm</code>, remember that session number.

			<code>loginctl show-session <session number from above> -p Type</code>

			Result should be:

			<code>Type=wayland</code>

			[Source] http://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used

Bavery: /* Dealing with java.lang.NullPointerException */

2016-11-21T18:09:23Z

Dealing with java.lang.NullPointerException

← Older revision		Revision as of 18:09, 21 November 2016
Line 140:		Line 140:
	<code>		<code>
	$export SWT_GTK3=0		$export SWT_GTK3=0
	< /code>		</code>
	But this might affect other programs as well.		But this might affect other programs as well.

Bavery: /* Dealing with java.lang.NullPointerException */

2016-11-21T18:09:08Z

Dealing with java.lang.NullPointerException

← Older revision		Revision as of 18:09, 21 November 2016
Line 118:		Line 118:

	=== Dealing with java.lang.NullPointerException ===		=== Dealing with java.lang.NullPointerException ===
	Eclipse upstream has some issues with some of the GTK3 libraries shipped with some of the distributions ~~[EclipseGTK3Bug~~ https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736]. If you are seeing a NullPointer Exception try adding the following to your eclipse.ini file:		Eclipse upstream has some issues with some of the GTK3 libraries shipped with some of the distributions(https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736). If you are seeing a NullPointer Exception try adding the following to your eclipse.ini file:
	<code>		<code>
	--launcher.GTK_version		--launcher.GTK_version

Bavery: /* Other Useful Info */

2016-11-21T18:07:56Z

Other Useful Info

← Older revision		Revision as of 18:07, 21 November 2016
Line 116:		Line 116:
	<code> Invoke Autoconf</code>		<code> Invoke Autoconf</code>
	Then Right click on the project and select <code> Reconfigure Project </code>. You should now be able to build the project again.		Then Right click on the project and select <code> Reconfigure Project </code>. You should now be able to build the project again.

			=== Dealing with java.lang.NullPointerException ===
			Eclipse upstream has some issues with some of the GTK3 libraries shipped with some of the distributions [EclipseGTK3Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736]. If you are seeing a NullPointer Exception try adding the following to your eclipse.ini file:
			<code>
			--launcher.GTK_version
			2
			</code>

			Here's an in place snippet of a happy ini file:
			<code>
			-showsplash
			org.eclipse.platform
			--launcher.XXMaxPermSize
			256m
			--launcher.defaultAction
			openFile
			--launcher.GTK_version
			2
			--launcher.appendVmargs
			-vmargs
			</code>
			Alternatively, you can set
			<code>
			$export SWT_GTK3=0
			< /code>
			But this might affect other programs as well.

Bavery: /* Why SDK Image */

2016-09-16T19:40:20Z

Why SDK Image

← Older revision		Revision as of 19:40, 16 September 2016
Line 97:		Line 97:
	== Other Useful Info ==		== Other Useful Info ==
	=== Why SDK Image ===		=== Why SDK Image ===
	The current poky-eclipse plugin mashes together 2 concepts that should have been disjoint: namely, the target sysroot and the image qemu will boot. Under Window->Preferences->Yocto Project SDK, you choose a sysroot location. Up above I told you to point this to the MY_QEMU_ROOTFS you extracted with runqemu-extract-sdk. This will work, but only if you have built the sdk image. If you built the core-image-sato instead, then the MY_QEMU_ROOTFS will be missing a lot of important development files like stdio.h...		The current poky-eclipse plugin mashes together 2 concepts that should have been disjoint: namely, the target sysroot and the rootfs image qemu will boot. Under <code> Window->Preferences->Yocto Project SDK </code>, you choose a sysroot location. Up above I told you to point this to the MY_QEMU_ROOTFS you extracted with runqemu-extract-sdk. This will work, but only if you have built the sdk image. If you built the core-image-sato instead, then the MY_QEMU_ROOTFS will be missing a lot of important development files like stdio.h...
	==== How to Work around this ====		==== How to Work around this ====
	Let's say you build core-image-sato (this is a standin for your particular image that can't have the sdk parts tossed in for some reason). You can still use eclipse and qemu. You need to do the same things as above with the following changes:		Let's say you build core-image-sato (this is a standin for your particular image that can't have the sdk parts tossed in for some reason). You can still use eclipse and qemu. You need to do the same things as above with the following changes:
	* <code>Sysroot in Window->Preferences->Yocto Project SDK </code> points to <builddir>/tmp/sysroots/qemux86-64		* <code>Sysroot in Window->Preferences->Yocto Project SDK </code> points to <builddir>/tmp/sysroots/qemux86-64. This will give the build system access to the development files it needs.
	* In the dialog for <code> Run->External Tools-> External Tools Configurations... </code> you will need to read the long Argument string in the big box. It will have something like <code> -e "source env-setup-<sdkarch>; runqemu <kernel path> <rootfs path> </code> Because the current plugin munges the sysroot and qemu image concepts, the <rootfs path> will incorrectly be pointing to your sysroot. Just delete the <rootfs path> and put in the ABSOLUTE path to the MY_QEMU_ROOTFS you extracted with the runqemu-extract-sdk tool. This way, you can build & debug the image even if it's not an sdk image.		* In the dialog for <code> Run->External Tools-> External Tools Configurations... </code> you will need to read the long Argument string in the big box. It will have something like <code> -e "source env-setup-<sdkarch>; runqemu <kernel path> <rootfs path> </code> Because the current plugin munges the sysroot and qemu image concepts, the <rootfs path> will incorrectly be pointing to your sysroot. Just delete the <rootfs path> and put in the ABSOLUTE path to the MY_QEMU_ROOTFS you extracted with the runqemu-extract-sdk tool. This way, you can build & debug the image even if it's not an sdk image.


	=== Adding static tap devices ===		=== Adding static tap devices ===

Bavery at 19:38, 16 September 2016

2016-09-16T19:38:40Z

← Older revision		Revision as of 19:38, 16 September 2016
Line 4:		Line 4:
	So that the commands are specific and can be cut and pasted to try, we will assume the following:		So that the commands are specific and can be cut and pasted to try, we will assume the following:
	* Target Image-> core-image-sato-sdk		* Target Image-> core-image-sato-sdk
	** see ~~bottom sec~~ [[#Why SDK Image]]		** see section[[#Why SDK Image]] for why you have to build the sdk image and how to work around it if you really don't want to.
	* Target Machine -> qemux86		* Target Machine -> qemux86
	<br>		<br>
Line 97:		Line 97:
	== Other Useful Info ==		== Other Useful Info ==
	=== Why SDK Image ===		=== Why SDK Image ===
			The current poky-eclipse plugin mashes together 2 concepts that should have been disjoint: namely, the target sysroot and the image qemu will boot. Under Window->Preferences->Yocto Project SDK, you choose a sysroot location. Up above I told you to point this to the MY_QEMU_ROOTFS you extracted with runqemu-extract-sdk. This will work, but only if you have built the sdk image. If you built the core-image-sato instead, then the MY_QEMU_ROOTFS will be missing a lot of important development files like stdio.h...
			==== How to Work around this ====
			Let's say you build core-image-sato (this is a standin for your particular image that can't have the sdk parts tossed in for some reason). You can still use eclipse and qemu. You need to do the same things as above with the following changes:
			* <code>Sysroot in Window->Preferences->Yocto Project SDK </code> points to <builddir>/tmp/sysroots/qemux86-64
			* In the dialog for <code> Run->External Tools-> External Tools Configurations... </code> you will need to read the long Argument string in the big box. It will have something like <code> -e "source env-setup-<sdkarch>; runqemu <kernel path> <rootfs path> </code> Because the current plugin munges the sysroot and qemu image concepts, the <rootfs path> will incorrectly be pointing to your sysroot. Just delete the <rootfs path> and put in the ABSOLUTE path to the MY_QEMU_ROOTFS you extracted with the runqemu-extract-sdk tool. This way, you can build & debug the image even if it's not an sdk image.