Porting C code and getting POSIX pthread errors 1

[SkiLift]

I am porting C code to Reliant Unix 5.45 and I ran into compile errors related to POSIX threads. It appears that I have an old version of Posix threads, because I fixed the compile error by changing the 2nd parameter of pthread_mutex_init from NULL to pthread_mutexattr_default:

pthread_mutex_init (pLock, NULL)

to:

pthread_mutex_init (pLock, pthread_mutexattr_default)

Now, when I link, I get many errors:
cc -Rmsg_wrap -Kthread,signed,PIC -DSINIX -DRELUNIX54 cbmaint.o -o cbmaint -L. -lvst -lcb63 -lm -lloc -lqutil -L. -lloc -lcb63 -lm -lqutil
ld: ./libloc.so: warning: attempted multiple inclusion of file
ld: ./libcb63.so: warning: attempted multiple inclusion of file
ld: ./libqutil.so: warning: attempted multiple inclusion of file
Undefined first referenced
symbol in file
__nr_creat /lib/libcma.so
__nr_pipe /lib/libcma.so
__nr_fcntl /lib/libcma.so
doscan_mutex /lib/libcma.so
__nr_poll /lib/libcma.so
sprint_mutex /lib/libcma.so
__nr_ioctl /lib/libcma.so
__nr_getpmsg /lib/libcma.so
_iob_mutex /lib/libcma.so
__nr_creat64 /lib/libcma.so
libc_mutex /lib/libcma.so
__nr_writev /lib/libcma.so
__nr_readv /lib/libcma.so
__nr_setitimer /lib/libcma.so
__nr_close /lib/libcma.so
__nr_sigismember /lib/libcma.so
set_pthread_symb /opt/CDS++/lib/pthr_dce_c.o
__ree_system /lib/libcma.so
rtld_mutex /lib/libcma.so
__nr_sigaction /lib/libcma.so
libc_r_init /opt/CDS++/lib/pthr_dce_c.o
__nr_write /lib/libcma.so
__nr_open64 /lib/libcma.so
__nr_read /lib/libcma.so
__nr_sigaddset /lib/libcma.so
__nr_sigprocmask /lib/libcma.so
fpalloc_mutex /lib/libcma.so
__ree_popen /lib/libcma.so
__nr_fork /lib/libcma.so
__nr_execve /lib/libcma.so
__nr_dup /lib/libcma.so
__nr_open /lib/libcma.so
malloc_mutex /lib/libcma.so
__nr_getmsg /lib/libcma.so
__nr_putpmsg /lib/libcma.so
__nr_putmsg /lib/libcma.so

Does anyone know why I'm getting these link errors? If I get the latest version of POSIX threads, will these errors go away? Where do I download POSIX thread libraries?

Thanks

 

[Salem]

Check your command line
[tt]cc -Rmsg_wrap -Kthread,signed,PIC -DSINIX -DRELUNIX54 cbmaint.o -o cbmaint -L. -lvst -lcb63 -lm -lloc -lqutil -L. -lloc -lcb63 -lm -lqutil[/tt]
You listed a bunch of things twice.

Note that the order in which you list libraries is also important. If something in liba depends on libb, you need to make sure liba appears before libb on the command line.

A lot of those symbols (eg. __nr_creat) look like original Unix system call functions, but with some prefix which is no doubt system specific.
I would normally expect the compiler to locate these symbols without any extra effort on your part.

First thing would be to fix the duplicate libraries, in case this is throwing everything else off.

> [tt]-Rmsg_wrap -Kthread,signed,PIC -DSINIX -DRELUNIX54[/tt]
I don't know what these flags mean to your compiler, but did you use them when you created cbmaint.o in a separate command?
Keeping your compiler options consistent between compilation and linking is also important.

--

 

[SkiLift]

Thanks for your help Salem,

I am able to compile and link now, but it does not run correctly. It does not core dump, it just does not output anything. To get it to compile and link, first I narrowed the problem by writing a new barebones main() in logtest.c.

cc -L/opt/thread/lib -lcma -I/opt/thread/include 
-DPORT_UNIXANSI -DRELUNIX54 log.c logtest.c -o logtest

I searched for the library where

__nr_creat

is located, which is the libc.so in /opt/thread/lib, hence the -L above. The libc.so it was using before did not have __nr_creat. The -lcma library is needed because that's where the thread functions are. (eg. pthread_mutex_lock)

I am going to debug the executable to find out why its not working, but I am fearfull that I am still not linking it correctly. Any more suggestions would be greatly appreciated. Thanks again.

 

[Salem]

It's a pretty safe bet that it linked OK if you didn't get any linker errors, and you're getting an executable.

There is one thing you need to watch out for, and that's making sure you link with thread-safe versions of whatever libraries you use.

The rest is pretty much as you now know - debugging it to find out what is wrong.

When you're porting code from one place to another, this usually means finding all the assumptions which the programmer made originally, such as say assuming that sizeof(int) == 4

--