SHLIBSUFFIX incorrect on HP-UX IA64

[bdbaddog]

This issue was originally created at: 2016-09-16 06:17:40. This issue was reported by: michael_o. michael_o said at 2016-09-16 06:17:40

hplink.py always assumes has '.sl' is the default suffix for shared libraries: [Dead link] https://bitbucket.org/scons/scons/src/8451239caec261a9b70ab75808e8d4211f74dadd/src/engine/SCons/Tool/hplink.py?at=default&fileviewer=file-view-default#hplink.py-68 [New link] https://github.com/SCons/scons/blob/4ec9a65bc07375d7e2de1ca745158862546d07f1/SCons/Tool/hplink.py#L63

Though, this is only true on PA-RISC. On IA64, this has been changed to Unix default: .so

The script shall examine the CPU arch and set the proper value accordingly.

bdbaddog said at 2016-09-16 09:21:23

Please run:

python -c "import platform; print platform.uname()"

on both pa-risc and ia64 systems and paste the return values.

Of course if you'd like to submit a pull request that would be even better.

michael_o said at 2016-09-16 11:40:03

osipovmi@blnn724x[]:~$ python -c "import platform; print platform.uname()";
('HP-UX', 'blnn724x', 'B.11.31', 'U', 'ia64', '')
osipovmi@blnn724x[]:~$ uname -a
HP-UX blnn724x B.11.31 U ia64 HP-UX

For PA-RISC, I need to see wether we have a spare machine. Most of your PA-RISC machines are either 10.20 or 11.11 without reasonable Python support. I am on IA64 exclusively.

This is PA-RISC:

uname -a
HP-UX blnn716x B.11.11 U 9000/785 2006449151 unlimited-user license
 
root@blnn716x - /
1024 # uname -m
9000/785

Additionally these lines from config.guess:

https://github.com/gcc-mirror/gcc/blob/master/config.guess#L632-L651

Basically, I would do:

if cpu_arch == ia64
  ext = .so
else
  ext = .sl

No further magic. What do you think?

michael_o said at 2016-09-16 11:46:58

Pretty much like: [Dead link] https://bitbucket.org/scons/scons/src/8451239caec261a9b70ab75808e8d4211f74dadd/src/engine/SCons/Tool/intelc.py?at=default&fileviewer=file-view-default#intelc.py-436:440 [New link] https://github.com/SCons/scons/blob/4ec9a65bc07375d7e2de1ca745158862546d07f1/SCons/Tool/intelc.py#L431

        uname_m = os.uname()[4]
        if uname_m == 'x86_64':
            abi = 'x86_64'
        else:
            abi = 'ia32'

michael_o said at 2016-09-16 15:28:07

link.py:299 is another problematic spot.

bdbaddog said at 2016-09-16 15:44:02

is the .so vs .sl compiler specific? (Not expecting it is). If you use hp's compiler vs using gcc?

michael_o said at 2016-09-17 01:53:44

I highly doubt that this is compiler-specific. Though, I have never used GCC on HP-UX I have always used cc or aCC for compilation.

I could install GCC though Porting Archive, but frankly I have no idea what to pass to GCC to figure this out.

Here is a valuable answer from the HP community: https://community.hpe.com/t5/System-Administration/so-and-sl-files/td-p/3780528

[michael-o]

This is still a problem with 3.0.5. I would simply wipe this, PA-RISC is dead.

[michael-o]

Still a problem on 4.4.0. Patch:

diff -ur SCons/Platform/hpux.py SCons/Platform/hpux.py
--- SCons/Platform/hpux.py	2021-11-17 17:06:47 +0000
+++ SCons/Platform/hpux.py	2022-08-10 14:29:41 +0000
@@ -35,7 +35,7 @@
     #Based on HP-UX11i: ARG_MAX=2048000 - 3000 for environment expansion
     env['MAXLINELENGTH']  = 2045000
 
-    env['SHLIBSUFFIX'] = '.sl'
+    env['SHLIBSUFFIX'] = '.so'
     env['HOST_OS'] = 'hpux'
 
 # Local Variables:
diff -ur SCons/Tool/hplink.py SCons/Tool/hplink.py
--- SCons/Tool/hplink.py	2021-11-15 20:50:26 +0000
+++ SCons/Tool/hplink.py	2022-08-10 14:30:10 +0000
@@ -58,9 +58,10 @@
     """
     link.generate(env)
     
-    env['LINKFLAGS']   = SCons.Util.CLVar('-Wl,+s -Wl,+vnocompatwarnings')
+    env['LINKFLAGS']   = SCons.Util.CLVar('-Wl,+s')
     env['SHLINKFLAGS'] = SCons.Util.CLVar('$LINKFLAGS -b')
-    env['SHLIBSUFFIX'] = '.sl'
+    env["_SHLIBVERSIONFLAGS"] = "$SHLIBVERSIONFLAGS -Wl,+h,$_SHLIBSONAME"
+    env['SHLIBSUFFIX'] = '.so'
 
 def exists(env):
     return ccLinker

[mwichmann]

Applying this fix seems simple enough, though nobody else has anything to test on. PA-RISC may be dead, but Itanium is pretty dead too, no?

[michael-o]

Applying this fix seems simple enough, though nobody else has anything to test on. PA-RISC may be dead, but Itanium is pretty dead too, no?

Technically, yes. Itanium ist not produced, but HPE will provide support for all machines beyond 2025 and I will/have to continue to run those for many reasons. SCons is the only way to compile libserf which I need for Subversion which we need for manage 100 000s LoC engineering code.

Yes, this will break PA-RISC, but this platform is truly dead. SCons has been working for me just fine on HP-UX IA64 for years for at least libserf. So the patch has been tested many times.

[mwichmann]

Sure - I'd take the argument that if PA-RISC, if there's still one running somewhere, can't run a Python that SCons requires (which at this point is 3.6 or greater) then there's no reason to keep support for such a platform in the current tip of the tree.

What do you think, @bdbaddog

[michael-o]

I bet that Python 3.x does not even compile on PA-RISC. I took me quite some effort to make Python 3.8 to compile and run on IA64, I have upstreamed all patches and some are still open.

[bdbaddog]

Can't we detect if SCons is running on itanium and just make these changes in that case. That way if someone out there is still building on PA-RISC we don't break them. Should be trivial right?

[mwichmann]

seems like that sequence is excerpted above, but someone would have to run an old SCons to work with Python 2.x anyway, which it sounds like would be a limitation.

[michael-o]

Unfortunately, the issue still persists on main.

[mwichmann]

yeah, doesn't seem like anyone applied the change.