Need help with Port - unalz

[RobK88]

I need some help with fixing an old and abandoned port -- unalz.

It is broken in Macports. I have fixed the port and it will build on most systems just fine. One big step forward.

But on older Mac systems, I get the dreaded unalz is using libstdc++ (this installation is configured to use libc++).

I have patched the Makefile accordingly so the CFLAGS, CXXFLAGS and LDFLAGS set by Macports are honoured and appended to the flags in the Makefile.

I can tell that the "-stdlib=libc++" command line option is being passed to the compiler. But it looks like the default compiler on old Macs (e.g. g++ 4.2 on Lion) does not understand the -stdlib=libc++ command line option. e.g. cc1plus: error: unrecognized command line option "-stdlib=libc++"

Of course, I can get around this by specifying configure.compiler=macports-clang-9.0 when installing or upgrading this port using macports.

Attached is the patched Makefile and the draft portfile. (I know I need to fix the formatting etc in the draft portfile).

Any help would be greatly appreciated. Is there a way to get the old Apple compilers to understand the "-stdlib=libc++" command line option? Maybe I need to specify the compiler in the portfile. e.g. clang-9.0 or greater. How would I do that?

P.S. As recently as 2015, the Debian Project has fixed a number of bugs (including buffer overflow bugs) in unalz. I will need to add the Debian patches to this portfile. But I want to address the compiler and stdc++ issue first. See ​https://sources.debian.org/patches/unalz/0.65-8/ and ​https://packages.debian.org/source/stable/unalz

[RobK88]

Portfile

[RobK88]

Makefile Patched by Macports

[RobK88]

Makefile Patch

[RobK88]

I think I found the problem to the compiler issue.

Because the default Apple clang compiler does not understand the -stdlib=libc++ command line option, I needed to add the following to the portfile:

compiler.blacklist		clang

P.S. I also added PortGroup makefile 1.0. But it did not fix the problem. I needed to blacklist the Apple clang compiler.

[jmroot (Joshua Root)]

I can assure you that /usr/bin/clang++ does understand the -stdlib option on 10.7, and that Xcode clang is the default compiler used by MacPorts on that platform. If the correct compiler is being used, the issue is probably the CXXFLAGS.

It's OK to have a ticket for a WIP contribution, but for questions about Portfile development, you're more likely to get help asking on the macports-dev mailing list (most people won't even see this ticket).

[ryandesign (Ryan Carsten Schmidt)]

build.args       CPP="${configure.cxx}" \
                 CXX="${configure.cxx}" \
                 CC="${configure.cc}"

Normally CPP is used for the C preprocessor and CXX is used for the C++ compiler. However this Makefile does appear to misuse CPP as the C++ compiler and does not use CXX. As such there's no need to set CXX and you should add a comment noting the misuse of CPP so that others don't look at it and think it's a typo.

It doesn't patch for me:

--->  Patching UnAlz.cpp: s|register ||
DEBUG: Executing reinplace: /usr/bin/sed {s|register ||} </opt/local/var/macports/build/_private_tmp_a/unalz/work/unalz/UnAlz.cpp >@file11
sed: RE error: illegal byte sequence

Since this only affects two instances, as does the next reinplace which has the same problem, there's no reason not to use a patchfile instead of a reinplace. Alternately, add -locale C to tell sed to treat the file as ASCII bytes instead of UTF-8. (I think the file is actually in some Chinese charset but since you're just replacing ASCII characters it's fine to treat the whole file as ASCII for this.)

After fixing that it builds fine for me on macOS 12.

If you are on OS X 10.8 or earlier and it doesn't link due to missing symbols, you may also need the -stdlib flag (or, for simplicity, all CXXFLAGS) everywhere CPP is used to link, where currently only LDFLAGS are used.

[RobK88]

Ryan and Joshua -- Many thanks for all the feedback.

I will definitely add a comment in the Portfile regarding the misuse of CPP.

And I am planning to eliminate ALL the reinplace statements, when I incorporate all the patch files from the Debian Project. And the first two reinplace statements are no longer needed because I added PortGroup makefile 1.0 to the portfile.

(FYI -- Debian never bothered deleting all the register keywords in the source. As you know the register keyword has been deprecated in C++17. It will just compile fine on a compiler supporting C++17 but a warning message will be thrown. I am debating whether to just keep register in the source. It may help when the source is being compiled on older compilers).

Ryan, thank you for your last comment! I checked the logs, and you are right. The Apple clang compiler on my Mac running Lion does understand the -stdlib flag. The code did compile but it failed to link due to missing symbols. So I will need to add CXXFLAGS everywhere CPP is being used to link! Duh! I should have looked at the logs more carefully.

And finally, I would be grateful if you could give me some advice regarding the homepage and master_sites. The homepage for unalz has disappeared from the net. But I can find in in the Wayback Machine. So I could use that instead in the portfile. But the link to the source is no longer available (even on the Wayback Machine). I will keep looking for another website for the source code. Alternatively, I could use the link to the source code at the Debian project. (But then I will need to update the portfile accordingly since as you know Debian uses its own standardized format for source code filenames). Or I could leave the portfile as is since Macports already has a copy of the source in its repos.

P.S. For my further education, please explain your comment "add -locale C to tell sed to treat the file as ASCII". How do you set the locale with sed. I do not believe that -locale is a command line option for sed.

[jmroot (Joshua Root)]

It's reinplace that takes the -locale option. That makes it set LC_CTYPE appropriately when running sed internally.

[RobK88]

Thanks Joshua! Yes I see in the Macports Guide that reinplace is a TCL command that accepts the -locale option. The reference to sed threw me.

I added -locale C to all the reinplace statements in the portfile and it works. But as I mentioned previously, I will likely eliminate all the reinplace commands in the portfile and just use patch files instead.

[RobK88]

Ryan and Joshua -- Thanks gain for all your help and guidance.

I was able to locate the developers new website. So I was able to properly update the homepage in the portfile.

Attached please find the portfile and a zip file containing all the needed patches. I was able to incorporate all the patches created by the Debian project to address bugs and buffer overflow issues in unalz.

Also attached is a diff file showing the changes from the original portfile.

When a I get a chance I will refresh my memory and figure out how to submit the updated port via a Github pull request.

[RobK88]

Updated Portfile

[RobK88]

unalz Patches

[RobK88]

Portfile-unalz diff

[RobK88]

Final Portfile

[RobK88]

I finally refreshed my memory and submitted a pull request to Github.

See ​https://github.com/macports/macports-ports/pull/15527

Crossing my fingers. :-)

