Subject: Re: Problems with 2006Q3
To: None <pkgsrc-users@netbsd.org>
From: Hrvoje =?utf-8?q?Habjani=C4=87?= <hrvoje.habjanic@zg.t-com.hr>
List: pkgsrc-users
Date: 11/11/2006 10:45:28
Hi again!

I finally managed to produce fairly stable enviroment for pkgsrc on my Tru64. 
It seems that OS ld command "is root of all evil" and is broken beyond any 
repair. I encountered the following oddities:

1. order of searching for libraries. From 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).
"
With this algorithm .so library later in -L dir will have higher priority 
than .a library in directory before one where .so is (for example, glu ld 
searches in each directory first for .so, then .a, then moves to next dir).

2. order of resolving unresolved object references

It seems that Tru64 ld make only one pass through library list when searching 
for dependency in .a libraries. For example, when building groff (!), one of 
utilities is linked against -lSM and -lICE. And because x11-link package 
makes links for .a libs of those, they get linked in because they are 
before .so parts. When linking, libraries are specified 
as: -lSM -lICE  -lXaw -lXt -lX11.

Object in question requires something from Xaw. BUT Xaw requires something 
from SM and ICE. It seems that ld is unable to resolve this "secondary" 
dependencies, and it stops with unresolved.

3. rpath handling

Tru64 ld accepts ONLY last rpath OR LD_RUN_PATH enviroment. There is no 
concatenating or merging. Only "or".

Solution

I tried to build gnu ld, but alas - it isn't supported on Tru64. So, i'm stuck 
with this crazy ld ...

Anyhow, solutions for each of problems:
1. Adding -oldstyle_liblookup will fix this
2. Altering order of libraries fix this one
3. Only solution was to build a wrapper script. But, because gcc ads its 
own -rpath to command line, i was forced to make wrapper script 
for "collect2" command from gcc (collect2 is unable to merge more rpath in 
one, or i don't know how to do it). Nasty, but it works.

With this i managed to compile joe, mc, tcpdump, vim, screen and few more. Of 
course, with small patches, mostly because last time someone tried this was 
for osf4, and i'm doing it on osf5.1.

In separate mail i'll send patches ...

H.