[PATCH] Problem with native IRIX ld

[Morten Eriksen]

Hi,

I've bumped into a rather nasty problem with libtool's "cooperation"
with the native SGI IRIX linker.

Platform:
        * SGI IRIX 6.5

        * SGI Mipspro CC v7.30

        * native ld, $Id$ = IRIX 6.4:1275524910 built 04/21/99
          (couldn't find a way to make it spit out the version or
          release number)

        * Libtool v1.3.5


In a nutshell, the problem is that the -set_version option of the
native IRIX linker can't handle optionstrings of more than ~230
characters before it segfaults.

The long version of the problem is that libtool uses IRIX ld's
-set_version to set up the list of interface versions which the
library you're building is meant to be backwards compatible
with. Here's the relevant code from ltmain.sh:

        irix)
          major=`expr $current - $age + 1`
          versuffix="$major.$revision"
          verstring="sgi$major.$revision"

          # Add in all the interfaces that we are compatible with.
          loop=$revision
          while test $loop != 0; do
            iface=`expr $revision - $loop`
            loop=`expr $loop - 1`
            verstring="sgi$major.$iface:$verstring"
          done
          ;;


(So if our current major version number is 1 (and age 0), and our
revision is 5, the library will be named libxxx.so.2.5 and the
interface compatibility $verstring will become
"sgi2.4:sgi2.3:sgi2.2:sgi2.1:sgi2.0:sgi2.5".)

The $verstring is then passed to ld's -set_version option in the
generated libtool script, here's the command:

      archive_cmds='$LD -shared $libobjs $deplibs $linkopts -soname $soname 
`test -n "$verstring" && echo -set_version $verstring` -update_registry 
${objdir}/so_locations -o $lib'

Now, if the $revision number is large, $verstring can quickly get
rather long. IRIX ld will crash if it consists of more than ~230
characters, and each extra interface to be listed consists of minimum
7 characters (in the form "sgi1.0:sgi1.1:...").

I.e., you can't have more than about 25 revisions of a library, and
that is only if you increment the revision number by 1 each time you
do a new release. This is obviously not good enough.


That's the problem, now for my proposed solution:

The thing is that I can't see why we need to pass -set_version at all,
as the default behavior for IRIX ld is to keep compatibility only over
major version numbers -- i.e. the minor number defaults to being
ignored by the runtime linker if the library was created without the
-set_version option.

So unless I've overlooked something crucial, I propose the attached
patch as a workaround for the IRIX ld problem. Changelog entry as
follows (I'm not sure in which format you want patches against release
tarballs, I guess you'd perhaps want to ignore the changes to the
autogenerated files):

2000-10-26  Morten Eriksen  <address@hidden>
        
        * ltconfig.in (irix*): Remove unnecessary use of the buggy
        -set_version option to IRIX ld (the linker segfaults for
        strings longer than ~230 characters).
        * ltconfig (irix*): Likewise.
        * ltmain.in (irix*): No need to build the $verstring variable
        anymore.
        * ltmain.sh (irix*): Likewise.

BTW, AFAICS the CVS HEAD-branch also has the same problem.

(I Cc:'ed the discussion mailinglist as I'm not 100% sure this is the
correct solution.)

Regards,
Morten Eriksen

irixld.diff
Description: Text document