Makefile edits for deploying via gcc 2.95.3 on SCO Openserver 5.0.7

Makefile edits for deploying via gcc 2.95.3 on SCO Openserver 5.0.7

[Kevin R. Bulgrien]

This is a courtesy note regarding some local edits I made to:

  bzip2-1.0.8/Makefile
  bzip2-1.0.8/Makefile-libbz2_so

Feel free to disregard as this deployment was made on a long out-of-support
operating system, but, do consider possibly making a note in:

  README.COMPILATION.PROBLEMS
 
First, I ran into an issue with bzip2-1.0.8/Makefile-libbz2_so on this system.
It did not like the -Wl,-soname argument, and kicked out a warning that
very likely meant that the intended effect off setting the DT_SONAME
attribute probably did not happen.  The message was:

  UX:i386ld: WARNING: option '-o' already seen; ...

Basically, the system 'ld' does not understand the '-soname' argument, so
it thinks the argument list goes something along the lines of:

  ld ... -s -o name libbz2.so.1.0 -o libbz2.so.1.0.8 ...

Reviewing the 'ld' man page turns up this information:

 -h name
   In dynamic mode only, when building a shared object, record name in the
   object's dynamic section. name will be recorded in executables that are
   linked with this object rather than the shared object's pathname.
   Accordingly, name will be used by the dynamic linker as the pathname of
   the shared object to search for at run time.

Therefore, in such a situation, I believe that bzip2-1.0.8/Makefile-libbz2_so
needs an edit along the lines of:

-       $(CC) -shared -Wl,-soname -Wl,libbz2.so.1.0 -o libbz2.so.1.0.8 $(OBJS)
+       $(CC) -shared -Wl,-h -Wl,libbz2.so.1.0 -o libbz2.so.1.0.8 $(OBJS)

This does, indeed, eliminate the aforementioned warning.

In the interest of giving credit where credit is due, I found a SCO patch
that led me to the '-h'.  I had not worked enough with ld or shared
objects enough to pick up on it via man page alone.

  ftp://ftp2.sco.com/pub/skunkware/src/fileutil/aspell-osr5.patch

For posterity:

$ uname -a
SCO_SV sddemokb 3.2 5.0.7 i386
$ ld -V
UX:i386ld: INFO: SCO UNIX Development System  Release 5.2.0A 03Aug06
$ gcc -v
Reading specs from /usr/gnu/lib/gcc-lib/i586-pc-sco3.2v5.0/2.95.3/specs
gcc version 2.95.3 20010315 (release)

Granted that the following is much more than the change above, I'll share
my patches that I made for my own sake.  The verbosity is not something I'd
imagine is desired for a public release.  I'm not exactly deeply steeped in
experience writing portable or public Makefiles, so its written to remind me
of things in case I forget and then run into a similar situation somewhere
else.  I certainly don't expect this patch to land in a project release.

I also added an 'install' target so the packaging tool I use could be easily
made to also deploy the shared object resources.

--- bzip2-1.0.8/Makefile-libbz2_so.orig 2019-07-13 12:50:05.000000000 -0500
+++ bzip2-1.0.8/Makefile-libbz2_so      2022-04-21 20:08:07.000000000 -0500
@@ -26,6 +26,9 @@
 BIGFILES=-D_FILE_OFFSET_BITS=64
 CFLAGS=-fpic -fPIC -Wall -Winline -O2 -g $(BIGFILES)

+# Where you want it installed when you do 'make install'
+PREFIX=/usr/local
+
 OBJS= blocksort.o  \
       huffman.o    \
       crctable.o   \
@@ -34,11 +37,50 @@
       decompress.o \
       bzlib.o

+# UX:i386ld: WARNING: option '-o' already seen; ...
+#   gcc -Wl,-soname -Wl,libbz2.so.1.0 ...
+#
+# SCO Openserver 5.0.7 gcc 2.95.3 workaround:
+#   gcc -Wl,-h -Wl,libbz2.so.1.0
+#
+# The SCO Openserver 5.0.7 'ld' man page says:
+#   -h name
+#     In dynamic mode only, when building a shared object, record name in the
+#     object's dynamic section. name will be recorded in executables that are
+#     linked with this object rather than the shared object's pathname.
+#     Accordingly, name will be used by the dynamic linker as the pathname of
+#     the shared object to search for at run time.
+#
+# Proof:
+#   Add -v to the gcc command-line to report the collect2 link command. The
+#   "-h libbz2.so.1.0" is observable.  Next, manually run the shown collect2
+#   command with -v added.  This shows an ld command with "-h libbz2.so.1.0".
+#
+# To use the workaround, either override Wl_SONAME value on the command-line:
+#   $ make -f Makefile-libbz2_so Wl_SONAME="-Wl,-h"
+# or, set the Wl_SONAME variable here:
+#
+# Wl_SONAME = -Wl,-soname
+Wl_SONAME = -Wl,-h
+
+LN_NAME=libbz2.so.1.0
+SO_NAME=libbz2.so.1.0.8
+
 all: $(OBJS)
