This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 147773 [details] ide log Since a few days the compiler tools detection on a remote linux arm host does not work. Steps to reproduce: 1. On a Service tab try to add remote build host - armv6 (raspberry pi) with debian (jessie/sid). 2. After typing a hostname, port, login and password on the first two screens, the IDE tries to detect compiler tools on the remote host. 3. The result shown in "Tool Collections details" is "None ()". It works with version 7.0.1 and it used to work with version 8.0. The ide log says that file /var/tmp/dlight_root/ee90f67c/136285267/pty does not exists, but it does.
Has the file /var/tmp/dlight_root/ee90f67c/136285267/pty -x permissions? What if you - close the IDE, - remove /var/tmp/dlight_root/ee90f67c/ (or just rename it) - restard IDE - will this help? (Upon connection, IDE should recognize the absence of this directory and upload all necessary files there)
> Has the file /var/tmp/dlight_root/ee90f67c/136285267/pty -x permissions? Yes, it has "-rwx------ root root" (i'm connecting as a root). >What if you >- close the IDE, >- remove /var/tmp/dlight_root/ee90f67c/ (or just rename it) >- restard IDE - >will this help? No, it didn't help even though the IDE has recreated the file. Note that i've already deleted ~/.netbeans directory and even reinstalled IDE. I'm using netbeans-8.0-cpp-linux.sh installer.
Could you please launch IDE with additional command line options -J-Dcnd.remote.logger.level=0 -J-Dnativeexecution.support.logger.level=0 -J-Dremote.support.logger.level=0 and attach message log? (please note it will contain host and user name you would probably like to strip)
Created attachment 147831 [details] ide log - cnd detailed
What if you login to your host in console and try to launch /var/tmp/dlight_root/ee90f67c/136285267/pty without parameters - what will happen?
I also need to know what is the output of commands cat /proc/cpuinfo uname -a I would also like to note that arm is not officially supported, only x86 and sparc are. I'm eager to fix this bug however, but can't do this without your input.
OK, i will provide you more info, but now i'm on holiday. In a two weeks i'll be back.
Closing as incomplete. Please reopen as soon as you get additional iformation.
Halo again! Here are the info you asked for: root@hasiok:~# dir /var/tmp/dlight_root/ee90f67c/136285267/pty -rwx------ 1 root root 17175 cze 26 19:57 /var/tmp/dlight_root/ee90f67c/136285267/pty root@hasiok:~# /var/tmp/dlight_root/ee90f67c/136285267/pty -bash: /var/tmp/dlight_root/ee90f67c/136285267/pty: No such file or directory root@hasiok:~# cat /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 2.00 Features : swp half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7 Hardware : BCM2708 Revision : 000e Serial : 0000000083ad7349 root@hasiok:~# uname -a Linux hasiok 3.10.33+ #658 PREEMPT Tue Mar 18 17:35:55 GMT 2014 armv6l GNU/Linux
Hi, the same problem in my case I'm developing on arm7 (Linux a13-OLinuXino-Micro 3.4.79+ #5 PREEMPT Fri Mar 14 13:27:31 EET 2014 armv7l GNU/Linux) remote compiling works fine in 7.4, but now in 8.0.1: pty does not execute on remote machine. (nor executing it from the root user on the remote machine, nor if I copy it to another location different from var/tmp/...) the response is always: bash: ./pty No such file or directory Thank you if you can suggest us a workaround (other than go back to 7.4!)
I have the same problem. messages.log of Netbeans 8.0.1: bash: /var/tmp/dlight_user/3936f06/02084214819/pty: No such file or directory On the remote Debian wheezy, I have: root@cubie-user:/usr/bin# l /var/tmp/dlight_user/3936f06/02084214819/pty -rwx------ 1 user user 17175 Oct 4 07:33 /var/tmp/dlight_user/3936f06/02084214819/pty So it exists but cannot be executed. ELF format is not proper one for the host: root@cubie-user:/usr/bin# /var/tmp/dlight_user/3936f06/02084214819/pty -bash: /var/tmp/dlight_user/3936f06/02084214819/pty: No such file or directory root@cubie-user:/usr/bin# file /bin/bash /bin/bash: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xd3638bb98e0f7b6c998c8d448bfa86dc29f6d123, stripped root@cubie-user:/usr/bin# file /var/tmp/dlight_user/3936f06/02084214819/pty /var/tmp/dlight_user/3936f06/02084214819/pty: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x2e026e0f01484c7e7d9b5954c4c2832c4c87ee0a, stripped So I guess this is the only possibility. ELF format is not for this host. my uname: Linux cubie-user 3.4.43-20130823-user-2 #3 Thu Aug 22 02:25:03 CEST 2013 armv7l GNU/Linux My cpuinfo: Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS : 71.88 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : sun4i Revision : 0000 Serial : 0000000000000000 (Cubieboard with A10)
I'm happy that this issue is filed as a bug. I racked my brains for couple of days to debug my project on BBB(BeagleboneBlack) using netbeans as I was able to do few months back!! Netbeans was unable to copy files to BBB. Unable to create new project at BBB using remote toolbar. If I try to build an existing project present on BBB, it gives an error like "Unable to get process PID". I hope this bug will be fixed soon. I'm willing to help to fix this bug as soon as possible.
$ uname -a Linux arm 3.8.13-bone63 #1 SMP Mon Aug 11 23:03:02 UTC 2014 armv7l armv7l armv7l GNU/Linux
Created attachment 150025 [details] Could you try this pty on your remote arm, will it execute or fail as well? Please copy the attached pty binary to your remote arm machine and try launching it there - will it work?
It works! Good job, thanks! ;-) olimex@a13-OLinuXino-Micro:~$ cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS : 1001.88 Features : swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : sun5i Revision : 0000 Serial : 0000000000000000 olimex@a13-OLinuXino-Micro:~$ ./pty usage: pty [-e] [--no-pty] [-w] [-p pts_name] [--set-erase-key] [--readenv env_file] [[--env NAME=VALUE] ...] [--dir dir] [--redirect-error] [--report report_file] program [ arg ... ] -e turn echoing off -w wait SIGCONT after reporting PID/TTY/.. but before executing the program -p define pts_name to attach process's I/O instead of opening a new one --readenv read environment to start process in from a file --env pass (additional) environment variable to the process --dir change working directory for starting process --redirect-error redirect stderror to stdout for starting process (makes sense if --no-pty only) --report record process' and exit status information into specified file usage: pty --dumpenv env_file --dumpenv dump environment to a file
Yep, It works! $ ./pty uname -a PID=3444 TTY=/dev/pts/2 PSID=3444 NBMAGIC=3443 ---------------------------------------------------------------------------- $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 2 (v7l) BogoMIPS : 298.24 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part : 0xc08 CPU revision : 2 Hardware : Generic AM33XX (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000
$ ./pty uname -a PID=3444 TTY=/dev/pts/2 PSID=3444 NBMAGIC=3443 Linux fp3 3.8.13-bone63 #1 SMP Mon Aug 11 23:03:02 UTC 2014 armv7l armv7l armv7l GNU/Linux
Created attachment 150045 [details] log generated while creating a remote project Its the log generated since I connected to Beaglebone black from remote toolbar of the IDE and tried to create a project on the BeagleboneBlack which failed.
Created attachment 150046 [details] log generated while creating a remote project Its the log generated since I connected to Beaglebone black from remote toolbar of the IDE and tried to create a project on the BeagleboneBlack which failed.
I'm sorry! Replacing /var/tmp/dlight_ubuntu/c1326f49/0982811042/pty worked. Now Netbeans detects the C++ toolchain and I was able to create a C++ project. Thanks!
The pty I attached was just linked with -static option - that's the only difference. Sure it is much larger than original one: 524K vs 17K I'm slightly afraid of such size increase taking into consideration the fact that there are more utilities we upload to /var/tmp/dlight_${USER}/ Could you find other utilities there (for example fs_server) and try them as well and tell me whether they launch or not?
I see. Acch! Same problem with fs_server (108kb) in /var/tmp/.../bin. It does not start. (no such file or directory) But... how things are working in Netbeans 7.4 ? I don't see any helper programs uploaded in /var/tmp...
(In reply to nimaia from comment #22) > But... how things are working in Netbeans 7.4 ? In 7.x NetBeans didn't even try to use these programs; in 8.0 I first built them all for arm. The main reason for that was as follows: NetBeans remote file system in 8.0 uses fs_server utilty - this allowed to speed up a lot (up to 6-8 times on slow connections) and also made response for remote file changes more adequate. Sure, in the absence of fs_server or in the case of its fatal failure, IDE falls back to old (sftp based) implementation. But I decided to use this new approach for arm as well.
Hi Vladimir, While debugging no output is being printed on internal or external terminal. I tried changing all the terminal options in the project properties.
I'm having this issue with a BeagleBone black running Debian 7.7. I believe that the problem lies in the fact that the pty executable is linked against libc for the armel architecture (/lib/arm-linux-gnueabi/libc.so.6). If only the armhf, rather than the armel, packages are installed (/lib/arm-linux-gnueabihf/libc.so.6), then the libc library that pty links against does not exist. This also explains why the statically compiled version of pty corrects this issue. I installed the armel version of libc using these commands: dpkg --add-architecture armel apt-get update apt-get install libc6:armel Then the platform is correctly detected and the tool collection is found when I add the BBB as a remote host in NetBeans. There is some discussion here: http://www.raspberrypi.org/forums/viewtopic.php?f=33&t=20873 on detecting whether the platform is armhf or armel. Perhaps some technique can be used to choose the correct executable to mitigate this issue?
Hi everyone! I have read the complete bug and all your comments. I have the same issue on the same architecture. I am using Netbeans 8.0.1 and also have downloaded the file attached by Vladimir, which is statically compiled. It works running alone in the remote device, but I can not add the remote host succesfully yet because the IDE does not identify the tool chain. Here is some info: root@ts4900:/var/tmp/dlight_root/ac6356f1/2053225632# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 10 (v7l) BogoMIPS : 790.52 Features : swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10 ... Hardware : Freescale i.MX6 Quad/DualLite (Device Tree) Revision : 0000 Serial : 0000000000000000 (the processor is multicore, only one core shown here) Moreover, I believe that something important to mention is that this processor belongs to those called "hard-float" family. This is identified by the acronim "armhf" or "arm-linux-gnueabihf". ARMv7 processors family has this new feature, built-in floating point unit. I have another device with an ARMv5 processor and I have used Netbeans to develop remotely without any problem. The gcc -v output shows the target platform: root@ts4900:/var/tmp/dlight_root/ac6356f1/2053225632# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Running pyi alone: root@ts4900:/var/tmp/dlight_root/ac6356f1/2053225632# ./pty usage: pty [-e] [--no-pty] [-w] [-p pts_name] [--set-erase-key] [--readenv env_file] [[--env NAME=VALUE] ...] [--dir dir] [--redirect-error] [--report report_file] program [ arg ... ] -e turn echoing off -w wait SIGCONT after reporting PID/TTY/.. but before executing the program -p define pts_name to attach process's I/O instead of opening a new one --readenv read environment to start process in from a file --env pass (additional) environment variable to the process --dir change working directory for starting process --redirect-error redirect stderror to stdout for starting process (makes sense if --no-pty only) --report record process' and exit status information into specified file usage: pty --dumpenv env_file --dumpenv dump environment to a file I was wondering if any could tell me if there is a plan to fix this problem in the near future. Also, if there is anything i can do to bypass and continue developing remotely. I would like to avoid compiling by ssh =P. Thanks a lot!
I can confirm the pty attached to this list worked for me as well on the Hummingboard using the ubuntu distribution for Cubie / Hummingboard. I'd love to get a copy of fserver compiled the same way. Alternatively I'd like a better understanding of additional packages I could install that would make the required shared libraries available so that static compilation wasn't necessary. Any updates?
(In reply to jlefley from comment #25) > I'm having this issue with a BeagleBone black running Debian 7.7. I believe > that the problem lies in the fact that the pty executable is linked against > libc for the armel architecture (/lib/arm-linux-gnueabi/libc.so.6). If only > the armhf, rather than the armel, packages are installed > (/lib/arm-linux-gnueabihf/libc.so.6), then the libc library that pty links > against does not exist. This also explains why the statically compiled > version of pty corrects this issue. > > I installed the armel version of libc using these commands: > > dpkg --add-architecture armel > apt-get update > apt-get install libc6:armel > > Then the platform is correctly detected and the tool collection is found > when I add the BBB as a remote host in NetBeans. > > There is some discussion here: > http://www.raspberrypi.org/forums/viewtopic.php?f=33&t=20873 on detecting > whether the platform is armhf or armel. Perhaps some technique can be used > to choose the correct executable to mitigate this issue? Do you know if there are any repercussions to adding the el architecture ? I'd hate to have most of my stuff start using soft floating point. If I can safely add it and it will only be used if needed though then that's a different story
With todays updates netbeans 8.0.1 no longer works even with the static linked pty - it detects the platform as generic instead of linux x86. I still have the 8.0 beta installed and that one continues to work with the static pty program. The non-functional (even with static pty) is version 1.27.1.1 in the plugins dialog. The version in the plugin in the beta is 1.25.1.1 and still works with static pty. I'm positive 8.0.1 release was working until I accepted a plugin update today.
(In reply to riftware from comment #28) > (In reply to jlefley from comment #25) > > I'm having this issue with a BeagleBone black running Debian 7.7. I believe > > that the problem lies in the fact that the pty executable is linked against > > libc for the armel architecture (/lib/arm-linux-gnueabi/libc.so.6). If only > > the armhf, rather than the armel, packages are installed > > (/lib/arm-linux-gnueabihf/libc.so.6), then the libc library that pty links > > against does not exist. This also explains why the statically compiled > > version of pty corrects this issue. > > > > I installed the armel version of libc using these commands: > > > > dpkg --add-architecture armel > > apt-get update > > apt-get install libc6:armel > > > > Then the platform is correctly detected and the tool collection is found > > when I add the BBB as a remote host in NetBeans. > > > > There is some discussion here: > > http://www.raspberrypi.org/forums/viewtopic.php?f=33&t=20873 on detecting > > whether the platform is armhf or armel. Perhaps some technique can be used > > to choose the correct executable to mitigate this issue? > > Do you know if there are any repercussions to adding the el architecture ? > I'd hate to have most of my stuff start using soft floating point. If I > can safely add it and it will only be used if needed though then that's a > different story I do not think that adding the armel architecture will change the default. It is possible to remove the armel architecture using "dpkg --remove-architecture armel" after you install libc6:armel.
Ok - the nightly builds can work with the statically linked pty above. You do have to put it in the directory that is created - I suspect there is a new subdirectory created with each version of netbeans. Further updates -- I tried adding the armel architecture above.. I could not install the package listed above with my Hummingboard ubuntu install. -- I'd be happy to build the native binaries myself on my platform if I knew what I had to check out and build and where to put it in the netbeans install I'd really like to make progress on this bug if possible
Ok - this works for me on my Hummingboard running Ubuntu. Its an armv architecture using Hard Float so I believe it will work for the raspberry pi as well. These were compiled using shared library not static. Before attempting anything please back up the contents of the directory listed below before attempting this. The files in the attached zip (assuming I figure out how to attach) all go in this directory under the netbeans install. /ide/bin/nativeexecution/Linux-arm/ 1:BACKUP THAT DIRECTORY 2:Unzip the file and place the contents in that directory. 3: Remove the C++ build host -we're going to create it again so it copies everything over 4: On the arm remove the /var/tmp/dlightxxxxxx directory 5: Close Netbeans and restart it 6: Re-add the c++ build host. During the effort make sure you choose sftp instead of smb I can only state that this works for the Hummingboard but I'd be interested in hearing others results.
Created attachment 151282 [details] ARM Hard Float pty and other native utils Hummingboard- see my comment
(In reply to riftware from comment #33) > Created attachment 151282 [details] > ARM Hard Float pty and other native utils - see my comment This doesn't work with my raspberry (armv6l, Little Endian).
Created attachment 151289 [details] arm hard float pty and other native utils built on Raspberry PI I didn't put this in my previous posts but you may need to keep the unbuffer.so from the original directory I said to back up.
Comment on attachment 151282 [details] ARM Hard Float pty and other native utils Hummingboard- see my comment Please keep the unbuffer.so from your original directory (you backed it up right?) on the netbeans install
The archive I uploaded yesterday works for me on both the PI and the Hummingboard. I believe that is because the pi is an Arm 6 architecture and the Hummingboard is a version 7 architecture which should be backwards compatible. This is good news since netbeans only has one spot it pulls tools from for ARM and if you have multiple kinds of boards its a pain to switch between them.
Should be fixed after http://hg.netbeans.org/cnd-main/rev/fe67be9dc5f3
Integrated into 'main-silver', will be available in build *201501300002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/fe67be9dc5f3 User: Vladimir Kvashin <vkvashin@netbeans.org> Log: fixed #245243 - IDE can't detect c/c++ compiler tool on a remote host (linux arm)
I'm having this same problem with 8.0.2 and the newest debian image (2015 3-01) as well as the remote terminal closes as soon as you try to launch it after creating the remote host without toolchain.
It was fixed in development version, you can get it from http://bits.netbeans.org/download/trunk/nightly/latest/ or wait until 8.1 is out. 8.0.2 does not have this fix, sorry
*** Bug 251343 has been marked as a duplicate of this bug. ***
*** Bug 254518 has been marked as a duplicate of this bug. ***
(In reply to Vladimir Kvashin from comment #41) > It was fixed in development version, you can get it from > http://bits.netbeans.org/download/trunk/nightly/latest/ > or wait until 8.1 is out. > > 8.0.2 does not have this fix, sorry Vladimir, Thank you very much! That fixed my problem. Best regards, Georg
*** Bug 254872 has been marked as a duplicate of this bug. ***
*** Bug 254899 has been marked as a duplicate of this bug. ***