Repost: OSR 5.0.5 strange linker problem.. (nobody?)

[Robert Lipe]

> [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