-       $(CC) -shared -Wl,-soname -Wl,libbz2.so.1.0 -o libbz2.so.1.0.8 $(OBJS)
-       $(CC) $(CFLAGS) -o bzip2-shared bzip2.c libbz2.so.1.0.8
-       rm -f libbz2.so.1.0
-       ln -s libbz2.so.1.0.8 libbz2.so.1.0
+       $(CC) -shared $(Wl_SONAME) -Wl,$(LN_NAME) -o $(SO_NAME) $(OBJS)
+       $(CC) $(CFLAGS) -o bzip2-shared bzip2.c $(SO_NAME)
+       rm -f $(LN_NAME); \
+       ln -s $(SO_NAME) $(LN_NAME)
+
+install: all
+       if ( test ! -d $(PREFIX)/lib ); \
+       then \
+         mkdir -p $(PREFIX)/lib; \
+         chmod a+rx $(PREFIX)/lib; \
+       fi; \
+       cp -f $(SO_NAME) $(PREFIX)/lib/$(SO_NAME); \
+       chmod a+r $(PREFIX)/lib/$(SO_NAME); \
+       ln -s $(PREFIX)/lib/$(SO_NAME) $(PREFIX)/lib/$(LN_NAME)

 clean:
        rm -f $(OBJS) bzip2.o libbz2.so.1.0.8 libbz2.so.1.0 bzip2-shared

It also happened that when I ran 'make install', that various resources were
created without world read permission.  I didn't chase that down.  Rather I
just did this:

--- bzip2-1.0.8/Makefile.orig   2019-07-13 12:50:05.000000000 -0500
+++ bzip2-1.0.8/Makefile        2022-04-21 22:31:49.000000000 -0500
@@ -79,10 +79,10 @@
        cp -f bzip2 $(PREFIX)/bin/bunzip2
        cp -f bzip2 $(PREFIX)/bin/bzcat
        cp -f bzip2recover $(PREFIX)/bin/bzip2recover
-       chmod a+x $(PREFIX)/bin/bzip2
-       chmod a+x $(PREFIX)/bin/bunzip2
-       chmod a+x $(PREFIX)/bin/bzcat
-       chmod a+x $(PREFIX)/bin/bzip2recover
+       chmod a+rx $(PREFIX)/bin/bzip2
+       chmod a+rx $(PREFIX)/bin/bunzip2
+       chmod a+rx $(PREFIX)/bin/bzcat
+       chmod a+rx $(PREFIX)/bin/bzip2recover
        cp -f bzip2.1 $(PREFIX)/man/man1
        chmod a+r $(PREFIX)/man/man1/bzip2.1
        cp -f bzlib.h $(PREFIX)/include
@@ -92,13 +92,13 @@
        cp -f bzgrep $(PREFIX)/bin/bzgrep
        ln -s -f $(PREFIX)/bin/bzgrep $(PREFIX)/bin/bzegrep
        ln -s -f $(PREFIX)/bin/bzgrep $(PREFIX)/bin/bzfgrep
-       chmod a+x $(PREFIX)/bin/bzgrep
+       chmod a+rx $(PREFIX)/bin/bzgrep
        cp -f bzmore $(PREFIX)/bin/bzmore
        ln -s -f $(PREFIX)/bin/bzmore $(PREFIX)/bin/bzless
-       chmod a+x $(PREFIX)/bin/bzmore
+       chmod a+rx $(PREFIX)/bin/bzmore
        cp -f bzdiff $(PREFIX)/bin/bzdiff
        ln -s -f $(PREFIX)/bin/bzdiff $(PREFIX)/bin/bzcmp
-       chmod a+x $(PREFIX)/bin/bzdiff
+       chmod a+rx $(PREFIX)/bin/bzdiff
        cp -f bzgrep.1 bzmore.1 bzdiff.1 $(PREFIX)/man/man1
        chmod a+r $(PREFIX)/man/man1/bzgrep.1
        chmod a+r $(PREFIX)/man/man1/bzmore.1

In any event, if it were to tickle someone's funny bone, when/if the project
ever updated, I guess that at least the README.COMPILATION.PROBLEMS could
stand a note for any other poor soul working with one of these dinosaurs.
Granted, it's unlikely, LOL, but this way, if I forget, maybe a web
search will remind me what I did.

--

Kevin R. Bulgrien