Bug 18008 - Can't link on Tru64: argument list too long
Summary: Can't link on Tru64: argument list too long
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 1.8.0
Hardware: Alpha other
: medium normal
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-10 10:05 UTC by M Joonas Pihlaja
Modified: 2018-08-25 13:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Failing make command. (151.08 KB, text/plain)
2008-10-10 10:05 UTC, M Joonas Pihlaja
Details

Description M Joonas Pihlaja 2008-10-10 10:05:55 UTC
Created attachment 19574 [details]
Failing make command.

The final linking step when building on Tru64 Unix fails with the error message /usr/bin/ld: arg list too long.  The command line it's trying to run is about 150kb long and contains a very long list of sonameish numbers.  The failing command appears to be

test -n "10802.10800.0:2.0:3.0:4.0:5[...snip...]:10801.0:10802.0

I'm attaching the output of make for more context.
Comment 1 Chris Wilson 2008-10-10 12:21:46 UTC
So why is libtool doing this for Tru64? Is it merely a broken libtool version, or a broken shared library system on Tru64 that cairo must workaround? (Which would necessitate a new major so version...)
Comment 2 M Joonas Pihlaja 2008-10-10 13:32:50 UTC
I successfully built and installed from source all of the packages below (most of which use libtool) as dependencies of cairo without too much trouble so I'm guessing it's not a broken shared library system.

fontconfig-2.6.0
freetype-2.3.7
libpng-1.2.32
libxml2-2.7.2
pixman-0.12.0
pkg-config-0.23
zlib-1.2.3
Comment 3 Chris Wilson 2008-10-10 16:36:26 UTC
What I meant was: "Can anyone tell me why libtool is doing what it's doing?"!
Comment 4 Peter O'Gorman, The Written Word, Inc. 2009-12-28 14:21:12 UTC
(In reply to comment #3)
> What I meant was: "Can anyone tell me why libtool is doing what it's doing?"!

For cairo-1.6.4 CURRENT was 19, REVISION 5 and AGE 17, so libtool added

-set_version 19.17.5:2.0:3.0:4.0:5.0:6.0:7.0:8.0:9.0:10.0:11.0:12.0:13.0:14.0:15.0:16.0:17.0:18.0:19.0

to the link flags, thus ensuring that any application that used a previous libcairo.so.2 would continue to be compatible with the current one.

Now, with libcairo-1.8.8, libtool again attempts to ensure that applications that use a previous libcairo do not need to be rebuilt by adding all versions from $CURRENT - $AGE to $CURRENT to the -set_version compatibility list. Libtool does not know that there were no versions released between 19 and 10802.

See also:
http://www.mail-archive.com/libtool@gnu.org/msg06548.html

I can only suggest that cairo add an exception for *-osf* to make the version info 20:0:18 or something that will still give the same soname as cairo-1.6.4, but not lead to problems with command line length.
Comment 5 Chris Wilson 2009-12-29 01:31:10 UTC
Peter, thanks for the explanation of the behaviour. Adding the exception for Tru64 (and any others?) does sound like the only way to proceed. Joonas, care to whip up and test a patch?
Comment 6 Peter O'Gorman, The Written Word, Inc. 2009-12-29 10:54:42 UTC
(In reply to comment #5)
> Peter, thanks for the explanation of the behaviour. Adding the exception for
> Tru64 (and any others?)

Libtool does similar things for IRIX and NonStop UX but instead of adding all versions from $CURRENT - $AGE to $CURRENT, they just use the sonum (so 3 for libcairo.so.3) and add compatibility versions from 0 to $REVISION, so this could be a problem if $REVISION were very large.

For example cairo-1.6.4 on IRIX has:
                      SONAME: libcairo.so.3
               MIPS_IVERSION: sgi3.4:sgi3.3:sgi3.2:sgi3.1:sgi3.0:sgi3.5

It is not currently a problem for cairo on these systems, only Tru64.

Unfortunately it is difficult for Libtool to change the versioning scheme for these systems without breaking binary compatibility for all libtool using libraries.

Cairo, however can change the versioning scheme just for *-osf*, as it is impossible for anyone to build cairo-1.8.x on these systems with the current version-info (so it's not really breaking binary compat).

Comment 7 Behdad Esfahbod 2010-01-06 16:46:21 UTC
Mind reporting this to bug-libtool-at-gnu-org?  Feel free to CC me.
Comment 8 GitLab Migration User 2018-08-25 13:29:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/30.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.