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.