[comp.unix.xenix.sco] Problems with Slibcfp.a

srodawa@vela.acs.oakland.edu (Ron Srodawa) (02/05/91)

I am trying to compile dvips for Xenix/386 using the gcc compiler.
I got errors out of ld in /lib/386/Slibcfp.a as follows:
Three symbols are defined more than once.  They are:
  _atof in (atof.c)
  _fltrd in (atof.c)
  __doprnt in (doprnt.c)
Anyone understand what is going on here and how to resolve the problem?
(Well, it could be gld..I don't know which gcc is using for sure.)
I assume the problem is with the archive, but who knows?  ar t looks
good.  Ron.
-- 
| Ronald J. Srodawa               | Internet: srodawa@unix.secs.oakland.edu |
| School of Engineering and CS    | UUCP:     srodawa@egrunix.UUCP          |
| Oakland University              | Voice:    (313) 370-2247                |
| Rochester, Michigan  48309-4401 |                                         |

alfred@pemcom.pem-stuttgart.de (Alfred Koebler) (02/21/91)

srodawa@vela.acs.oakland.edu (Ron Srodawa) writes:

>I am trying to compile dvips for Xenix/386 using the gcc compiler.
>I got errors out of ld in /lib/386/Slibcfp.a as follows:
>Three symbols are defined more than once.  They are:
>  _atof in (atof.c)
>  _fltrd in (atof.c)
>  __doprnt in (doprnt.c)

We had the same problem with double defined symbol __doprnt a half year ago.
It is caused by Slibc.a and Slibcfp.a
In both libraries is the __doprnt symbol defined.
It's source file is doprnt.c
Only in the source file for Slibcfp.a is the symbol __rlprint defined.
In our case the linker searched first for __doprnt. He used Slibc.a
Then he needs the symbol __rlprint and uses Slibcfp.a
In this moment the error of symbols defined more than once occurs.

I got this info with the system utility "nm". It shows the symbols of the
library.

To solve this problem, the linker had always to use Slibcfp.a

Therefore I wrote the following little C-programm:

extern _rlprint;
__emergency__()
{
  int i;
  i = __rlprint;
}

I compiled the programm with "cc -c emergency.c"

Then I always link the emergency.o file before all user files.


We haven't problems with symbols from atof.c
I think it would be the same problem.

Nice to hear from you	Alfred

--
					  	    koebler@PEM-Stuttgart.de
Alfred Koebler		                PEM Programmentwicklungsgesellschaft
Vaihinger Str.49, PostBox 810165		      fuer Microcomputer mbH
FRG 7000 Stuttgart 80		  voice: +49-711-713045  fax: +49-711-713047

sef@kithrup.COM (Sean Eric Fagan) (02/22/91)

In article <1108@pemcom.pem-stuttgart.de> alfred@pemcom.pem-stuttgart.de (Alfred Koebler) writes:
>To solve this problem, the linker had always to use Slibcfp.a

Well, that's not what the system C compiler does.  It spits out something
like

	Slibcfp.a Slibc.a

There is a symbol, uhm, uhm, __fltused, I think, which is defined as an
external if the code uses floating point.  Slibcfp.a has the various
routines that use floating point with __fltused defined.  (Note that
*printf* isn't defined until Slibc.a, and it declares __doprnt as an
external there.)

Aren't linkers *fun*?

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.