| Summary: | Can't link on Tru64: argument list too long | ||
|---|---|---|---|
| Product: | cairo | Reporter: | M Joonas Pihlaja <jpihlaja> |
| Component: | general | Assignee: | Carl Worth <cworth> |
| Status: | RESOLVED MOVED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | freedesktop, pogma |
| Version: | 1.8.0 | ||
| Hardware: | Alpha | ||
| OS: | other | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Failing make command. | ||
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...) 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 What I meant was: "Can anyone tell me why libtool is doing what it's doing?"! (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. 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? (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). Mind reporting this to bug-libtool-at-gnu-org? Feel free to CC me. -- 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.
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.