[csw-maintainers] assembler in shared libraries

[Peter FELECAN]

Mike Watters <mwatters at opencsw.org> writes:

> Joerg Schilling wrote:
>> Philip Brown <phil at bolthole.com> wrote:
>> 
>>> a WELL-BEHAVED set of Makefiles, will allow you to override linker by
>>> simply specifying
>>>
>>> LD=/path/to/ld
>> 
>> Well, if the "new" LD behaves significantly similar to the expected LD,
>> you are correct.
>> 
>> For simple makefiles you may be correct too......
>> 
>> For more complex makefiles you are not correct as these makefiles may
>> have more internal knowledge than you may expect.
>> 
>> Jörg
>> 
>
> It is all up to the writer of the Makefile, Makefiles can force whatever the
> creator  wants it to force by default.  we always have the option of changing
> it. either with a patch to Makefile.in or autoconf.   however, if the package
> uses libtool, the LD environment variable should be honored.

The projects that I try to port/package use some autotools but not
libtool --- which I can understand.

Using the an environment variable LD implies the knowledge by the
subsequent tools of this mechanism; it's true for libtool but not for the
gcc driver.

Here is some additional information:

- the linking is done through the gcc driver, with classic argument
  passing by -Wl

- originally, the linker arguments are from the super-set of the GNU
  -linker, e.g., soname, --version-script, &c

- when asking to show the invoked sub-processes:

       /opt/csw/gcc4/bin/gcc -v -B /opt/csw/gnu t.c -o t

  we obtain, for the link phase:

     COLLECT_GCC_OPTIONS='-v' '-B' '/opt/csw/gnu' '-o' 't' '-mtune=generic'
     /usr/ccs/bin/ld -V ...
     ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490

  which is not what we expect when using -B

- note that when using gcc3 there is a subtle difference:

    /opt/csw/gcc3/bin/gcc -v -B /opt/csw/gnu t.c -o t
    ...
    /opt/csw/gcc3/libexec/gcc/i386-pc-solaris2.8/3.4.5/collect2 -V ...
    ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490

  the linker is called by collect2; here I'm a little bit confused as
  this is the first time that I see a gcc shipped without the collect2
  binary. But this is another issue which is probably not related.

- exploring the compiler driver search paths:

    gcc -print-search-dirs | grep '^programs:'
    programs: =/opt/csw/gcc3/libexec/gcc/i386-pc-solaris2.8/3.4.5/:...:/usr/ccs/bin/

  but

    gcc -B /opt/csw/gnu -print-search-dirs | grep '^programs:'
    programs: =/opt/csw/gnu/i386-pc-solaris2.8/3.4.5/:/opt/csw/gnu/:...:/usr/ccs/bin/

  shows that this has no effect even though the path is modified as expected.

- trussing the driver:

    truss -e -f -o gcc.truss gcc -v -B /opt/csw/gnu t.c -o t

  shows that there is no tentative to search for a linker binary in
  /opt/csw/gnu

  There is a remark in the GCC FAQ: http://gcc.gnu.org/faq.html#gas
  about using --with-ld when configuring the compiler: "One drawback of
  this option is that it won't allow you to override the search path for
  assembler and linker with command-line options -B/path/ if the
  specified file names exist." My experiments show that this is also true
  when trying to use the environment variable GCC_EXEC_PREFIX

-- 
Peter