T.R | Title | User | Personal Name | Date | Lines |
---|
3447.1 | seems like a bug to me | DECCXX::MITCHELL | | Thu Feb 13 1997 09:22 | 17 |
| When there's a .c file on the cxx command line, the
file is compiled by cc rather than the C++ compiler
(unless -x cxx is specified).
I think the problem you reported is a bug. That is,
cxx should pass any -g options on the cxx command line
on to cc when compiling .c files. (It already does
that for some options; e.g. -O.) I've entered a bug
report in our internal database for this.
In the meantime, the obvious workaround is to
invoke cc directly to compile the .c files and
then specify the resulting object files on the
cxx command line For example,
cc -g2 -c -o test1.o test1.c
cxx -g2 ... test1.o
|
3447.2 | Other options gone missing too | GALVIA::STONES | Tom Stones | Fri Feb 14 1997 08:04 | 58 |
| The cxx driver doesn't seem to be passing linker options through either.
For example, -hidden option is ignored - see below.
Also, with the -shared option, should it be including
/usr/lib/cmplrs/cxx/_main.o ??
zen> cxx -shared mcm.cxx -hidden mcm_internal.cxx cache.cxx -I. -o libmcm.so -v
>& junk
zen> more junk (extra line breaks added)
mcm.cxx:
/usr/lib/cmplrs/cxx/gemc_cxx -g0 -O2 -thread_safe -Xirf./cxx_repository/zen.ilo.
dec.comaawbea -ptr./cxx_repository -ptsuf.cxx.CXX.C.cc.CC.cpp.c -I. -Xsd./ -o mc
m.o mcm.cxx
0.80u 0.12s 0:01.4 66%
mcm_internal.cxx:
/usr/lib/cmplrs/cxx/gemc_cxx -g0 -O2 -thread_safe -Xirf./cxx_repository/zen.ilo.
dec.comaawbea -ptr./cxx_repository -ptsuf.cxx.CXX.C.cc.CC.cpp.c -I. -Xsd./ -o mc
m_internal.o mcm_internal.cxx
1.38u 0.17s 0:01.9 80%
cache.cxx:
/usr/lib/cmplrs/cxx/gemc_cxx -g0 -O2 -thread_safe -Xirf./cxx_repository/zen.ilo.
dec.comaawbea -ptr./cxx_repository -ptsuf.cxx.CXX.C.cc.CC.cpp.c -I. -Xsd./ -o ca
che.o cache.cxx
0.08u 0.05s 0:00.4 33%
/usr/lib/cmplrs/cxx/cc -o libmcm.so -G 8 -shared -g0 /usr/lib/cmplrs/cxx/_main.o
mcm.o mcm_internal.o cache.o -v -lcxxstd -lcxx -lexc -cxxsyms
/usr/lib/cmplrs/cc/ld -o libmcm.so -cxxsyms -g0 -O1 -shared /usr/lib/cmplrs/cxx/
_main.o mcm.o mcm_internal.o cache.o -lcxxstd -lcxx -lexc -lc
/usr/lib/cmplrs/cxx/cc -o libmcm.so -G 8 -shared -g0 /usr/lib/cmplrs/cxx/_main.o
./cxx_repository/Cache_t__T14EpMcMapEntry_t.o ./cxx_repository/Cache_t__T15RxBu
fMapEntry_t.o ./cxx_repository/Cache_t__T15TxBufMapEntry_t.o mcm.o mcm_internal.
o cache.o -v -lcxxstd -lcxx -lexc -cxxsyms
/usr/lib/cmplrs/cc/ld -o libmcm.so -cxxsyms -g0 -O1 -shared /usr/lib/cmplrs/cxx/
_main.o ./cxx_repository/Cache_t__T14EpMcMapEntry_t.o ./cxx_repository/Cache_t__
T15RxBufMapEntry_t.o ./cxx_repository/Cache_t__T15TxBufMapEntry_t.o mcm.o mcm_in
ternal.o cache.o -lcxxstd -lcxx -lexc -lc
/usr/lib/cmplrs/cxx/cc -o libmcm.so -G 8 -shared -g0 /usr/lib/cmplrs/cxx/_main.o
./cxx_repository/Cache_t__T14EpMcMapEntry_t.o ./cxx_repository/Cache_t__T15RxBu
fMapEntry_t.o ./cxx_repository/Cache_t__T15TxBufMapEntry_t.o mcm.o mcm_internal.
o cache.o -v -lcxxstd -lcxx -lexc |& /usr/lib/cmplrs/cxx/demangle
/usr/lib/cmplrs/cc/ld -o libmcm.so -g0 -O1 -shared /usr/lib/cmplrs/cxx/_main.o .
/cxx_repository/Cache_t__T14EpMcMapEntry_t.o ./cxx_repository/Cache_t__T15RxBufM
apEntry_t.o ./cxx_repository/Cache_t__T15TxBufMapEntry_t.o mcm.o mcm_internal.o
cache.o -lcxxstd -lcxx -lexc -lc
/usr/lib/cmplrs/cc/ld:
0.06u 0.04s 0:00 23% 0+10k 7+12io 2pf+0w 10stk+1352mem
0.08u 0.08s 0:00.5 36%
|
3447.3 | | GALVIA::STONES | Tom Stones | Fri Feb 14 1997 08:08 | 4 |
| Could you explain what's going on with the multiple cc and ld calls?
Ta,
Tom.
|
3447.4 | | DECCXL::OUELLETTE | | Wed Feb 19 1997 17:06 | 18 |
| > Could you explain what's going on with the multiple cc and ld calls?
Very approximately:
The way that cc automatically instantiates template classes and template
functions is via trial and error. The first pass compiles all of the
objects and then tries to link them. Unresolved references are then
collected and examined to find as yet uninstantiated template things.
Creating objects with the missing template things accounts for the extra
compiles. The reason why you may have more than two link trials is that
newly instantiated templates may need more templates (transitive closure).
The compiler uses the repository to avoid excessive compiles and links
in subsequent builds.
I don't think we want to document this in any more detail, since we're
considering changes to optimize the process in later compiler versions.
Roland.
|