Created attachment 1057 [details] err STATUS: IDLE ECLIPSE PLUTIN 1.4_M3:65f1b736b719ad5284281ccd88a33a5a92724da2 ENVIRONMENT: Fedora 17 x86_64 TOOLCHAIN USED:http://autobuilder.yoctoproject.org/pub/nightly/20130131-4/toolchain/x86_64/poky-eglibc-x86_64-i586-toolchain-gmae-1.3+snapshot-20130131.sh Sysroot used: The one which was installed with adt-installer. Adt-installer used: http://autobuilder.yoctoproject.org/pub/nightly/20130131-4/adt_installer-QA/ STEPS TO REPRODUCE: 1. Install the standalone toolchain. 2. Install adt-installer. 3. Launch eclipse, configure it with the eclipse plugin. For yocto adt-settings use as toolchain the standalone toolchain, and for sysroot and kernel, the ones installed by ADT-installer. 4. Create a new C, Hellow World GTK project. 5. Build it and launch qemu. Right click it and Debug as -> Debug Configurations Under Debug Configurations expand "C/C++ Remote Application". A configuration for the current project should appear. Clicking it will display the configuration settings. in "C/C++ Application" field input Remote Absolute File path for C/C++ Application. e.g.: /home/root/myapplication in "Commands to execute before application" enter: export DISPLAY=:0.0 In "Connection" drop-down list make sure a TCF connection is set up for your target. If not, create a new one by clicking the New button After all settings are done, select the Debug button on the bottom right corner EXPECTED OUTCOME: Under the Project files, a new folder appears called Binaries. This indicates that the compilation have been successful and the project binary have been created. Build succeed and the console outputs "Hello world", you can also check the output on target. Eclipse switches to Debug Perspective, and the user can debug ACUTAL OUTCOME: The application is built successful, but The following error appears (see the attachment): Error creating session Could not find platform independent libraries <prefix> Could not find platform independent libraries <prefix> Could not find platform independent libraries <prefix>
It's not eclips plug-in but the underline cross gdb. I've tested with i586-poky-linux-gdb on my ubuntu 12.04 from commandline and got the same error. A simple test is to download toolchain (1.4_M1), e.g. target as x86. Extract to an arbitrary location, e.g. $HOME/test-toolchain. Source environment-setup file. Then just type i586-poky-linux-gdb. You'll see the errors instead of entering a gdb session. I'm also getting these lines from command line: Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] ImportError: No module named site
More note: seems it's related to relocatable SDK if install under default location there's no such error. Also, it seems related to host distro, on my 32bit 12.04 Ubuntu, install under the user specified location works.
Patch on the oe-core ML.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=db0a02492c2a53c1917b753bcf21c4ee7c0ecf59
verified.
First of all, sorry for being late - just noticed this "fix" made it into danny, which triggered my response. Unfortunately, I don't have much time to track master too closely, hence didn't see it before... I've been dealing with this issue in our product for quite some time. I tried adding PYTHONHOME into environment-setup script originally, but we eventually realized it's not a good place for it to be. The reason is, the Python setup (all the modules) we normally bundle in the Yocto generated toolchain is very limited - it just cannot compete with the system-wide host Python installation. When you use the toolchain, you still expect to depend on the host Python a lot. E.g. Ubuntu has a default 'command-not-found' handler calling a Python library. Few other system commands expect their Python modules to be available. So, setting PYTHONHOME to point to our limited Python setup just for gdb and/or few other commands breaks a lot of other things. What I ended up doing is creating a small wrapper for gdb, which sets PYTHONHOME and calls gdb.real binary. Can be done for other tools in the toolchain, that require Python. This way when using gdb from the toolchain, we get our Python with its modules loaded. When using other non-toolchain commands or tools, the default system-wide Python is used.
For gdb there is simpler solution: http://patches.openembedded.org/patch/50559/ Gdb already does relocation of the python path, we only needed to give correct path for it work.