| Summary: | libXaw is created with incorrect version numbers on IRIX | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Stuart Shelton <srcshelton> |
| Component: | Lib/Xaw | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED WONTFIX | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | blocker | ||
| Priority: | high | CC: | srcshelton |
| Version: | unspecified | ||
| Hardware: | SGI | ||
| OS: | IRIX | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Hi guys, I realise that IRIX is, to say the least, a minority platform - but surely this bug indicates a pretty significant flaw in the build system? In any case, the workaround required (manually hex-editing the libXaw DSO binaries and changing the .la files) is manual, error-prone, and horribly hacky. Additionally, libXaw seems to be the only Xorg component affected. Since this is hugely problematic for building a significant number of X applications on IRIX, please could this be looked at as a matter of urgency? (If an IRIX machine to test on is unavailable then please let me know - I can arrange this if required) Many thanks, Stuart (In reply to comment #1) > I realise that IRIX is, to say the least, a minority platform - but surely this > bug indicates a pretty significant flaw in the build system? More likely just a bug in libXaw's special hacks for building it's multiple ABI versions. The combination of only affecting a platform few have access to in a library no one actively maintains makes it unlikely to be fixed quickly.
Since the problem seems to be an off-by-one issue, I was led to the following solution:
--- ltmain.sh.dist
+++ ltmain.sh
@@ -6311,11 +6311,11 @@ func_mode_link ()
;;
irix | nonstopux)
- if test "X$lt_irix_increment" = "Xno"; then
+ #if test "X$lt_irix_increment" = "Xno"; then
func_arith $current - $age
- else
- func_arith $current - $age + 1
- fi
+ #else
+ #func_arith $current - $age + 1
+ #fi
major=$func_arith_result
case $version_type in
... which appears to work. Presumably the 'lt_irix_increment' logic is there for a reason, though, so I'm not sure whether this might break any other part of the build.
So far, the new (and correctly numbered) library is working for me, though.
(In reply to comment #3) > Since the problem seems to be an off-by-one issue, I was led to the following > solution: > > --- ltmain.sh.dist > +++ ltmain.sh > @@ -6311,11 +6311,11 @@ func_mode_link () > ;; > > irix | nonstopux) > - if test "X$lt_irix_increment" = "Xno"; then > + #if test "X$lt_irix_increment" = "Xno"; then > func_arith $current - $age > - else > - func_arith $current - $age + 1 > - fi > + #else > + #func_arith $current - $age + 1 > + #fi > major=$func_arith_result > > case $version_type in > > ... which appears to work. Presumably the 'lt_irix_increment' logic is there > for a reason, though, so I'm not sure whether this might break any other part > of the build. > > So far, the new (and correctly numbered) library is working for me, though. Not an appropriate fix, since ltmain.sh is a generated file. See the section labeled "fix libtool to set SONAME to libXaw.so.$major" in configure.ac. You simply need to follow the example of win32 and darwin. The "fix" would be setting lt_irix_increment=no However implementing this fix would cause more problems than it would solve as the new files would be named correctly and conflict with the old ones, so everything that depends on libXaw would need to be rebuilt. This kind of binary compatibility headache is not worth making the version numbers more human friendly. Let's just suck it up and realize that IRIX will always be off-by-one here. Please reopen if you disagree, and provide a patch to set lt_irix_increment=no |
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.
After building libXaw-1.0.5 from unmodified source on IRIX with SGI's MIPSpro compiler suite (the most recent release, 7.4.4m), my src/.libs directory contains: -rw-r--r-- 1 stuart users 796K 2009-03-26 13:16 libXaw6.a lrwxr-xr-x 1 stuart users 13 2009-03-26 13:16 libXaw6.la -> ../libXaw6.la -rw-r--r-- 1 stuart users 1.3K 2009-03-26 13:16 libXaw6.lai lrwxr-xr-x 1 stuart users 14 2009-03-26 13:16 libXaw6.so -> libXaw6.so.7.1* lrwxr-xr-x 1 stuart users 14 2009-03-26 13:16 libXaw6.so.7 -> libXaw6.so.7.1* -rwxr-xr-x 1 stuart users 350K 2009-03-26 13:16 libXaw6.so.7.1* -rw-r--r-- 1 stuart users 1.1M 2009-03-26 13:20 libXaw7.a lrwxr-xr-x 1 stuart users 13 2009-03-26 13:20 libXaw7.la -> ../libXaw7.la -rw-r--r-- 1 stuart users 1.4K 2009-03-26 13:20 libXaw7.lai lrwxr-xr-x 1 stuart users 14 2009-03-26 13:20 libXaw7.so -> libXaw7.so.8.0* lrwxr-xr-x 1 stuart users 14 2009-03-26 13:20 libXaw7.so.8 -> libXaw7.so.8.0* -rwxr-xr-x 1 stuart users 505K 2009-03-26 13:20 libXaw7.so.8.0* -rw-r--r-- 1 stuart users 182 2009-03-26 13:20 so_locations ... where the actual shared objects should be named 'libXaw6.so.6.0.1' and 'libXaw7.so.7.0.0' libXaw-1.0.4 and libXaw-1.0.3 at least also suffer from the same problem. I'm not sure what information I can provide to help fix this problem (which I guess is somehow libtool-related?) but if there is anything then please ask. (To confirm, I've not seen this problem with any other packages I've successfully installed - including other Xorg ones) For reference, so_locations contains: libXaw.so.7 \ :st = .text 0x00400000, 0x0003f9e4:\ :st = .data 0x00440000, 0x00006700: libXaw.so.8 \ :st = .text 0x00450000, 0x0005cf81:\ :st = .data 0x004b0000, 0x00007ca8: ... (notice that the suffixes are off-by-one) and libXaw[67].la read: # libXaw6.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libXaw.so.7' # Names of this library. library_names='libXaw6.so.7.1 libXaw6.so.7 libXaw6.so libXaw6.so' # The name of the static archive. old_library='libXaw6.a' # Libraries that this one depends upon. dependency_libs=' -L/opt/gnu/usr/lib -L/opt/gnu/lib /opt/gnu/usr/lib/libXmu.la /opt/gnu/usr/lib/libXext.la /opt/gnu/usr/lib/libXt.la /opt/gnu/usr/lib/libX11.la /opt/gnu/usr/lib/libXau.la /opt/gnu/usr/lib/libXdmcp.la /opt/gnu/usr/lib/libSM.la /opt/gnu/usr/lib/libICE.la' # Version information for libXaw6. current=6 age=0 revision=1 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/opt/gnu/usr/lib' # libXaw7.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libXaw.so.8' # Names of this library. library_names='libXaw7.so.8.0 libXaw7.so.8 libXaw7.so libXaw7.so' # The name of the static archive. old_library='libXaw7.a' # Libraries that this one depends upon. dependency_libs=' -R/opt/gnu/usr/lib -L/opt/gnu/usr/lib -L/opt/gnu/lib /opt/gnu/usr/lib/libXmu.la /opt/gnu/usr/lib/libXext.la /opt/gnu/usr/lib/libXt.la /opt/gnu/usr/lib/libSM.la /opt/gnu/usr/lib/libICE.la /opt/gnu/usr/lib/libXpm.la /opt/gnu/usr/lib/libintl.la /opt/gnu/usr/lib/libiconv.la -lc /opt/gnu/usr/lib/libX11.la /opt/gnu/usr/lib/libXau.la /opt/gnu/usr/lib/libXdmcp.la' # Version information for libXaw7. current=7 age=0 revision=0 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/opt/gnu/usr/lib' ... notice the mangled version numbers in both files. Also, the "-R" option in libXaw7.la's dependency_libs list is GNU-specific, and shouldn't be there (especially since '-R' is a synonym for '-rpath' which is valid for *both* compilers).