[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH] Problem with native IRIX ld
From: |
Morten Eriksen |
Subject: |
[PATCH] Problem with native IRIX ld |
Date: |
26 Oct 2000 16:31:46 +0200 |
User-agent: |
Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.3 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [PATCH] Problem with native IRIX ld,
Morten Eriksen <=