Problems on Qt on NetBeans - qt

After having solved a Qt configured problem on my system, I have now installed NetBeans and everything is OK. It is just that I have the following problem. Here is the code:
#include <QtGui/QApplication>
#include <QDir>
#include <QFileInfo>
#include <QtDebug>
int main(int argc, char **argv) {
foreach(QFileInfo drive,QDir::drives()){
qDebug()<<"Drive: "<<drive.absolutePath();
QDir dir=drive.dir();
dir.setFilter(QDir::Dirs);
foreach(QFileInfo rootDirs,dir.entryInfoList())
qDebug()<< " "<<rootDirs.fileName();
}
return 0;
// return app.exec();
}
and errors are
/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make[1]: Entering directory `/home/david/NetBeansProjects/QtApplication_1'
/usr/bin/qmake VPATH=. -o qttmp-Debug.mk nbproject/qt-Debug.pro
mv -f qttmp-Debug.mk nbproject/qt-Debug.mk
/usr/bin/make -f nbproject/qt-Debug.mk dist/Debug/GNU-Linux-x86/QtApplication_1
make[2]: Entering directory `/home/david/NetBeansProjects/QtApplication_1'
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -Inbproject -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -Inbproject -I. -o build/Debug/GNU-Linux-x86/Qt1.o Qt1.cpp
Qt1.cpp:7: warning: unused parameter ‘argc’
Qt1.cpp:7: warning: unused parameter ‘argv’
g++ -o dist/Debug/GNU-Linux-x86/QtApplication_1 build/Debug/GNU-Linux-x86/Qt1.o build/Debug/GNU-Linux-x86/main.o -L/usr/lib -lQtGui -lQtCore -lpthread
build/Debug/GNU-Linux-x86/main.o: In function `main':
/home/david/NetBeansProjects/QtApplication_1/main.cpp:10: multiple definition of `main'
build/Debug/GNU-Linux-x86/Qt1.o:/home/david/NetBeansProjects/QtApplication_1/Qt1.cpp:7: first defined here
collect2: ld returned 1 exit status
make[2]: *** [dist/Debug/GNU-Linux-x86/QtApplication_1] Error 1
make[2]: Leaving directory `/home/david/NetBeansProjects/QtApplication_1'
make[1]: *** [.build-conf] Error 2
make[1]: Leaving directory `/home/david/NetBeansProjects/QtApplication_1'
make: *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 1s)
How can I fix this problem?

According to that output, you are compiling two source files Qt1.cpp and main.cpp, both of which define the function main(). You need to remove one of those two files from your project or remove the definition of main() from one of them.
As an added step to get rid of the warning about unused parameters in main(), change it to
main(int /*argc*/, char **/*argv*/)
until you need to use those arguments.

Related

__e_acsl_assert is not getting added for all given assert in .i file

