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.
When attempting to debug C/C++, there is an error from the dynamic linker that unbuffer-Mac_OS_X-x86.dylib could not be loaded. The error message is: dyld: could not load inserted library: /Applications/Dev/NetBeans 6.5.1.app/Contents/Resources/NetBeans/cnd2/bin/unbuffer-Mac_OS_X-x86.dylib This is on a PPC machine. When looking in "NetBeans 6.5.1.app/Contents/Resources/NetBeans/cnd2/bin" there are PPC libraries. On a related note, there is no PPC version of GdbHelper-Mac_OS_X-*.dylib either. Maybe a separate issue is that the runtime platform is not detected as PPC, and assumes x86 instead. Product Version: NetBeans IDE 6.5.1 (Build 200903060201) with all updates (there are no updates to 6.5.1 release as of now) Java: 1.5.0_16; Java HotSpot(TM) Client VM 1.5.0_16- C/C++ plugin: 1.4.4 (Source: NetBeans IDE 6.5.1 (Build 200903060201) Regards, Anders
Typo at: "there are PPC libraries" should of course be "there are no PPC libraries"
does application fail? or it is just a warning message? does usual project run work? (unbuffer is used only when output is in output window -> see project properties/run)
Indeed, it happens only when console type is set to "output window", with "external terminal" it works. With "output window" the following happens: - Netbeans shows an error message that the debugger exited with an exit status != 0. - In the (Build, Debug) output tab, the dyld error is printed followed by a stack trace of gdb. Normal project run (with "output window") shows the same dyld error, followed by "Run failed. Exit value 133." Run with "external terminal" works. I just find "output window" convenient for non-interactive applications, since it doesn't open a separate terminal window. But I can live with that.
I created issue 161047 to support power pc arch. I'm not sure it will be fixed soon. As a workaround you can go to netbeans/cnd2/src/GdbHelper and compile unbuffer for your machine (both src and makefile are there) then replace netbeans/cnd2/bin/unbuffer-Mac_OS_X-x86.dylib with a new version. It should help.
transferring to execution since debugger was switched to use new execution unbuffer
move to execution subcomponent
There is a similar problem on x86-64 in Netbeans 6.8: dyld: could not load inserted library: /Applications/Dev/NetBeans 6.8.app/Contents/Resources/NetBeans/dlight2/bin/nativeexecution/MacOSX-x86/unbuffer.dylib This file exists, but the netbeans is running in 64-bit mode (or I assume, the JVM is). So it should be loading from MacOSX-x86_64. The issue seems to be the same as on the PPC where the platform is incorrectly detected as x86. A workaround is to remove/rename MacOSX-x86/unbuffer.dylib, and put a symlink there from MacOSX-x86_64/unbuffer.dylib. You can also remove/rename the MacOSX-x86 directory, but then I guess some functionality is lost? I can report it separately if you want. -- Product Version: NetBeans IDE 6.8 (Build 200912041610) Java: 1.6.0_17; Java HotSpot(TM) 64-Bit Server VM 14.3-b01-101 System: Mac OS X version 10.6.2 running on x86_64; MacRoman; en_US (nb) Userdir: /Users/anorland/.netbeans/6.8
anorland, as a workaround could you, please, use -J-Dexecution.no_unbuffer=true while starting the IDE. This should disable the "unbuffer" functionality. =Andrew
I did some more digging, and the culprit in 6.8 is the hostinfo.sh script and the interpretation of the CPUTYPE and CPUFAMILY variables. As far as I understand, CPUFAMILY is expected to be x86, and CPUTYPE to be x86_64 when running on x86_64. But they appear to be used the opposite way elsewhere (in org.netbeans.modules.dlight.nativeexecution). This is what you get on a 64-bit kernel: BITNESS=64 # <-- contradicts what CPU{TYPE,FAMILY} reports CPUFAMILY=x86 CPUTYPE=i386 On a 32-bit kernels: BITNESS=32 CPUFAMILY=x86 CPUTYPE=i386 The problem here is that uname cannot be relied on to determine if 64-bit processes are supported. The kernel is by default running in 32-bit mode, but still supports 64-bit user-space processes. Even on 64-bit kernels uname -p reports i386, while uname -m reports x86_64. Here's what I added to hostinfo.sh <...> elif [ "${OSFAMILY}" = "MACOSX" ]; then ## Start new part if [ "${CPUTYPE}" = "i386" ]; then # Either of the following works CPUTYPE=`(otool -v -f /mach_kernel | grep CPU_TYPE_X86_64 >/dev/null && echo x86_64) || ${CPUTYPE}` # CPUTYPE=`(file /mach_kernel | grep x86_64 >/dev/null && echo x86_64) || ${CPUTYPE}` echo ${CPUTYPE} | egrep x86_64 >/dev/null if [ $? -eq 0 ]; then BITNESS=64 fi fi ## End new part CPUNUM=`hostinfo | awk '/processor.*logical/{print $1}'` OSNAME="MacOSX" OSBUILD=`hostinfo | sed -n '/kernel version/{n;p;}' | sed 's/[ ]*\([^:]*\).*/\1/'` fi This gives the correct values even on 32-bit kernels running on 64-bit hardware. But CPUFAMILY will still be x86 causing the same error. Making CPUFAMILY equal to CPUTYPE makes loading of unbuffer work. This has nothing to with PowerPC of course... Best regards, Anders