From: "Kevin R. Bulgrien" <kevinb@systemsdesignusa.com>
To: bzip2-devel@sourceware.org
Subject: Makefile edits for deploying via gcc 2.95.3 on SCO Openserver 5.0.7
Date: Fri, 22 Apr 2022 00:06:52 -0500 (CDT) [thread overview]
Message-ID: <327445950.282128.1650604012137.JavaMail.zimbra@systemsdesignusa.com> (raw)
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
reply other threads:[~2022-04-22 5:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=327445950.282128.1650604012137.JavaMail.zimbra@systemsdesignusa.com \
--to=kevinb@systemsdesignusa.com \
--cc=bzip2-devel@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).