I am new to Frama-C. I specifically need to use e-acsl plugin for verification purposes. I used first.i file as
int main(void) {
int x = 0;
/∗# assert x == 0; ∗/
/∗# assert x == 1; ∗/
return 0;
}
Created monitored_first.c file from first.i file using the following command.
$ frama-c -e-acsl first.i -then-last -print -ocode monitored_first.c
The main function inside the monitored_first.c looks like the one below.
int main(void)
{
int __retres;
__e_acsl_memory_init((int *)0,(char ***)0,8UL);
int x = 0;
__retres = 0;
__e_acsl_memory_clean();
return __retres;
}
It is not adding e_acsl assertion for x==1.
I tried it using the "e-acsl-gcc.sh" script , which generated the monitored_first.i file. But the main function inside monitored_first.i is same as that in monitored_first.c.
$ e-acsl-gcc.sh -c -omonitored_first.i first.i
The above command generated two executable, "a.out.e-acsl" and "a.out". It also generates some warnings when run in ubuntu 22.04 as follows:
/home/amrutha/.opam/4.11.1/bin/frama-c -remove-unused-specified-functions -machdep gcc_x86_64 '-cpp-extra-args= -std=c99 -D_DEFAULT_SOURCE -D__NO_CTYPE -D__FC_MACHDEP_X86_64 ' -no-frama-c-stdlib first.i -e-acsl -e-acsl-share=/home/amrutha/.opam/4.11.1/bin/../share/frama-c/e-acsl -then-last -print -ocode monitored_first.i
[kernel] Parsing first.i (no preprocessing)
[e-acsl] beginning translation.
[kernel] Parsing FRAMAC_SHARE/e-acsl/e_acsl.h (with preprocessing)
/tmp/ppannot15ad34.c:362: warning: "__STDC_IEC_60559_BFP__" redefined
362 | #define __STDC_IEC_60559_BFP__ 201404L
|
In file included from <command-line>:
/usr/include/stdc-predef.h:39: note: this is the location of the previous definition
39 | # define __STDC_IEC_60559_BFP__ 201404L
|
/tmp/ppannot15ad34.c:363: warning: "__STDC_IEC_60559_COMPLEX__" redefined
363 | #define __STDC_IEC_60559_COMPLEX__ 201404L
|
In file included from <command-line>:
/usr/include/stdc-predef.h:49: note: this is the location of the previous definition
49 | # define __STDC_IEC_60559_COMPLEX__ 201404L
|
[e-acsl] translation done in project "e-acsl".
+ gcc -std=c99 -m64 -g -O2 -fno-builtin -fno-merge-constants -Wall -Wno-long-long -Wno-attributes -Wno-nonnull -Wno-undef -Wno-unused -Wno-unused-function -Wno-unused-result -Wno-unused-value -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-implicit-function-declaration -Wno-empty-body first.i -o a.out
+ gcc -DE_ACSL_SEGMENT_MMODEL -std=c99 -m64 -g -O2 -fno-builtin -fno-merge-constants -Wall -Wno-long-long -Wno-attributes -Wno-nonnull -Wno-undef -Wno-unused -Wno-unused-function -Wno-unused-result -Wno-unused-value -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-implicit-function-declaration -Wno-empty-body -I/home/amrutha/.opam/4.11.1/bin/../share/frama-c/e-acsl -o a.out.e-acsl monitored_first.i /home/amrutha/.opam/4.11.1/bin/../share/frama-c/e-acsl/e_acsl_rtl.c /home/amrutha/.opam/4.11.1/bin/../lib/frama-c/e-acsl/libeacsl-dlmalloc.a -lgmp -lm
In ubuntu 20.04 there is no any warning, only the end part is getting displayed. When run ./a.out.e-acsl , it simply run the code without any message, which is not supposed. The expected output should look like this:
$ ./a.out.e-acsl
first.i: In function 'main'
first.i:4: Error: Assertion failed:
The failing predicate is:
x == 1.
Aborted (core dumped)
$ echo $?
134
I tried it in ubuntu 22.04 with opam version 2.1.2 and Fragma-C 25.0
and ubuntu 20.04 with opam version 2.0.5 and Fragma-C 25.0
The same issue has been posted to Frama-C's public bug tracking and it seems the cause might have been the non-ASCII asterisk characters used in the ACSL annotations: ∗ instead of *.
I still don't understand how the comments could parse at all (my compiler gives a syntax error), but the user seems to indicate that replacing them solved the problem.
In any case, in similar situations one can either use the Frama-C GUI to open the parsed file and check if Frama-C recognizes the ACSL annotations (they should show up in the CIL normalized code), or try other analyses, e.g. running frama-c -eva and checking that it detects the annotations.

Errors in qvariant.h during compilation

