Opened 2 years ago
Closed 2 years ago
#65561 closed defect (fixed)
Need help with Port - unalz
Reported by: | RobK88 | Owned by: | RobK88 |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.2 |
Keywords: | Cc: | RobK88 | |
Port: | unalz |
Description (last modified by 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
Attachments (7)
Change History (25)
Changed 2 years ago by RobK88
comment:1 Changed 2 years ago by RobK88
Description: | modified (diff) |
---|
comment:2 Changed 2 years ago by RobK88
Description: | modified (diff) |
---|
comment:3 Changed 2 years ago by RobK88
Description: | modified (diff) |
---|
comment:4 Changed 2 years ago by RobK88
Description: | modified (diff) |
---|
comment:5 Changed 2 years ago by RobK88
Description: | modified (diff) |
---|
comment:6 Changed 2 years ago by RobK88
Cc: | RobK88 added |
---|
comment:7 Changed 2 years ago by RobK88
Owner: | set to RobK88 |
---|---|
Status: | new → assigned |
comment:8 Changed 2 years ago by 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.
comment:9 Changed 2 years ago by 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).
comment:10 Changed 2 years ago by 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.
comment:11 Changed 2 years ago by 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
.
comment:12 Changed 2 years ago by jmroot (Joshua Root)
It's reinplace
that takes the -locale
option. That makes it set LC_CTYPE
appropriately when running sed internally.
comment:13 Changed 2 years ago by 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.
comment:14 Changed 2 years ago by 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.
comment:15 Changed 2 years ago by 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$
comment:16 Changed 2 years ago by 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.
comment:17 Changed 2 years ago by 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/15643
@Ryan and @Josh, when you have a chance, please review the PR. It should be good to go!
Thanks!
comment:18 Changed 2 years ago by RobK88
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Portfile