[comp.sys.sun] Question on /lib/compile

kendall%saber%harvard@husc6.harvard.edu (Samuel C. Kendall) (03/04/89)

My Sun-4 runs 4.0, but has the Sys4-3.2 filesystems mounted under
/root3.2.  I've nearly got a "cc3.2" command working on 4.0 that makes
Sys4-3.2 binaries.  It's very simple; it just invokes
/root3.2/lib/compile, making sure its argv[0] ends in "cc", and passes in
the right -Qpath, -I, and -L options.

It almost works.  The problem is in linking.  /root3.2/lib/compile invokes
the right ld (/root3.2/pub/bin/ld), but passes it two options "-dc -dp"
that are understood only by the 4.0 ld (it should pass just "-d" instead).

My question, then, is how does /lib/compile know what arguments to pass to
ld?  The arguments are not "hardwired" into the binary, because the same
"compile" binary invokes ld differently depending on which OS is running,
and what paths must be used to get to certain files.  But I haven't been
able to find the template file that drives it, if there is one.

I can fix this by invoking /root3.2/pub/bin/ld myself, but it would be
easier to let "compile" do it.

My script "cc3.2" is as follows:

#! /bin/sh
exec /usr/local/lib/cc3.2/cc -Qpath /root3.2/pub/lib -Qpath /root3.2/pub/bin \
        -Qpath /root3.2/usr/lib -I/root3.2/usr/include -L/root3.2/pub/lib \
        -L/root3.2/usr/lib -L/root3.2/usr/local/lib $*

"/usr/local/lib/cc3.2/cc" is a link to "/root3.2/lib/compile"; it exists
so that "compile" can be invoked with an argv[0] that ends in "cc".

----
Sam Kendall 
Saber Software, Inc.
kendall%saber@harvard.edu
(617) 876-7636

jackson@csc-ws-srv.umd.edu (03/17/89)

>It almost works.  The problem is in linking.  /root3.2/lib/compile invokes
>the right ld (/root3.2/pub/bin/ld), but passes it two options "-dc -dp"
>that are understood only by the 4.0 ld (it should pass just "-d" instead).

>My question, then, is how does /lib/compile know what arguments to pass to
>ld?  The arguments are not "hardwired" into the binary, because the same

This is tricky.  What happens is that compile tries to find some file (I'm
thinking crt0.o, but I don't remember for sure) in both /usr/lib and /lib.
If it finds it in /usr/lib, it thinks you're on a 4.0 system and uses 4.0
ld arguments.  If it's in /lib, it thinks you're on 3.2 and uses 3.2 ld
arguments.  (Evidently, the 3.2 compile is really the 4.0 compile with
hooks for backwards compatiblity.)  I found this by use of the trace(1)
command, and fixed the problem by changing the offending file name in the
3.2 compile binary using adb.  (Change it to something like
"/zzz/lib/whatever"; it won't be found, and compile will use 3.2-style
argments for ld.)

Chris Jackson               University of Maryland Computer Science Department
                            (no, I don't work here, I'm just a student...)