I am getting a variety of compilation errors relating to qvariant when compiling my program. I have not modified the Qt libs/source, so why am I getting these errors? (What do they mean)
/Qt/5.9.9/gcc_64/mkspecs/linux-g++ -o tl_ansi_codes.o /mydir/tl_ansi_formatting/tl_ansi_codes.cpp
In file included from /opt/Qt/5.9.9/gcc_64/include/QtCore/qlocale.h:43,
from /opt/Qt/5.9.9/gcc_64/include/QtCore/qtextstream.h:46,
from /opt/Qt/5.9.9/gcc_64/include/QtCore/qdebug.h:49,
from /opt/Qt/5.9.9/gcc_64/include/QtCore/QDebug:1,
from /mydir/tl_ansi_formatting/tl_ansi_codes.cpp:9:
/opt/Qt/5.9.9/gcc_64/include/QtCore/qvariant.h: In constructor ‘QVariant::QVariant(QVariant&&)’:
/opt/Qt/5.9.9/gcc_64/include/QtCore/qvariant.h:265:25: warning: implicitly-declared ‘constexpr QVariant::Private& QVariant::Private::operator=(const QVariant::Private&)’ is deprecated [-Wdeprecated-copy]
265 | { other.d = Private(); }
| ^
/opt/Qt/5.9.9/gcc_64/include/QtCore/qvariant.h:380:16: note: because ‘QVariant::Private’ has user-provided ‘QVariant::Private::Private(const QVariant::Private&)’
380 | inline Private(const Private &other) Q_DECL_NOTHROW
| ^~~~~~~
g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -Dproject_vls=1 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_SQL_LIB -DQT_CORE_LIB -I/mydir//project -I. -
/opt/Qt/5.9.9/gcc_64/include/QtCore/qvariant.h: In constructor ‘QVariant::QVariant(QVariant&&)’:
/opt/Qt/5.9.9/gcc_64/include/QtCore/qvariant.h:265:25: warning: implicitly-declared ‘constexpr QVariant::Private& QVariant::Private::operator=(const QVariant::Private&)’ is deprecated [-Wdeprecated-copy]
265 | { other.d = Private(); }
The best solution available is just to ignore it, Or upgrade to qt6.
To Ignore the warning, just add
QMAKE_CXXFLAGS += -Wno-deprecated-copy
In all of your .pro files.
This will ignore all the deprecated-copy warning; you can also ignore for debug or release build using QMAKE_CXXFLAGS_DEBUG or QMAKE_CXXFLAGS_RELEASE.

using R's c code in my standalone executables: "Undefined symbols"

Suppose I have the following c source code, in dexp_test.c:
#include <stdio.h>
double dexp(double x, double scale, int log);
int main() {
double x;
x = dexp(1 , 2, 0);
printf("Value: %f\n", x);
return 0;
}
where dexp is defined in R's source code (https://github.com/wch/r-source/blob/trunk/src/nmath/dexp.c). I would like to compile this to a standalone executable. I have R 4.0 installed on my system. I have the following gcc lines:
gcc r-source/src/nmath/dexp.c -I/Library/Frameworks/R.framework/Versions/4.0/Resources/include -c -o a.o
gcc dexp_test.c -c -o b.o
These lines run just fine on my system and I am left with new files a.o and b.o without errors.
When I run this line to get an executable:
gcc -o test_exp a.o b.o
...I get these errors:
Undefined symbols for architecture x86_64:
"_R_NaN", referenced from:
_Rf_dexp in a.o
"_R_NegInf", referenced from:
_Rf_dexp in a.o
"_dexp", referenced from:
_main in b.o
(maybe you meant: _Rf_dexp)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I'm definitely missing something conceptually here; how do I get this to compile? If it helps, I'm on OSX 15.6, and the output of gcc -v is
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
You should mention the operating system you are using.
You need to include the appropriate headers. And tell the linker where and which libraries you want to use.
So your source should be
#include <stdio.h>
#include <R.h>
#include <Rmath.h>
int main() {
double x;
x = dexp(1 , 2, 0);
printf("Value: %f\n", x);
return 0;
}
And on the command line you should use the following
gcc -I/Library/Frameworks/R.framework/Versions/4.0/Resources/include -L/Library/Frameworks/R.framework/Versions/4.0/Resources/lib -lR -o test_exp trydexp.c

Opencv2 cvtColor() does not work

