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.

Bug 74174 - fail to build helloapp using Sun's compiler collection
Summary: fail to build helloapp using Sun's compiler collection
Status: RESOLVED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 5.x
Hardware: Sun Solaris
: P3 blocker (vote)
Assignee: Thomas Preisler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-30 01:09 UTC by julieg
Modified: 2007-06-27 02:18 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description julieg 2006-03-30 01:09:38 UTC
To reproduce on Solaris sparc:
o create a helloapp sample project
o project property:
  => compiler collection: Sun Compiler collection
  => platform: solaris sparc
o build main project
Running "make -f Makefile CONF=Debug" in /export/home1/tester/HelloApp1/helloapp

make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
cd ../hello1lib; make -f Makefile CONF=Debug
make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
g++    -c -g -o build/Debug/GNU-Solaris-Sparc/hello1.o hello1.cc
rm -f dist/Debug/libhello1lib.a
ar rv dist/Debug/libhello1lib.a build/Debug/GNU-Solaris-Sparc/hello1.o 
ar: creating dist/Debug/libhello1lib.a
ar: writing dist/Debug/libhello1lib.a
a - build/Debug/GNU-Solaris-Sparc/hello1.o
ranlib dist/Debug/libhello1lib.a
`build' is up to date.
cd ../hello2lib; make -f Makefile CONF=Debug
make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
g++    -c -g -o build/Debug/GNU-Solaris-Sparc/hello2.o hello2.cc
rm -f dist/Debug/libhello2lib.a
ar rv dist/Debug/libhello2lib.a build/Debug/GNU-Solaris-Sparc/hello2.o 
ar: creating dist/Debug/libhello2lib.a
ar: writing dist/Debug/libhello2lib.a
a - build/Debug/GNU-Solaris-Sparc/hello2.o
ranlib dist/Debug/libhello2lib.a
`build' is up to date.
CC    -c -g -o build/Debug/Sun-Solaris-Sparc/main.o main.cc
(/export/home1/tester/HelloApp1/helloapp)main.cc:
:(/export/home1/tester/HelloApp1/helloapp)main.cc
CC    -o dist/Debug/helloapp build/Debug/Sun-Solaris-Sparc/main.o
../hello1lib/dist/Debug/libhello1lib.a  ../hello2lib/dist/Debug/libhello2lib.a 
(/export/home1/tester/HelloApp1/helloapp)build/Debug/Sun-Solaris-Sparc/main.o:
:(/export/home1/tester/HelloApp1/helloapp)build/Debug/Sun-Solaris-Sparc/main.o
(/export/home1/tester/HelloApp1/helloapp)../hello1lib/dist/Debug/libhello1lib.a:
:(/export/home1/tester/HelloApp1/helloapp)../hello1lib/dist/Debug/libhello1lib.a
(/export/home1/tester/HelloApp1/helloapp)../hello2lib/dist/Debug/libhello2lib.a:
:(/export/home1/tester/HelloApp1/helloapp)../hello2lib/dist/Debug/libhello2lib.a
Undefined                       first referenced
 symbol                             in file
char*hello2()                   build/Debug/Sun-Solaris-Sparc/main.o
char*hello1()                   build/Debug/Sun-Solaris-Sparc/main.o
ld: fatal: Symbol referencing errors. No output written to dist/Debug/helloapp
*** Error code 1
make: Fatal error: Command failed for target `dist/Debug/helloapp'
Current working directory /export/home1/tester/HelloApp1/helloapp
*** Error code 1
make: Fatal error: Command failed for target `.build-impl'

Build failed. Exit value 1.
Comment 1 Thomas Preisler 2006-03-30 19:40:48 UTC
If you look at the output, you compile the libraries with g++ and the main file
with CC. CC and g++ is NOT link compatible so this won't work. Did you create
the sample on Linux using GNU as compiler set, build it once, then switched
compiler set on the main project to Sun, and recompiled it? You will need to
switch compiler set on all projects including subprojects to same (or compatible
compiler).
Comment 2 julieg 2006-03-30 19:56:34 UTC
I am aware of the mixing g++ and CC compilation and this is the reason why I am
filing the bug. What happen is that helloapp, hello1lib, and hello2lib all
contain project property which allows the user to chose the compiler collection.
 However, since helloapp is the main project and hello1lib and hello2lib are the
dependencies, changing the compiler type for the main project does not propagate
the compiler type to its dependencies.  
I think we should allow the users to chose a global compiler type, so that
they do not need to go through all of the dependent project properties and
change the compiler type.
 
