From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 954919-app2.systemsdesignusa.com (954919-app2.systemsdesignusa.com [72.3.203.202]) by sourceware.org (Postfix) with ESMTPS id EE1973858D37 for ; Fri, 22 Apr 2022 05:06:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE1973858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=systemsdesignusa.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=systemsdesignusa.com Received: from localhost (localhost [127.0.0.1]) by 954919-app2.systemsdesignusa.com (Postfix) with ESMTP id B6EA02260064 for ; Fri, 22 Apr 2022 00:06:52 -0500 (CDT) Received: from 954919-app2.systemsdesignusa.com ([127.0.0.1]) by localhost (954919-app2.systemsdesignusa.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id A8gCXRMRUdGt for ; Fri, 22 Apr 2022 00:06:52 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by 954919-app2.systemsdesignusa.com (Postfix) with ESMTP id 3F2B52260066 for ; Fri, 22 Apr 2022 00:06:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at systemsdesignusa.com Received: from 954919-app2.systemsdesignusa.com ([127.0.0.1]) by localhost (954919-app2.systemsdesignusa.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vxufIy-j45Wz for ; Fri, 22 Apr 2022 00:06:52 -0500 (CDT) Received: from 954919-app2.systemsdesignusa.com (954919-app2.systemsdesignusa.com [172.24.16.202]) by 954919-app2.systemsdesignusa.com (Postfix) with ESMTP id 290152260064 for ; Fri, 22 Apr 2022 00:06:52 -0500 (CDT) Date: Fri, 22 Apr 2022 00:06:52 -0500 (CDT) From: "Kevin R. Bulgrien" To: bzip2-devel@sourceware.org Message-ID: <327445950.282128.1650604012137.JavaMail.zimbra@systemsdesignusa.com> Subject: Makefile edits for deploying via gcc 2.95.3 on SCO Openserver 5.0.7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.24.16.202] X-Mailer: Zimbra 8.8.15_GA_4257 (ZimbraWebClient - GC100 (Win)/8.8.15_GA_4257) Thread-Index: b3L99weTy93OYNLMEFDakDWBjYhfKA== Thread-Topic: Makefile edits for deploying via gcc 2.95.3 on SCO Openserver 5.0.7 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: bzip2-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bzip2-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2022 05:07:01 -0000 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