Opened 4 years ago
Closed 3 years ago
#62276 closed defect (fixed)
optool @0.1: error: expected ';' after top level declarator
Reported by: | RobK88 | Owned by: | raimue (Rainer Müller) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | lion | Cc: | |
Port: | optool |
Description
optool fails to build on Lion. main.log is attached.
Grinchs-Mac-Pro:~ grinch$ sudo port clean optool ---> Cleaning optool Grinchs-Mac-Pro:~ grinch$ sudo port install optool ---> Fetching distfiles for optool ---> Verifying checksums for optool ---> Extracting optool ---> Applying patches to optool ---> Configuring optool ---> Building optool Error: Failed to build optool: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_optool/optool/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port optool failed
Attachments (1)
Change History (11)
Changed 4 years ago by RobK88
comment:1 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | raimue@… removed |
---|---|
Keywords: | lion added; Lion removed |
Owner: | set to raimue |
Status: | new → assigned |
Summary: | optool Fails to Build on Lion → optool @0.1: error: expected ';' after top level declarator |
The first error in the log is:
optool/defines.h:68:22: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] typedef NS_ENUM(int, OPError) { ^~~~~~~ optool/defines.h:68:9: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] typedef NS_ENUM(int, OPError) { ~~~~~~~ ^ optool/defines.h:68:30: error: expected ';' after top level declarator typedef NS_ENUM(int, OPError) { ^ ; 2 warnings and 1 error generated.
I'm aware that NS_ENUM
is a "new" compiler feature, but I don't know how new. Presumably the version of clang available on Lion is not new enough. optool 0.1 was released in 2014 which is several years after Lion.
Rainer hasn't been interested lately in working on issues only affecting older systems, but if a solution can be found, he usually accepts it.
The developers of optool have a precompiled binary available on their site; you could see if that works.
comment:2 Changed 4 years ago by RobK88
Thanks Ryan. Unfortunately, the precompiled binary for optool from the developer's website just crashes on Lion.
Clang-9.0 etc is available on Lion. Perhaps, I can try to compile optool using a different compiler. Please let me know how I can easily try doing that.
Thanks.
comment:3 Changed 4 years ago by Wowfunhappy (Jonathan)
A newer version of clang would probably be able to compile it. The problem is running it. I have previously tried compiling optool on Mavericks (outside Macports; default Clang), with 10.7 specified as a minimum target. It builds fine, but it doesn't actually run on 10.7.
I too would love to have this working on Lion, but unfortunately it's likely in need of a real patch.
comment:4 Changed 4 years ago by RobK88
Hmm. Well I couldn't get it to build with clang 9.0 either
Here is the result:
sudo port clean optool sudo port -v install optool configure.compiler=macports-clang-9.0 blah blah blah.... ** BUILD FAILED ** The following build commands failed: CompileC build/optool.build/Release/optool.build/Objects-normal/x86_64/headers.o optool/headers.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler CompileC build/optool.build/Release/optool.build/Objects-normal/x86_64/operations.o optool/operations.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler CompileC build/optool.build/Release/optool.build/Objects-normal/x86_64/main.o optool/main.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler (3 failures) Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_optool/optool/work/optool-0.1" && /usr/bin/xcodebuild -alltargets -configuration Deployment build INSTALL_PATH=/Applications/MacPorts OBJROOT="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_optool/optool/work/optool-0.1/build/" SYMROOT="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_optool/optool/work/optool-0.1/build/" MACOSX_DEPLOYMENT_TARGET=10.7 ARCHS=x86_64 SDKROOT="" CLANG_CXX_LIBRARY="libc++" Exit code: 65 Error: Failed to build optool: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_optool/optool/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port optool failed
comment:5 Changed 4 years ago by RobK88
I can confirm that optool still will not build on Lion. I tried various compilers with no success.
comment:6 Changed 4 years ago by kencu (Ken)
comment:7 Changed 4 years ago by RobK88
I just synced. And now optool does build and install on Lion!
Many thanks Ken for the fix!
comment:8 Changed 4 years ago by RobK88
P.S. I have been using "optool" to remove code signatures from Mac binaries so I can modify them. But I have found that the "unsign" tool from steakknife on Githib works better.
"Unsign" compiles easily on Lion and Mtn Lion. I suspect it will also compile on later versions of Mac OS X too.
Unfortunately, unsign is not in Macports. But it would be easy to create a portfile for it.
comment:9 Changed 3 years ago by RobK88
This ticket should probably be closed. The optool port has been fixed.
optool compiles and installs just fine now on my Mac running Lion.
bash-3.2$ port installed optool The following ports are currently installed: optool @0.1_0 (active) bash-3.2$ bash-3.2$ optool optool v0.1 USAGE: install -c <command> -p <payload> -t <target> [-o=<output>] [-b] [--resign] Inserts an LC_LOAD command into the target binary which points to the payload. This may render some executables unusable. uninstall -p <payload> -t <target> [-o=<output>] [-b] [--resign] Removes any LC_LOAD commands which point to a given payload from the target binary. This may render some executables unusable. strip [-w] -t <target> Removes a code signature load command from the given binary. restore -t <target> Restores any backup made on the target by this tool. aslr -t <target> [-o=<output>] [-b] [--resign] Removes an ASLR flag from the macho header if it exists. This may render some executables unusable OPTIONS: [-w --weak] Used with the STRIP command to weakly remove the signature. Without this, the code signature is replaced with null bytes on the binary and its LOAD command is removed. [--resign] Try to repair the code signature after any operations are done. This may render some executables unusable. -t|--target <target> Required of all commands to specify the target executable to modify -p|--payload <payload> Required of the INSTALL and UNINSTALL commands to specify the path to a DYLIB to point the LOAD command to [-c --command] Specify which type of load command to use in INSTALL. Can be reexport for LC_REEXPORT_DYLIB, weak for LC_LOAD_WEAK_DYLIB, upward for LC_LOAD_UPWARD_DYLIB, or load for LC_LOAD_DYLIB [-b --backup] Backup the executable to a suffixed path (in the form of _backup.BUNDLEVERSION) [-h --help] Show this message (C) 2014 Alexander S. Zielenski. Licensed under BSD bash-3.2$
comment:10 Changed 3 years ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
main.log