Makefile edits for deploying via gcc 2.95.3 on SCO Openserver 5.0.7
Kevin R. Bulgrien
kevinb@systemsdesignusa.com
Fri Apr 22 05:06:52 GMT 2022
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
More information about the Bzip2-devel
mailing list