root@libove.UUCP (Jay M. Libove) (10/06/88)
[ I know that this is a Sys5 _feature_ and not a bug, but it is of concern
to the Sys5 audience in general as well as the Xenix audience... ]
It seems that Xenix, and indeed Sys5 in general, are unwilling (in their
default "ar"chiver/library-manager) to store globals in a library as such:
--------------------
/* globaltest.c */
int argle;
void codefunc()
{
printf("Hello world\n");
};
--------------------
/* globaluse.c */
extern int argle;
void main()
{
argle=5;
printf("%d\n",argle);
};
--------------------
% cc -c globaltest.c
% rm -f archive.a
% ar q archive.a globaltest.o
% ranlib archive.a
% cc -c globeluse.c
% cc globaluse.o archive.a
Undefined external symbols:
argle in globaluse.o(globaluse.c)
This is rather annoying. It has been a problem for me in porting a
number of sources to my SCO Xenix machine (SCO Xenix 80286 version 2.2.1).
So, is this a compiler thing? Does the compiler strip out that global?
I don't think so - the compiler on my system (and probably on most) is
based on pcc. So, is it a /bin/ar thing? I would guess so. Thusly: Does
anyone have a public domain ar replacement?
Sigh. Any help muchly appreciated, net...
--
Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu
5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas
Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or
(412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libovegwyn@smoke.ARPA (Doug Gwyn ) (10/08/88)
In article <167@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: >[ I know that this is a Sys5 _feature_ and not a bug, but it is of concern > to the Sys5 audience in general as well as the Xenix audience... ] >It seems that Xenix, and indeed Sys5 in general, are unwilling (in their >default "ar"chiver/library-manager) to store globals in a library as such: To the contrary, UNIX System V does NOT have the bug you report. Your problem stems from some port of what is apparently an old (pre-System V) version of PCC and the Berkeley linker suite. The "int argle;" is supposed to generate a .data, not a .lcomm, and System V doesn't even have "ranlib". Complain to your compiler vendor.