This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Repost: OSR 5.0.5 strange linker problem.. (nobody?)
- To: Rob Kramer <wrobbie at my-Deja dot com>
- Subject: Re: Repost: OSR 5.0.5 strange linker problem.. (nobody?)
- From: Robert Lipe <robertlipe at usa dot net>
- Date: Mon, 20 Mar 2000 11:47:21 -0600
- Cc: egcs at egcs dot cygnus dot com
- References: <HHPHDFBNENLJHCAA@my-deja.com>
> [Sorry, but I still haven't solved this.. Next repost I'd better mail to Robert Lipe directly :)]
Robert doesn't have clues about every possible problem that happens to
pop up on SCO. When you get into network code, shared libes, and C++,
you have an interesection of three weaknesses so I'm not often compelled
to even write a "dunno".
> - If I make 'test' like this, it says 'Port: 0', which is incorrect.
> - If I omit libdummy.so, or make libdummy.so a C-library by compiling
> with GCC instead of G++, or link with libdummy.a, then 'test' says
> 'Port: 8900', which is correct.
I changed your Makfefile to get rid of the absolute pathnames and to use
"echo" for serv instead of "SMRTTISCM_BOOT_REQ" which doesn't appear in
/etc/services on my system and see the following results:
g++ -c -Wall -Wno-parentheses dummy.cc
g++ -G -dy -h libdummy.so dummy.o -o libdummy.so
g++ -c -Wall -Wno-parentheses test.cc
g++ -Wall -Wno-parentheses -o test test.o libdummy.so -lsocket
(robertl) rjlhome:/tmp/rr
$ ./test
Port: 7
This is or isn't what you see?
> The libdummy is just to show that linking any C++ library will kill
> getservbyname(). I'm not entirely sure whether this is the correct
> way to build a shared libdummy, but the method seems to work fine for
> our 'real' libraries except for this problem. Building with '-shared'
> won't work for me, the linker complains about missing libm symbols in
> that case (don't have a libm.so)
The absence of -fPIC seems disturbing. I thought that dummy.cc in y our
example should be compiled as PIC, shouldn't it?
RJL