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.
Product Version = NetBeans IDE 7.4 RC1 (Build 201309162201) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.7.0_40 Runtime = Java HotSpot(TM) 64-Bit Server VM 24.0-b56 They standard cygwin download has several C++ compilers. Netbeans always uses the same linker (g -o) instead of a linker specific to the compiler, for example i686-pc-cygwin-gcc. The result is that the link libraries are wrong and the link fails. This is consistent with each compiler. The result is that the only compiler C++ usable is gcc. A very short listing of the issue is below. The compiler used is i686-pc-cygwin-g++. Netbeans uses g++ to link. It should be i686-pc-cygwin-g++. Note that the library given is /usr/lib/gcc/x86_64-pc-cygwin/4.8.1. The library should be /usr/lib/gcc/ i686-pc-cygwin/4.7.3/ ... thanks art i686-pc-cygwin-g++ -w -c -g -MMD -MP -MF build/Debug/CygwinPC_4.7.3-Windows/TestUtilities.o.d -o build/Debug/CygwinPC_4.7.3-Windows/TestUtilities.o TestUtilities.cpp mkdir -p dist/Debug/CygwinPC_4.7.3-Windows g++ -o dist/Debug/CygwinPC_4.7.3-Windows/slip build/Debug/CygwinPC_4.7.3-Windows/Slip.o build/Debug/CygwinPC_4.7.3-Windows/SlipBoolOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipCell.o build/Debug/CygwinPC_4.7.3-Windows/SlipCellBase.o build/Debug/CygwinPC_4.7.3-Windows/SlipCharOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipDatum.o build/Debug/CygwinPC_4.7.3-Windows/SlipDoubleOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipErr.o build/Debug/CygwinPC_4.7.3-Windows/SlipException.o build/Debug/CygwinPC_4.7.3-Windows/SlipGlobal.o build/Debug/CygwinPC_4.7.3-Windows/SlipHeader.o build/Debug/CygwinPC_4.7.3-Windows/SlipHeaderOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipLongOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipPointer.o build/Debug/CygwinPC_4.7.3-Windows/SlipPtrOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipReadList.o build/Debug/CygwinPC_4.7.3-Windows/SlipReader.o build/Debug/CygwinPC_4.7.3-Windows/SlipReaderCell.o build/Debug/CygwinPC_4.7.3-Windows/SlipReaderOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipSequencer.o build/Debug/CygwinPC_4.7.3-Windows/SlipStringConst.o build/Debug/CygwinPC_4.7.3-Windows/SlipStringNonConst.o build/Debug/CygwinPC_4.7.3-Windows/SlipStringOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipSublist.o build/Debug/CygwinPC_4.7.3-Windows/SlipSublistOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipUndefinedOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipUnsignedCharOP.o build/Debug/CygwinPC_4.7.3-Windows/SlipUnsignedLongOP.o build/Debug/CygwinPC_4.7.3-Windows/Test.o build/Debug/CygwinPC_4.7.3-Windows/TestGlobal.o build/Debug/CygwinPC_4.7.3-Windows/TestHeader.o build/Debug/CygwinPC_4.7.3-Windows/TestMisc.o build/Debug/CygwinPC_4.7.3-Windows/TestOperators.o build/Debug/CygwinPC_4.7.3-Windows/TestReader.o build/Debug/CygwinPC_4.7.3-Windows/TestReplace.o build/Debug/CygwinPC_4.7.3-Windows/TestSequencer.o build/Debug/CygwinPC_4.7.3-Windows/TestUtilities.o /usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld: i386 architecture of input file `build/Debug/CygwinPC_4.7.3-Windows/Slip.o' is incompatible with i386:x86-64 output
Created attachment 141610 [details] IDE log
Cannot reproduce the bug.IDE always use linker which is used as compiler.Please provide steps to reproduce.
The latest cygwin 64 bit development system has 11(?) compilers. 1: Download cygwin64 (http://www.cygwin.com install 64-bit setup et al. 2: Tools->Options->C/C++->add add a cygwin compiler such as x86_64-pc-cygwin, but not gcc (the default compiler). a. Update 3: In a given C/C++ project, right click on the project name ->properties->build and select the compiler just added. 4: Run->Clean and Build the project In my case, there are just oodles of linker errors. Instead of the linker associated with x86_64-pc-cygwin being used, the default linker, g++ (/usr/bin/g++.exe), is used giving access to the wrong libraries. (The linker is actually an option given to the g++ compiler.) All the compilers and assemblers in the current 64-bit cygwin download are given below. They should be viewed using a fixed font. The default 'gcc' works just fine in Netbeans. I believe that one of the Mingw's work but that is it. compile command g++ -w -c -g -MMD -MP -MF link command g++ -o gcc.exe 4.8.1 64-bits i686-pc-cygwin-gcc.exe 4.8.1 linking w/x86_64-pc-cygwin/4.8.1 i686-pc-cygwin-gcc-4.7.3.exe 4.7.3 linking w/x86_64-pc-cygwin/4.8.1 x86_64-pc-cygwin-gcc.exe 4.8.1 64-bits x86_64-pc-cygwin-gcc-4.8.1.exe 4.8.1 64-bits i686-pc-mingw32-gcc.exe 4.7.3 linking w/x86_64-pc-cygwin/4.8.1 i686-pc-mingw32-gcc-4.7.3.exe 4.7.3 linking w/x86_64-pc-cygwin/4.8.1 i686-w64-mingw32-gcc.exe 4.8.1 linking w/x86_64-pc-cygwin/4.8.1 i686-w64-mingw32-gcc-4.8.1.exe 4.8.1 linking w/x86_64-pc-cygwin/4.8.1 x86_64-w64-mingw32-gcc.exe 4.8.1 compiler incompatibilities x86_64-w64-mingw32-gcc-4.8.1.exe 4.8.1 compiler incompatibilities Some compiler statistics. compiler command -v | tr ' ' '\n' | egrep 'build|target|host' gcc.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=x86_64-pc-cygwin i686-pc-cygwin-gcc.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=i686-pc-cygwin i686-pc-cygwin-gcc-4.7.3.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=i686-pc-cygwin x86_64-pc-cygwin-gcc.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=x86_64-pc-cygwin x86_64-pc-cygwin-gcc-4.8.1.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=x86_64-pc-cygwin i686-pc-mingw32-gcc.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=i686-pc-mingw32 i686-pc-mingw32-gcc-4.7.3.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=i686-pc-mingw32 i686-w64-mingw32-gcc.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=i686-w64-mingw32 i686-w64-mingw32-gcc-4.8.1.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=i686-w64-mingw32 x86_64-w64-mingw32-gcc.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=x86_64-w64-mingw32 x86_64-w64-mingw32-gcc-4.8.1.exe build=x86_64-pc-cygwin host=x86_64-pc-cygwin target=x86_64-w64-mingw32 as.exe i686-pc-cygwin-as.exe i686-pc-mingw32-as.exe i686-w64-mingw32-as.exe x86_64-w64-mingw32-as.exe
(In reply to aschwarz1309 from comment #3) > The latest cygwin 64 bit development system has 11(?) compilers. > 1: Download cygwin64 (http://www.cygwin.com install 64-bit setup et al. > 2: Tools->Options->C/C++->add add a cygwin compiler such as > x86_64-pc-cygwin, but not gcc (the default compiler). > a. Update Please attach screen shot.
Created attachment 141703 [details] Screen Shots pdf file of screenshots for cygwin compiler used, build compiler used, and output of clean and build for C and C++ projects
Now for the not so good news and the really bad news. NOT SO GOOD: I took your negative indications to heart and changed the compiler used on a smaller (much smaller) project 'C' project. As you have observed, it built correctly, but, it failed to run and gave the following error message: "RUN FAILED (exit value 127, total time: 30ms)" THE REALLY BAD NEWS: I recompiled and built the larger 'C++' project using the same compiler toolset as for the smaller project and received the same results as before, to wit, everything compiled correctly but the wrong linker was used leading to just oodles of bad messages. An attachment is included which includes: Page 1: Tools->Options->C++ for the compiler used in both cases Page 2: right click->Project (name)->Properties->build Page 3: Clean and Build output for the C++ project Page 4: Clean and Build output for the C project
Please attach output of following commands: env make -p Run commands in cygwin terminal.
And please look at project properties: Build->C++ Compiler and Linker. What do fields Tool contain?
Created attachment 141710 [details] make -p Umm. Apparently I can't attach two files. Umm. The env > env 2>&1 listing is below. The properties->C++ tools entry is g++, which is probably incorrect? I guess my question, if this is wrong, is why isn't the appropriate "Tool" extracted from the compiler? I would think that since you know about Cygwin and MinGW then you know enough to get the appropriate toolset? Anyhow, here's the environment data. HOMEPATH=\Users\skidmarks MANPATH=/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man APPDATA=C:\Users\skidmarks\AppData\Roaming ProgramW6432=C:\Program Files HOSTNAME=2600k-PC JDK=jdk1.7.0_40 SHELL=/bin/bash TERM=xterm PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel WINDIR=C:\Windows VS80COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\ PUBLIC=C:\Users\Public OLDPWD=/cygdrive/e/home/skidmarks/Projects/SLIP ANTLR=antlr-4.1-complete.jar USERDOMAIN=2600k-PC CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files OS=Windows_NT ALLUSERSPROFILE=C:\ProgramData hprofile=$HOME/.profile USER=skidmarks !::=::\ TEMP=/tmp temp=C:\Users\SKIDMA~1\AppData\Local\Temp VS90COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\ COMMONPROGRAMFILES=C:\Program Files\Common Files tmp=C:\Users\SKIDMA~1\AppData\Local\Temp MICROSOFT=/ProgramFiles86/Microsoft\ Office PROGRAM=/ProgramFiles WINNT=/Windows PARSE=C:/cygwin64/usr/local/lib/antlr-4.1-complete.jar MYHOME=/cygdrive/e/home/skidmarks QTJAVA=C:\Program Files (x86)\Java\jre7\lib\ext\QTJava.zip USERNAME=skidmarks PROCESSOR_LEVEL=6 ProgramFiles(x86)=C:\Program Files (x86) PATH=.:/ProgramFiles/Java/jdk1.7.0_40/bin/:/usr/local/bin:/usr/bin:/ProgramFiles86/AMD APP/bin/x86_64:/ProgramFiles86/AMD APP/bin/x86:/ProgramFiles/Common Files/Microsoft Shared/Windows Live:/ProgramFiles86/Common Files/Microsoft Shared/Windows Live:/Windows/system32:/Windows:/Windows/System32/Wbem:/ProgramFiles86/ATI Technologies/ATI.ACE/Core-Static:/ProgramFiles86/Microsoft SQL Server/90/Tools/binn:/ProgramFiles86/Microsoft SQL Server/80/Tools/Binn:/ProgramFiles86/Windows Live/Shared:/ProgramFiles86/Common Files/HP/Digital Imaging/bin:/ProgramFiles86/HP/Digital Imaging/bin:/ProgramFiles86/HP/Digital Imaging/bin/Qt/Qt 4.3.3:/ProgramFiles/doxygen/bin:/Windows/System32/WindowsPowerShell/v1.0:/ProgramFiles86/Graphviz2.30/bin:/Windows/System32/WindowsPowerShell/v1.0:/ProgramFiles86/QuickTime/QTSystem:/usr/lib/lapack:/ProgramFiles86:/ProgramFiles PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ JAVA=/ProgramFiles/Java/jdk1.7.0_40/bin/ ByPass=1 FP_NO_HOST_CHECK=NO PWD=/cygdrive/e/home/skidmarks/Projects/SLIP/tmp SYSTEMDRIVE=C: AMDAPPSDKROOT=C:\Program Files (x86)\AMD APP\ LANG=en_US.UTF-8 USERPROFILE=C:\Users\skidmarks TZ=America/Los_Angeles PS1=\W >> LOGONSERVER=\\2600K-PC CommonProgramW6432=C:\Program Files\Common Files PROCESSOR_ARCHITECTURE=AMD64 LOCALAPPDATA=C:\Users\skidmarks\AppData\Local HISTCONTROL=ignoredups ProgramData=C:\ProgramData SHLVL=1 HOME=/cygdrive/e/home/skidmarks PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC HOMEDRIVE=C: COMSPEC=C:\Windows\system32\cmd.exe TMP=/tmp SYSTEMROOT=C:\Windows PRINTER=HP Officejet 6500 E709a Series PROCESSOR_REVISION=2a07 CLASSPATH=. VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\ INFOPATH=/usr/local/info:/usr/share/info:/usr/info: PROGRAMFILES=C:\Program Files PROGRAM86=/ProgramFiles86 NUMBER_OF_PROCESSORS=8 asl.log=Destination=file SESSIONNAME=Console COMPUTERNAME=2600K-PC WCDHOME=/cygdrive/e/home/skidmarks/.wcd _=/usr/bin/env
(In reply to aschwarz1309 from comment #9) > The properties->C++ tools entry is g++, which is probably incorrect? I guess > my question, if this is wrong, is why isn't the appropriate "Tool" extracted > from the compiler? I would think that since you know about Cygwin and MinGW > then you know enough to get the appropriate toolset? Try to change "Tool" in this two options on "default" value (action in property poupup menu). Does it fix issue?
I am on my laptop, not my desktop. This is what I observed: Changing the Project->properties->build->Test collection a. Project->properties->C Compiler->Tool changed b. Project->properties->C++ Compiler->Tool did not change Physically altering the C++ Compiler->Tool to be compatible with the Build Test Collection allowed successful compilation and linking. The C Compiler->Tool change was done by Netbeans. Other than the Default Cygwin development and one of the MinGW toolsets, run was not successful, a previous post contains the error message. Neither C nor C++ projects can execute successfully with other than the Default Cygwin toolset. I haven't checked MinGW yet. So there are two issues. 1: Netbeans alters the C Compiler->Tool to be compatible with build->Test collection but does not do so for C++ Compiler->Tool. 2: There is a residual issue with executing compiled code with other than the default Cygwin toolset. art
(In reply to aschwarz1309 from comment #11) > So there are two issues. > 1: Netbeans alters the C Compiler->Tool to be compatible with build->Test > collection but does not do so for C++ Compiler->Tool. At first the fields Tool have a "default value". In this state the compiler tool and linker tool always are taken from tool collection. After first editing of the fields IDE uses user value as linker or compiler tool. This is by design. There is no issue. If you have steps where IDE changes the fields behind you, please reopen bug with steps. (For example: create welcome sample project, ....., project is not compiled). > 2: There is a residual issue with executing compiled code with other than > the default Cygwin toolset. Please, file separate bug with steps to reproduce.
> So there are two issues. > 1: Netbeans alters the C Compiler->Tool to be compatible with build->Test > collection but does not do so for C++ Compiler->Tool. At first the fields Tool have a "default value". In this state the compiler tool and linker tool always are taken from tool collection. After first editing of the fields IDE uses user value as linker or compiler tool. This is by design. There is no issue. If you have steps where IDE changes the fields behind you, please reopen bug with steps. (For example: create welcome sample project, ....., project is not compiled). I don't feel that maintaining the status quo is a satisfactory solution in that: 1: There are differences in behavior for the same condition between the C and C++ operations. To wit, the C Compiler->Tool correctly changes the linker and the C++ Compiler->Tool does not. At the end of the day a user can change compilers and build code with a C compiler but not with a C++ compiler. 2: The result of maintaining the status quo is that a developer with C and C++ artifacts must remember to change only the C++ Compiler->Tools when deploying the code with a new compiler. 3: Keeping the existing behavior does not seem reasonable from the standpoint that Netbeans is knowingly (by design) not enabling a successful build when there is a reasonable alternative. 4: The decision to maintain the status quo leads to developer confusion and makes the decision to use Netbeans problematic on large projects. My personal and strong belief is that this behavior is just plain wrong. An operation which can be automated is made manual in a way so confusing that it will lead to derisive comments on an otherwise excellent product. I am puzzled why anyone who would deliberately design a flaw into their system would even claim that this is a good design decision. It is a flaw, and a serious one. For myself it has caused over a months delay in progress just to find out what the problem is, and then to discover that the issue was deliberately designed into the system. For gosh sake, rethink the issues and remove the flaw. art
So it is an enhancement.