The updated port provides bug fixes and security updates. unalz seems to work just fine now:

bash-3.2$ unalz
unalz v0.65 (2009/04/01) 
Copyright(C) 2004-2009 by kippler@gmail.com (http://www.kipple.pe.kr) 

Usage : unalz [<switches>...] archive.alz [<file names to extract>...]

<switches>
  -utf8        : convert filename's codepage to UTF-8 (default)
  -cp949       : convert filename's codepage to CP949
  -euc-kr      : convert filename's codepage to EUC-KR
  -l           : list contents of archive
  -d directory : set output directory
  -p           : extract files to pipe, no messages
  -pwd <pwd>   : set password
bash-3.2$ 
bash-3.2$ file /opt/local/bin/unalz
/opt/local/bin/unalz: Mach-O universal binary with 2 architectures
/opt/local/bin/unalz (for architecture x86_64):	Mach-O 64-bit executable x86_64
/opt/local/bin/unalz (for architecture i386):	Mach-O executable i386
bash-3.2$ 
bash-3.2$ lipo -info  /opt/local/bin/unalz
Architectures in the fat file: /opt/local/bin/unalz are: x86_64 i386 
bash-3.2$

[RobK88]

Ryan -- As you pointed out, with the older compilers (such as Apple's clang), the binary will not properly link unless -stdlib=libc++ is passed to each linking command. If you do not do this, the build (or more precisely the linking) will fail with "missing symbols".

I just discovered a simpler and more elegant way to ensure that the binaries are linked against stdc++. Instead of patching the Makefile to either add $(CXXFLAGS) (or just -stdlib=libc++) to all the linking commands, it is just easier and more elegant to add this one line to the portfile:

configure.ldflags-append    "-stdlib=${configure.cxx_stdlib}"

I tested it and it works. I will remember this for my next port. I have already submitted the fixed port for unalz. I guess I could change and submit an upgraded portfile but I would have to redo all the 7 patch files. That would be too much work for little gain.

[RobK88]

I closed the original Pull Request submitted a week ago since I was unable to push changes from my local git repo to my Github repo. I did not want to --force my push.

I wanted to incorporate some changes suggested from Ryan on another port. So I created a new Pull Request for unalz: ​https://github.com/macports/macports-ports/pull/15634

@Ryan and @Josh, when you have a chance, please review the PR. It should be good to go!

Thanks!

[RobK88]

In 5080b0deda26a30fa23b7e84a567326a2fa4e4e7/macports-ports (master):

unalz: fix bugs and security flaws

• Revive abandoned port
• Fix Fails to Build From Source (FTBFS) on modern compilers
• Use system zlib from Macports instead of the internal old version of zlib
• Use system libbz2 from Macports instead of the internal old version of libbz2
• Fix type error caused by introduction of z_crc_t type in zlib
• Correct pipe mode. Don't do close() or utime() in pipe mode
• Check to see if the filename length field is invalid
• Fix file offset overflow on incomplete files
• Add the license to the Portfile
• Update the long description in the Portfile
• Add two new library dependencies to the Portfile - zlib and bzip2
• Update the developer's homepage in the Portfile
• Remove unnecessary statements from the Portfile
• Add revision number to the Portfile

Closes: #60014
Closes: #65561