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).