public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* not instantiating runtime_error objects?
@ 1998-08-12 6:59 Christoph Moar
1998-08-20 22:52 ` Martin von Loewis
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Moar @ 1998-08-12 6:59 UTC (permalink / raw)
To: egcs-bugs
Hello all,
I have a rather large application running on different systems,
one of them is a red hat linux 2.032 /w
Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.53/specs
gcc version egcs-2.91.53 19980803 (gcc2 ss-980609 experimental)
Now, this application runs fine, also on other compilers on
other machines.
I am now porting it on a solaris machine,
SunOS olymp 5.5 Generic sun4m sparc SUNW,SPARCstation-20
Reading specs from
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.53/specs
gcc version egcs-2.91.53 19980803 (gcc2 ss-980609 experimental)
as you can see, using the very same compiler.
The bug I am experiencing happens at link time:
my application uses different user exceptions, defined
as follows:
class data_sink_error : public runtime_error {
public:
data_sink_error (const string& what_string)
: runtime_error(what_string) {}
};
When linking on the sunos machine, I get an unresolved
external:
g++ -g -I. -D__SUNOS__ -D__sunos__ -D__OSVERSION__=5 -D__EXTENSIONS__
-D_PTHREADS -DTARGET_IPPUMP -DTARGET_IPRECV -DRTSPPUMP
-I/sw/local_o/egcs/include -I/usr/local/include
-I/home/moar/omniORB_2.5.0/include {whole bunch of objects} -o ippump
-L./ -L/sw/local_o/egcs/lib -L/home/moar/omniORB_2.5.0/lib/sun4_sosV_5.5
-lomnithread -lpthread -lnsl -lsocket -lposix4
Undefined first referenced
symbol in file
runtime_error::runtime_error(basic_string<char, string_char_traits<char>,
__default_alloc_template<1, 0> > const &)TcpIpSinkThread.o
ld: fatal: Symbol referencing errors. No output written to ippump
collect2: ld returned 1 exit status
make: *** [ippump] Error 1
Now, I was trying to reduce everything to a small example
doing the same constructs, but the small example always
works. I do a nm on the object file, c++filt on it,
see that there is no such function in the object file, but
when I link it using g++, the corresponding function
seems to get generated. Am I correct on this?
So I am rather puzzled here, as to where to start to look.
Any hints?
Christoph.
--
Christoph Moar (christoph.moar@mchp.siemens.de) Tel. (++49) 89 636-44628
SIEMENS AG Corporate Technology Fax. (++49) 89 636-47457
Information and Media Technology
Office Adress: SIEMENS AG ZT IK 1, Otto-Hahn-Ring 6, D-81739 Munich
Postal Adress: SIEMENS AG ZT IK 1, D-81730 Munich
pgpkey http://pgp5.ai.mit.edu:11371/pks/lookup?op=index&search=0xae81b9cc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: not instantiating runtime_error objects?
1998-08-12 6:59 not instantiating runtime_error objects? Christoph Moar
@ 1998-08-20 22:52 ` Martin von Loewis
1998-08-21 3:05 ` Christoph Moar
0 siblings, 1 reply; 4+ messages in thread
From: Martin von Loewis @ 1998-08-20 22:52 UTC (permalink / raw)
To: christoph.moar; +Cc: egcs-bugs
> runtime_error::runtime_error(basic_string<char, string_char_traits<char>,
> __default_alloc_template<1, 0> > const &)TcpIpSinkThread.o
[...]
> Any hints?
This constructor should be defined in
/usr/local/lib/libstdc++.a. Please do nm(1) on this to see if it is
really there. If so, there is a good chance that the linker is
picking up a different copy of libstdc++. If you have multiple
compilers installed, make sure the (a) g++ header files and (b)
library files are not mixed.
In order to find out what library is used, invoke g++ with -v. Copy
the linker line, and add --verbose.
Hope this helps,
Martin
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: not instantiating runtime_error objects?
1998-08-20 22:52 ` Martin von Loewis
@ 1998-08-21 3:05 ` Christoph Moar
1998-08-21 11:04 ` Martin von Loewis
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Moar @ 1998-08-21 3:05 UTC (permalink / raw)
To: Martin von Loewis; +Cc: egcs-bugs
At 07:49 21.08.98 +0200, you wrote:
>> runtime_error::runtime_error(basic_string<char, string_char_traits<char>,
>> __default_alloc_template<1, 0> > const &)TcpIpSinkThread.o
>This constructor should be defined in
>/usr/local/lib/libstdc++.a. Please do nm(1) on this to see if it is
>really there.
ok, what I have there (/sw/local_o/egcs/lib) is:
runtime_error::runtime_error(basic_string<char, string_char_traits<char>,
__default_alloc_template<0, 0> > const &)
if I check the same egcs snapshot under linux (rh5.0), I find (correctly)
runtime_error::runtime_error(basic_string<char, string_char_traits<char>,
__default_alloc_template<1, 0> > const &)
so the __default_alloc_template<0, 0> becomes <1, 0> on solaris
platform. I suppose that's it, isn't it?
>If so, there is a good chance that the linker is
>picking up a different copy of libstdc++. If you have multiple
>compilers installed, make sure the (a) g++ header files and (b)
>library files are not mixed.
Yup, I did that. I checked with the --verbose flag, and here it is
[89]olymp/home/moar/SmartPump >make
*** target set to generate code on platform SunOS -DTARGET_IPPUMP
-DTARGET_IPRECV -DRTSPPUMP
g++ -g -v -I. -D__SUNOS__ -D__sunos__ -D__sparc__ -D__OSVERSION__=5 -DSVR4
-DUserPthread -D_REENTRANT -D__EXTENSIONS__ -D_PTHREADS -DTARGET_IPPUMP
-DTARGET_IPRECV -DRTSPPUMP -I/sw/local_o/egcs/include
-I/home/moar/omniORB_2.5.0/include I{...objects...}
-o ippump -L./ -L/sw/local_o/egcs/lib
-L/home/moar/omniORB_2.5.0/lib/sun4_sosV_5.5 -lomnithread -lpthread -lnsl
-lsocket -lposix4 --verbose
Reading specs from
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54/specs
gcc version egcs-2.91.54 19980816 (gcc2 ss-980609 experimental)
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54/collect2 -V
-Y P,/usr/ccs/lib:/usr/lib -Qy -o ippump
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54/crt1.o
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54/crti.o
/usr/ccs/lib/values-Xa.o
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54/crtbegin.o
-L./ -L/sw/local_o/egcs/lib -L/home/moar/omniORB_2.5.0/lib/sun4_sosV_5.5
-L/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54
-L/sw/local_o/egcs/sparc-sun-solaris2.5/lib -L/usr/ccs/bin -L/usr/ccs/lib
-L/sw/local_o/egcs/lib {...objects...} -lomnithread -lpthread -lnsl
-lsocket -lposix4 -lstdc++ -lm -lgcc -lc -lgcc
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54/crtend.o
/sw/local_o/egcs/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.54/crtn.o
ld: Software Generation Utilities (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning)
Undefined first referenced
symbol in file
runtime_error::runtime_error(basic_string<char, string_char_traits<char>,
__default_alloc_template<1, 0> > const &)TcpIpSinkThread.o
ld: fatal: Symbol referencing errors. No output written to ippump
collect2: ld returned 1 exit status
make: *** [ippump] Error 1
--
I'd volunteer to check the compiler, but I am afraid I would never
know where to look there ... ;)
Any hints? I'll happily help out finding out, if I can.
Best regards,
Christoph Moar.
--
Christoph Moar (christoph.moar@mchp.siemens.de) Tel. (++49) 89 636-44628
SIEMENS AG Corporate Technology Fax. (++49) 89 636-47457
Information and Media Technology
Office Adress: SIEMENS AG ZT IK 1, Otto-Hahn-Ring 6, D-81739 Munich
Postal Adress: SIEMENS AG ZT IK 1, D-81730 Munich
pgpkey http://pgp5.ai.mit.edu:11371/pks/lookup?op=index&search=0xae81b9cc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: not instantiating runtime_error objects?
1998-08-21 3:05 ` Christoph Moar
@ 1998-08-21 11:04 ` Martin von Loewis
0 siblings, 0 replies; 4+ messages in thread
From: Martin von Loewis @ 1998-08-21 11:04 UTC (permalink / raw)
To: christoph.moar; +Cc: egcs-bugs
> so the __default_alloc_template<0, 0> becomes <1, 0> on solaris
> platform. I suppose that's it, isn't it?
Most likely. Please note that the first parameter determines whether
the allocator is thread-aware or not. It seems that your library was
installed without thread support, but now you compile with threads
enabled.
> Yup, I did that. I checked with the --verbose flag, and here it is
This looks OK. You either need to drop -D_PTHREADS from your
compilation, or build libstdc++ with -D_PTHREADS. I'm not sure how to
achieve the latter.
Hope this helps,
Martin
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1998-08-21 11:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-12 6:59 not instantiating runtime_error objects? Christoph Moar
1998-08-20 22:52 ` Martin von Loewis
1998-08-21 3:05 ` Christoph Moar
1998-08-21 11:04 ` Martin von Loewis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).