ranlib and its ar s subsitute
Chip Collier
I searched through google for a while and found out that ranlib isn't
requried on an SGI system. I'm tyring to build the OpenPTC-X11 library
v1.0.0 and I've been tweaking stuff all day getting it further and further
along. I have a question though about ranlib's influence on libraries and
stuff.
In the makefile that calls ranlib:
it calls 'ar rcv $(PTC_FULL_LIB) $(OFILES)'
then calls 'ranlib $(PTC_FULL_LIB)'
What is supposed to be happening there? Just messing around I placed 'ar sr'
in place of ranlib and everything went fine except that the library just
didn't work when I tried to link with it. I then placed 'true' in place of
'ar sr' and it got through everything fine until it hit some compiler errors
in Pallette.cc where it couldn't convert a parameter from "const unsigned
int*" to "int32*". Why wouldn't this error occur before when I substituted
'ar sr' for ranlib?
The error shouldn't be such a big deal to fix but I wonder if I even need
to.
By the way, there was no logic to using 'ar sr' there I just saw a post that
said I should use 'ar s' instead of ranlib but in order to use 'ar s' I have
to specify another argument...and I haven't the slightest idea what's
appropriate there because I'm not sure what the authors had intended.
Thanks,
Chip Collier
gcol...@nospam.rsad.edu
Walter Roberson
Chip Collier <gcol...@rsad.edu.spam-filter> wrote:
:I searched through google for a while and found out that ranlib isn't
:requried on an SGI system. I'm tyring to build the OpenPTC-X11 library
:v1.0.0 and I've been tweaking stuff all day getting it further and further
:along. I have a question though about ranlib's influence on libraries and
:stuff.
:In the makefile that calls ranlib:
:it calls 'ar rcv $(PTC_FULL_LIB) $(OFILES)'
:then calls 'ranlib $(PTC_FULL_LIB)'
:What is supposed to be happening there?
Historically, ar (on systems that needed ar) did not automatically
create the final index, as an optimization (because you might go on to
add further objects to the archive.) ranlib then added the index.
:Just messing around I placed 'ar sr'
:in place of ranlib and everything went fine except that the library just
:didn't work when I tried to link with it.
See below.
:I then placed 'true' in place of
:'ar sr' and it got through everything fine until it hit some compiler errors
:in Pallette.cc where it couldn't convert a parameter from "const unsigned
:int*" to "int32*". Why wouldn't this error occur before when I substituted
:'ar sr' for ranlib?
I'm not exactly sure, but see below.
:The error shouldn't be such a big deal to fix but I wonder if I even need
:to.
:By the way, there was no logic to using 'ar sr' there I just saw a post that
:said I should use 'ar s' instead of ranlib but in order to use 'ar s' I have
:to specify another argument...and I haven't the slightest idea what's
:appropriate there because I'm not sure what the authors had intended.
The gnu ranlib man page indicates that gnu ranlib is the same as 'ar -s'.
Anyhow, your filename 'Pallette.cc' implies that you are using C++.
C++ archives need special handling because of templates. If you really
want to create a C++ archive (instead of a shared library), then you
should use CC -ar -- see the CC man page. My guess, though, is that
a shared library is likely to be better for your purposes; see the 'dso'
man page for more information.