I am using OpenCV2 on Ubuntu 12.04. I can successfully run image read-display codes.
However I am not able to run codes with inbuilt functions eg. cvtColor()
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <stdio.h>
int main(int argc, char *argv[])
{
cv::Mat image = cv::imread("img.jpg");
if( image.data == NULL )
{
printf( "file cannot be loaded\n");
return 1;
}
cv::namedWindow("My");
cv::imshow("My", image);
cv::Mat result;
cv::cvtColor(image, result, CV_BGR2Luv);
cv::imwrite("outImg.jpg", result);
cv::waitKey(0);
return 0;
}
I am using Qt-creator for my OpenCV
After compiling with --libs, --cflags I get following compiler error:
make: Entering directory `/home/swaroop/Work/ai-junkies/cuda/uc_davis/opencv2.x/OpenCV2Test'
g++ -g -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_WEBKIT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I/usr/include/opencv -I. -o main.o main.cpp
main.cpp: In function 'int main(int, char**)':
main.cpp:22:29: error: 'CV_BGR2Luv' was not declared in this scope
main.cpp:22:39: error: 'cvtColor' was not declared in this scope
Please help me fix this.
cvtColor declared in opencv2/imgproc/imgproc.hpp
keep in mind it's #include not #import
#include <opencv2/imgproc/imgproc.hpp>
Alternatively, if you are testing things and not concerned with overdoing the includes, you can simply have one line:
#include <opencv2/opencv.hpp>
and it will include most opencv2 headers.

UNIX symbol referencing error

Greetings Everyone.
I'm currently trying to compile a multiple-language program (C, C++ and FORTRAN) using GNU compilers in UNIX (g++, gcc & f77 respectively).
All my sources are compiling into objects with no errors however I encounter a symbol referencing error as they are linked as shown below:
f77 -L/usr/sfw/lib -R/usr/sfw/lib -lgcc_s -o SlowDynamic.exe main.o \
SA.o mersenne.o CFE.o MA_57.o blas.o MA_57_Depend.o Metis.o\
BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o
NOTICE: Invoking /usr/bin/f90 -f77 -ftrap=%none -L/usr/sfw/lib -R/usr/sfw/lib -lgcc_s -o SlowDynamic.exe main.o SA.o mersenne.o CFE.o MA_57.o blas.o MA_57_Depend.o Metis.o BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o
Undefined first referenced
symbol in file
_Znwj SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEED1Ev SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEEC1Ev SA.o
_ZNKSsixEj main.o
_ZNSolsEPFRSoS_E SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEE4openEPKcSt13_Ios_Openmode SA.o
_ZNSolsEd SA.o
_ZNSolsEi SA.o
__cxa_end_catch SA.o
__cxa_begin_catch SA.o
_ZdlPv SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEE7is_openEv SA.o
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c SA.o
_ZSt4cerr SA.o
_ZSt4cout SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEE5closeEv SA.o
_ZNSt8ios_base4InitD1Ev main.o
_ZNSt8ios_base4InitC1Ev main.o
_ZNKSt9basic_iosIcSt11char_traitsIcEEntEv SA.o
__gxx_personality_v0 main.o
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc SA.o
__cxa_rethrow SA.o
_ZNKSs4sizeEv main.o
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ SA.o
ld: fatal: Symbol referencing errors. No output written to SlowDynamic.exe
*** Error code 1
make: Fatal error: Command failed for target `SlowDynamic.exe'
With the Following Makefile:
products: SlowDynamic.exe
SlowDynamic.exe: main.o SA.o mersenne.o CFE.o BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o MA_57.o blas.o MA_57_Depend.o Metis.o
f77 -L/usr/sfw/lib -R/usr/sfw/lib -lgcc_s -o SlowDynamic.exe main.o \
SA.o mersenne.o CFE.o MA_57.o blas.o MA_57_Depend.o Metis.o\
BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o
main.o: main.cpp
g++ -c -o main.o main.cpp
SA.o: SA.cpp
g++ -c -o SA.o SA.cpp
mersenne.o: mersenne.cpp
g++ -c -o mersenne.o mersenne.cpp
CFE.o: CFE.c
gcc -c -o CFE.o CFE.c
MA_57.o: MA_57.f
f77 -c -o MA_57.o MA_57.f
blas.o: blas.f
f77 -c -o blas.o blas.f
MA_57_Depend.o: MA_57_Depend.f
f77 -c -o MA_57_Depend.o MA_57_Depend.f
Metis.o: Metis.f
f77 -c -o Metis.o Metis.f
BCs.o: BCs.c
gcc -c -o BCs.o BCs.c
EMatrix.o: EMatrix.c
gcc -c -o EMatrix.o EMatrix.c
Numbering.o: Numbering.c
gcc -c -o Numbering.o Numbering.c
KMatrix.o: KMatrix.c
gcc -c -o KMatrix.o KMatrix.c
Solve.o : Solve.c
gcc -c -o Solve.o Solve.c
clean:
rm *.o Main.exe *.gpi
I have read that this is typically the fault of missing libraries. I know the C & FORTRAN code compiles fine seperatly (respective libraries included) as does the C++ code when compiled on its own. This leads me to believe that it is the interface between the two programs that causes the error. Unfortunatly I've little to no experiance debugging this sort of problem and without any clues from the linker its hard to move forward. I'll include the necessary parts of my program that deal with the interface between the two sides of the program.
First the C++ part: SA.h, SA.cpp
SA.h:
class SimAnneal {
...
std::vector<float> DensityArray;
std::vector<float> EnergyArray;
public
double ObjFunction ();
...
}
SA.ccp:
#include <math.h>
#include <iostream>
#include <fstream>
#include <time.h>
#include <vector>
#include "SA.h"
#include "CFE.h"
#include "randomc.h" //Includes mersenne.cpp
double SimAnneal::ObjFunction ()
{
CFE(&DensityArray[0], &EnergyArray[0]);
// sends pointers of both arrays to CFE.c and modifies EnergyArray as
// shown in CFE.c
double SumStrainEnergy = 0;
for (int i = 0; i < EnergyArray.size(); i++)
{
SumStrainEnergy += EnergyArray[i]; //Effectively sum of array
//engy[] from CFE.c
}
return SumStrainEnergy;
}
Secondly the C/FORTRAN part: CFE.h, CFE.c
CFE.h:
#ifdef __cplusplus
extern "C" {
#endif
void CFE(float density[], float energy[]);
#ifdef __cplusplus
}
#endif
CFE.c:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include "BCs.h"
#include "EMatrix.h"
#include "Numbering.h"
#include "KMatrix.h"
#include "fg_types.h"
#include "Solve.h"
void CFE(float density[], float energy[])
{
...stuff...
float * dens;
dens = density; //pass pointer of array density[0] in SA.cpp to CFE.c
...more stuff....
float * engy;
engy = energy; //pass pointer of array energy[0] in SA.cpp to CFE.c
***Modify engy in some respects****
}
Essentially the ObjFunction in SA.cpp is called in main.cpp, which contains main().
Is there any visible fault?
Is there any way I can ask the linker to announce what causes / where the error occours in the linking?
Any help will be much appriciated.
Thank you.
+++ EDIT: Verbose feedback +++
birch $ g++ -v Hello.cpp
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
/usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/cc1plus -quiet -v Hello.cpp -quiet -dumpbase Hello.cpp -mcpu=v7 -auxbase Hello -version -o /var/tmp//cc2JwHRb.s
ignoring nonexistent directory "/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../sparc-sun-solaris2.10/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/sparc-sun-solaris2.10
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/backward
/usr/local/include
/usr/sfw/include
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/include
/usr/include
End of search list.
GNU C++ version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) (sparc-sun-solaris2.10)
compiled by GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Hello.cpp:6:2: warning: no newline at end of file
/usr/ccs/bin/as -V -Qy -s -xarch=v8 -o /var/tmp//ccvAshv7.o /var/tmp//cc2JwHRb.s
/usr/ccs/bin/as: Sun Compiler Common 10 Patch 09/04/2007
/usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -R/usr/sfw/lib -Y P,/usr/ccs/lib:/usr/lib -Qy /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crt1.o /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crtbegin.o -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3 -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../sparc-sun-solaris2.10/lib -L/usr/ccs/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../.. /var/tmp//ccvAshv7.o -lstdc++ -lm -R/usr/sfw/lib -lgcc_s -lgcc -lc -R/usr/sfw/lib -lgcc_s -lgcc -lc /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crtend.o /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
Some of those undefined symbols clearly relate to standard C++ classes (i.e. ostream).
You need to ensure that you've got at least the C++ library linked (-lstdc++).
To debug further:
Run f77, g++, etc, in verbose mode (-v) with single language programs and see which libraries the compiler automatically includes in the link phase for each language
For symbols that are in your own code, use nm to look at both the native language declarations and non-native invocations to determine how they mismatch. There are rules about underscore prefixes, etc, which are commonly applied.
(As far as I can remember, but it's 15 years since I last linked C and Fortran, C symbols are always internally prefixed with an underscore, but Fortran symbols are not).
The main problem is that you're doing the linking step with the F77 compiler, which doesn't link in the C++ standard library by default. Like Alnitak said, specify -lg++ explicitly during linking to get it.
Also, if you are calling C++ functions from C code (or from F77 code), make sure you enclose the prototypes of those functions in an extern "C" {} block so that their symbol names show up in the standardized C form, rather than the mangled C++ form (this restricts you from some things, though, such as overloading). See here for more information.
Usually, you should link a program containing any C++ code with the C++ compiler, adding the Fortran and C libraries to the link line. Further, the standard advice is to make the main() program C++, nor Fortran, since the startup sequences for C++ are different. Make the Fortran code into a function that you call from a minimal C++ main.
int main(void) // Assuming no argument handling - probably incorrect
{
return(fortran_main_program());
}

Resources