Comment 3 Thomas Preisler 2007-05-23 21:53:03 UTC
Should be fixed as part of 102931 Cannot build project dependent on "C/C++
Dynamic Library" project
Comment 4 julieg 2007-06-26 23:56:33 UTC
Changing the compiler collection on one dependent library does not prpagate
to the main project and its libraries.

Steps to reproduce from CND 070626 on sqao36 (Ubuntu 6):
=> create helloapp project
=> Tools->Options->BuildTools
   default compilers are /usr/bin/gcc & /usr/bin/g++
=> Change hello1lib->Properties->Compiler Collections to SS12 compilers
=> Tools->Options->BuildTools compilers changed to SS12 compilers
=> Click on build project from the menu bar


Running "/usr/bin/make  -f Makefile CONF=Debug" in /export/home/tester/HelloApp_1/helloapp

/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make[1]: Entering directory `/export/home/tester/HelloApp_1/helloapp'
cd ../hello1lib && /usr/bin/make -f Makefile CONF=Debug
make[2]: Entering directory `/export/home/tester/HelloApp_1/hello1lib'
/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make[3]: Entering directory `/export/home/tester/HelloApp_1/hello1lib'
mkdir -p build/Debug/Sun12-Linux-x86
CC    -c -g -o build/Debug/Sun12-Linux-x86/hello1.o hello1.cc
(/export/home/tester/HelloApp_1/hello1lib)hello1.cc:
:(/export/home/tester/HelloApp_1/hello1lib)hello1.cc
mkdir -p dist/Debug
rm -f dist/Debug/libhello1lib.a
ar rv dist/Debug/libhello1lib.a build/Debug/Sun12-Linux-x86/hello1.o 
ar: creating dist/Debug/libhello1lib.a
a - build/Debug/Sun12-Linux-x86/hello1.o
ranlib dist/Debug/libhello1lib.a
make[3]: Leaving directory `/export/home/tester/HelloApp_1/hello1lib'
make[2]: Leaving directory `/export/home/tester/HelloApp_1/hello1lib'
cd ../hello2lib && /usr/bin/make -f Makefile CONF=Debug
make[2]: Entering directory `/export/home/tester/HelloApp_1/hello2lib'
/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make[3]: Entering directory `/export/home/tester/HelloApp_1/hello2lib'
mkdir -p build/Debug/GNU-Linux-x86
g++    -c -g -o build/Debug/GNU-Linux-x86/hello2.o hello2.cc
mkdir -p dist/Debug
rm -f dist/Debug/libhello2lib.a
ar rv dist/Debug/libhello2lib.a build/Debug/GNU-Linux-x86/hello2.o 
ar: creating dist/Debug/libhello2lib.a
a - build/Debug/GNU-Linux-x86/hello2.o
ranlib dist/Debug/libhello2lib.a
make[3]: Leaving directory `/export/home/tester/HelloApp_1/hello2lib'
make[2]: Leaving directory `/export/home/tester/HelloApp_1/hello2lib'
cd ../hello3lib && /usr/bin/make  -f Makefile CONF=Debug
make[2]: Entering directory `/export/home/tester/HelloApp_1/hello3lib'
/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make[3]: Entering directory `/export/home/tester/HelloApp_1/hello3lib'
mkdir -p build/Debug/GNU-Linux-x86
g++    -c -g -o build/Debug/GNU-Linux-x86/hello3.o hello3.cc
mkdir -p dist/Debug
g++     -shared -o dist/Debug/libhello3lib.so build/Debug/GNU-Linux-x86/hello3.o  
/usr/bin/ld: build/Debug/GNU-Linux-x86/hello3.o: relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
build/Debug/GNU-Linux-x86/hello3.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [dist/Debug/libhello3lib.so] Error 1
make[3]: Leaving directory `/export/home/tester/HelloApp_1/hello3lib'
make[2]: *** [.build-impl] Error 2
make[2]: Leaving directory `/export/home/tester/HelloApp_1/hello3lib'
make[1]: *** [.build-subprojects] Error 2
make[1]: Leaving directory `/export/home/tester/HelloApp_1/helloapp'
make: *** [.build-impl] Error 2

Build failed. Exit value 2.
Comment 5 Thomas Preisler 2007-06-27 02:18:20 UTC
It is not a bug. The project system is not designed to do that. There is no good way to handle this automatically and it
is up the the user to update all references