HP/Compaq Tru64 linker semantics

HP/Compaq Tru64 linker semantics

[Karl Vogel]

Since GNU as and GNU ld don't work on a Tru64 system, the system provided
linker is used. This linker differs in the way it looks for shared/archive
libraries.

From the ld [1] man page:

  When linking a shared object, ld searches all library directories for the
  shared object library (libx.so). If it cannot find the shared object
  library, it again searches all library directories for the archive library
  (libx.a).


It can be told to look for both the shared and the archive library in a
directory, before skipping to the next directory path:

  -oldstyle_liblookup
      Cause ld to search each library directory, first for the shared object
      library (libx.so) and then for the archive library (libx.a).

Which is the way GNU ld works.


For reference, I ran into this problem trying to use a newer (archive)
library than the (shared) library installed on the base system. (Berkeley DB
4.2.x package of http://www.openpkg.org)
I used the following patch on my system to get it in line with GNU ld:

--- gcc/config/alpha/osf.h.orig 2004-04-26 15:10:02 +0200
+++ gcc/config/alpha/osf.h      2004-04-26 15:10:18 +0200
@@ -79,7 +79,7 @@
    constructor and call-frame data structures are not accidentally
    overridden.  */
 #define LINK_SPEC  \
-  "-G 8 %{O*:-O3} %{!O*:-O1} -S %{static:-non_shared} \
+  "-oldstyle_liblookup -G 8 %{O*:-O3} %{!O*:-O1} -S %{static:-non_shared} \
    %{!static:%{shared:-shared -hidden_symbol _GLOBAL_*} \
    %{!shared:-call_shared}} %{pg} %{taso} %{rpath*}"



I was wondering what the general opinion is.. follow GNU ld as close as
possible? Or follow the standard way of the platform?!




[1]
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50_HTML/MAN/MAN1/0241
____.HTM

Re: HP/Compaq Tru64 linker semantics

[Jim Wilson]

Karl Vogel wrote:
> I was wondering what the general opinion is.. follow GNU ld as close as
> possible? Or follow the standard way of the platform?!

I would suggest that we should follow what the platform does.  People 
porting to Tru64 will expect gcc to work the same way as the native 
compiler, and if it doesn't, then packages with builtin Tru64 
assumptions may fail.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: HP/Compaq Tru64 linker semantics

[Rainer Orth]

Jim Wilson <wilson@specifixinc.com> writes:

> Karl Vogel wrote:
> > I was wondering what the general opinion is.. follow GNU ld as close as
> > possible? Or follow the standard way of the platform?!
> 
> I would suggest that we should follow what the platform does.  People 
> porting to Tru64 will expect gcc to work the same way as the native 
> compiler, and if it doesn't, then packages with builtin Tru64 
> assumptions may fail.

Fully agreed, even though this case of local vs. vendor supplied libdb has
bitten me as well.  Even though this default (searching for all shared
libraries before the static ones) is highly unusual on Unix systems, we
should follow the vendor here so GCC users don't get another surprise when
using GCC.

One caveat, though: currently one cannot pass -oldstyle_liblookup through
collect2 to ld, which is quite tedious.  This has been reported already

	http://gcc.gnu.org/ml/gcc-bugs/1999-09n/msg00912.html
	
and there's a PR for this, other/1963, but it is unfixed an has been
(erroneously, I think) been closed as a duplicate of PR other/5762.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Re: HP/Compaq Tru64 linker semantics

[Andrew Pinski]

On Apr 28, 2004, at 16:37, Rainer Orth wrote:

> Jim Wilson <wilson@specifixinc.com> writes:
>
>> Karl Vogel wrote:
>>> I was wondering what the general opinion is.. follow GNU ld as close 
>>> as
>>> possible? Or follow the standard way of the platform?!
>>
>> I would suggest that we should follow what the platform does.  People
>> porting to Tru64 will expect gcc to work the same way as the native
>> compiler, and if it doesn't, then packages with builtin Tru64
>> assumptions may fail.
>
> Fully agreed, even though this case of local vs. vendor supplied libdb 
> has
> bitten me as well.  Even though this default (searching for all shared
> libraries before the static ones) is highly unusual on Unix systems, we
> should follow the vendor here so GCC users don't get another surprise 
> when
> using GCC.

I should note that this is the same as Darwin's linker acts and there 
is no way to
change it for that target.

Thanks,
Andrew Pinski

Re: HP/Compaq Tru64 linker semantics

[Rainer Orth]

Andrew Pinski writes:

> I should note that this is the same as Darwin's linker acts and there 
> is no way to
> change it for that target.

I vaguely remembered having read that, but didn't want to claim it without
first-hand experience with that target.

	Rainer

Re: HP/Compaq Tru64 linker semantics

[Jim Wilson]

On Wed, 2004-04-28 at 13:37, Rainer Orth wrote:
> One caveat, though: currently one cannot pass -oldstyle_liblookup through
> collect2 to ld, which is quite tedious.  This has been reported already

This is because of confusion between "-o output" and
"-oldstyle_liblookup"  This should be fixable by defining
SWITCHES_NEED_SPACES to include "o".  This changes both gcc.c and
collect2.c, and they will no longer accept "-ooutput" as valid, which
should let the Tru64 linker option work.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: HP/Compaq Tru64 linker semantics

[Rainer Orth]

Jim Wilson writes:

> This is because of confusion between "-o output" and
> "-oldstyle_liblookup"  This should be fixable by defining
> SWITCHES_NEED_SPACES to include "o".  This changes both gcc.c and
> collect2.c, and they will no longer accept "-ooutput" as valid, which
> should let the Tru64 linker option work.

True, this is even mentioned in the PR.  I've just checked that this is
true: ld doesn't understand -otest (instead of -o test).  I once had a
hacky patch to let collect2 pass through certain flags (like
-oldstyle_liblookup) unprocessed, but this is much cleaner.

I'll prepare a patch.

Thanks.
	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Re: HP/Compaq Tru64 linker semantics

[Karl Vogel]

Rainer Orth wrote:

>Jim Wilson writes:
>
>  
>
>>This is because of confusion between "-o output" and
>>"-oldstyle_liblookup"  This should be fixable by defining
>>SWITCHES_NEED_SPACES to include "o".  This changes both gcc.c and
>>collect2.c, and they will no longer accept "-ooutput" as valid, which
>>should let the Tru64 linker option work.
>>    
>>
>
>True, this is even mentioned in the PR.  I've just checked that this is
>true: ld doesn't understand -otest (instead of -o test).  I once had a
>hacky patch to let collect2 pass through certain flags (like
>-oldstyle_liblookup) unprocessed, but this is much cleaner.
>
>I'll prepare a patch.
>
>  
>
I did something like:

+Index: gcc/config/alpha/osf.h
+--- gcc/config/alpha/osf.h.orig 2003-12-12 02:19:23.000000000 +0100
++++ gcc/config/alpha/osf.h      2004-04-26 21:25:14.000000000 +0200
+@@ -79,7 +79,7 @@
+    constructor and call-frame data structures are not accidentally
+    overridden.  */
+ #define LINK_SPEC  \
+-  "-G 8 %{O*:-O3} %{!O*:-O1} -S %{static:-non_shared} \
++  "-oldstyle_liblookup %{!o:-o a.out} -G 8 %{O*:-O3} %{!O*:-O1} -S %{static:-non_shared} \
+    %{!static:%{shared:-shared -hidden_symbol _GLOBAL_*} \
+    %{!shared:-call_shared}} %{pg} %{taso} %{rpath*}"
+ 



As I also bumped into the problem with the -o handling (ie. error when 
no -o is given on the gcc command line), but since I'm no GCC hacker, 
I'm not sure it's the best way :)

Karl.

Re: HP/Compaq Tru64 linker semantics

[Rainer Orth]

Karl Vogel writes:

> I did something like:
> 
> +Index: gcc/config/alpha/osf.h
> +--- gcc/config/alpha/osf.h.orig 2003-12-12 02:19:23.000000000 +0100
> ++++ gcc/config/alpha/osf.h      2004-04-26 21:25:14.000000000 +0200
> +@@ -79,7 +79,7 @@
> +    constructor and call-frame data structures are not accidentally
> +    overridden.  */
> + #define LINK_SPEC  \
> +-  "-G 8 %{O*:-O3} %{!O*:-O1} -S %{static:-non_shared} \
> ++  "-oldstyle_liblookup %{!o:-o a.out} -G 8 %{O*:-O3} %{!O*:-O1} -S %{static:-non_shared} \
> +    %{!static:%{shared:-shared -hidden_symbol _GLOBAL_*} \
> +    %{!shared:-call_shared}} %{pg} %{taso} %{rpath*}"
> + 

That's not what I meant: as already stated, I don't think it's appropriate
for gcc to behave differently than the native cc with respect to library
lookup, even if this behavior is unusual compared to other unices.

My patch to allow passing -oldstyle_liblookup through collect2 to ld (but
only as -Wl,-oldstyle_liblookup) is here:

	http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01920.html

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University