Fails to build on macOS Sierra

[rakkesh]

Firstly, I had to add .dylib to CMAKE_FIND_LIBRARY_SUFFIXES incmake/modules/3rdParty.cmake for the build to select system libiconv. But then, the build failed due to errors - call to 'stringToNumber' is ambiguous and call to 'numberToString' is ambiguous.

The complete build log is - https://gist.github.com/rakkesh/728e0d1506b5d96688be42ddd866930d

[Martchus]

For the .dylib you could send me a patch/PR if you like. I assume it is the extension of dynamic libs under macOS?

The actual error looks like your compiler has bad C++11 support. According to the log you're using AppleClang 8.0.0.8000042 which I guess is some customized Clang by Apple. Not sure how old/new it is and what is supports because they also customized the version number. Can you use the latest stock CMake (3.9.1)? This works for me (as well as GCC and mingw-w64).

[Martchus]

Could you provide the actual Clang version number? See http://stackoverflow.com/questions/33603027/apple-clang-version

But I'm not sure which is the minimum version required by c++utilities (just that C++11 must be fully supported).

[rakkesh]

Sure, I can send in a PR but would like to make this build with Xcode Command Line Tools instead of installing llvm from Homebrew.

By the way, the version info of the compiler is as follows -

$ clang++ --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

$ ./vers
__cplusplus: 199711

I was able to get rid of the ambiguous call error by adding -stdlib=libstdc++ flags but now I get a weird missing static lib error -

/tmp/tageditor--cpp-utilities-20170110-24798-4z2ibp/cpp-utilities-4.4.0/application/./argumentparser.h:7:10: fatal error: 'initializer_list' file not found
#include <initializer_list>

Edit: Adding -std=c++11 -stdlib=libc++ to enable C++11 doesn't seem to have an effect.

[rakkesh]

$ clang++ -E -x c++ - -v < /dev/null
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.12.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 274.2 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0 -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/rakkesh -ferror-limit 19 -fmessage-length 158 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.12.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o - -x c++ -
clang -cc1 version 8.0.0 (clang-800.0.42.1) default target x86_64-apple-darwin16.3.0
ignoring nonexistent directory "/usr/include/c++/v1"
#include "..." search starts here:
#include <...> search starts here:
 /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1
 /usr/local/include
 /Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/include
 /Library/Developer/CommandLineTools/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
# 1 "<stdin>"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 337 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "<stdin>" 2

initializer_list is present in /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1 (or /Library/Developer/CommandLineTools/usr/include/c++/v1), it is already in the search path. Even though adding CPPFLAGS=-I/Library/Developer/CommandLineTools/usr/include/c++/v1 did not affect the build and failed with 'initializer_list' file not found. Is there any special CMAKE flag to add CPPFLAGS?

[Martchus]

If it is in search path it should be available. Something is wrong with your setup. When switching std lib clean all files from previous build, just to be sure.

What speaks against homebrew? If it has recent stock CLang and libs I would use it rather than customized toolchain provided by Apple. Setting -std=c++11 should not be necessary as the build system sets it.

[Martchus]

BTW: Setting CPPFLAGS might not work. Try specifying required include paths via CMake command line option -DCMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES=path1;path2;path3....

[rakkesh]

What speaks against homebrew?

I'm actually working to get tageditor into Homebrew core formulae; did not realise llvm is in Homebrew core and mistook llvm to be in a Homebrew tap (homebrew-dupes), so, did not want to use it.

I'll try out with latest llvm from Homebrew and get back with an update.

[rakkesh]

==> cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="/usr/local/Cellar/tageditor/2.1.1/libexec/vendor" ..
-- The C compiler identification is Clang 3.9.1
-- The CXX compiler identification is Clang 3.9.1
-- Check for working C compiler: /usr/local/opt/llvm/bin/clang
-- Check for working C compiler: /usr/local/opt/llvm/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/local/opt/llvm/bin/clang++
-- Check for working CXX compiler: /usr/local/opt/llvm/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for iconv
-- Looking for iconv - not found
-- Linking c++utilities dynamically against external library iconv (/usr/lib/libiconv.dylib).
-- Configuring project c++utilities
-- Using default CXX11 ABI (not forcing old CX11 ABI).
-- Using template for Config.cmake from own (c++utilities) source directory.
-- Using template for global.h from own (c++utilities) source directory.
-- Using template for template.pc from own (c++utilities) source directory.
-- Linking test target dynamically against c++utilities
-- Using template for doxygen from own (c++utilities) source directory.
CMake Warning at cmake/modules/Doxygen.cmake:25 (message):
  Doxygen not found, unable to add target for generating API documentation
  for c++utilities
Call Stack (most recent call first):
  CMakeLists.txt:142 (include)

-- Using template for config.h from own (c++utilities) source directory.
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/tageditor--cpp-utilities-20170110-31199-11f0b5f/cpp-utilities-4.4.0/build
==> make DESTDIR=/usr/local/Cellar/tageditor/2.1.1/libexec/vendor install
Scanning dependencies of target c++utilities
[ 19%] Building CXX object CMakeFiles/c++utilities.dir/application/argumentparser.cpp.o
[ 19%] Building CXX object CMakeFiles/c++utilities.dir/application/commandlineutils.cpp.o
[ 19%] Building CXX object CMakeFiles/c++utilities.dir/application/fakeqtconfigarguments.cpp.o
[ 19%] Building CXX object CMakeFiles/c++utilities.dir/application/failure.cpp.o
[ 23%] Building CXX object CMakeFiles/c++utilities.dir/chrono/datetime.cpp.o
[ 28%] Building CXX object CMakeFiles/c++utilities.dir/chrono/period.cpp.o
[ 33%] Building CXX object CMakeFiles/c++utilities.dir/chrono/timespan.cpp.o
[ 38%] Building CXX object CMakeFiles/c++utilities.dir/conversion/conversionexception.cpp.o
[ 42%] Building CXX object CMakeFiles/c++utilities.dir/conversion/stringconversion.cpp.o
[ 47%] Building CXX object CMakeFiles/c++utilities.dir/io/ansiescapecodes.cpp.o
[ 52%] Building CXX object CMakeFiles/c++utilities.dir/io/binaryreader.cpp.o
[ 57%] Building CXX object CMakeFiles/c++utilities.dir/io/binarywriter.cpp.o
[ 61%] Building CXX object CMakeFiles/c++utilities.dir/io/bitreader.cpp.o
[ 66%] Building CXX object CMakeFiles/c++utilities.dir/io/inifile.cpp.o
[ 71%] Building CXX object CMakeFiles/c++utilities.dir/io/path.cpp.o
[ 76%] Building CXX object CMakeFiles/c++utilities.dir/io/catchiofailure.cpp.o
[ 80%] Building CXX object CMakeFiles/c++utilities.dir/io/nativefilestream.cpp.o
[ 85%] Building CXX object CMakeFiles/c++utilities.dir/math/math.cpp.o
[ 90%] Building CXX object CMakeFiles/c++utilities.dir/misc/random.cpp.o
/tmp/tageditor--cpp-utilities-20170110-31199-11f0b5f/cpp-utilities-4.4.0/io/path.cpp:121:4: error: Platform not supported.
#  error Platform not supported.
   ^
/tmp/tageditor--cpp-utilities-20170110-31199-11f0b5f/cpp-utilities-4.4.0/io/path.cpp:175:4: error: Platform not supported.
#  error Platform not supported.
   ^
2 errors generated.

There seems to be some check failing in the code.

[Martchus]

So it seems like PLATFORM_UNIX is not defined in your environment. You can check whether the Unix branch actually works under macOS by just altering the code so the branch is definitely used. If it works, then you can try to fix the condition (PLATFORM_MAC should be defined). If not, I will make this method and depended functionality optional.

[rakkesh]

As I'm neither using GNUC or xlc, I have changed the pre-processor on this line to #if defined(__APPLE__) for enabling PLATFORM_MAC; also, using common logic for both unix and macOS #if defined(PLATFORM_UNIX) || defined(PLATFORM_MAC) but got an error - Undefined symbols for architecture x86_64.

I'll go further down the rabbit-hole later tomorrow with your input.

[Martchus]

Thanks for the effort. Changing the condition in global.h makes sense. Good that the UNIX part works also on mac OS. Not sure about this next error (needed line/file/command/context).

[rakkesh]

I had changed io/path.cpp to have this condition all throughout the file - #if defined(PLATFORM_UNIX) || defined(PLATFORM_MAC)

[Martchus]

As alread said, I can only guess about the error message without more context. Migh be a linker error. You can enable verbose output by adding VERBOSE=1 to make arguments.

[rakkesh]

I have a gist of the error while running make install - https://gist.github.com/anonymous/f0e1625d836a24dc30c018be565d52e3

There are two instances of running make in the gist - the first one without and latter with VERBOSE=1.

[Martchus]

So it fails in the linker line as suspected. Seems like symbols from the standard library can not be found. You override the default standard library using -stdlib=libc++ flag. I suspect that it now tries to link against libc++ but still uses header files for the libstd++. When this is true, altering the include path using -DCMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES should fix the issue. From the output I don't know which include directories are actually used in your build. You could also switch to using recent libstd++.

When testing new configuration, always discard files from previous build to be sure to have a clean build.

BTW: The verbose output only shows the linker line because compile units have been reused from previous non-verbose make call (so it is not as verbose as it could have been).

[rakkesh]

Thanks for your detailed response, that was quite insightful. The llvm installation from Homebrew has a caveat which I had missed. 😒

LLVM executables are installed in /usr/local/opt/llvm/bin.
Extra tools are installed in /usr/local/opt/llvm/share/llvm.
To use the bundled libc++ please add the following LDFLAGS:
  LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"

This formula is keg-only, which means it was not symlinked into /usr/local.

macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/llvm/lib
    CPPFLAGS: -I/usr/local/opt/llvm/include

Since, llvm installation is quite big, I prefer it to be a build time dependency for cpp-utilities. That would mean, llvm will not be present when precompiled binary of tageditor (vendored packages - tagparser and cpp-utilities) is installed by a Homebrew user. So, tried using -DCMAKE_STATIC_LINKER_FLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib" but the build failed. I guess, I not using the proper cmake option flags.

PS: The make VERBOSE=1 was indeed a bit more verbose on first run. 😀

[Martchus]

Linking statically is supported, however it is just used and tested under Windows. It should also work under macOS if all required dependencies are available as static libraries. See the notes regarding this. The library directory can be set via CMAKE_SYSTEM_LIBRARY_PATH. CMake should handle setting rpath automatically (behavior of CMake regarding rpath can also be controlled via variables). Don't hard code such flags. I also don't understand the intention behind setting those flags. You want static linkage and have the static libs you want to link against in directory /usr/local/opt/llvm/lib? But then it makes no sense to set rpath.

libc++ itself should not be big and linking statically might not make much sense on macOS.

Because I know nothing about macOS I can not tell you what makes sense here. Instead I would propose to check how other applications/libraries requiring C++11 features and Qt are distributed and I would just follow their way of doing it. An example would be mkvtoolnix which is (as far as I remember) available on macOS.

[Martchus]

I recently succeeded in compiling this library for MacOS X. There were some changes required to make this work. I have also updated the documentation (main README and documentation about build system variables).

From your error log I would say it can not even find the symbols of the standard library so there is something wrong with your build environment (and likely not the build script of this library).

This is the build configuration I used:

• using Clang under Linux as cross compiler with help of osxcross
• using libstdc++ from GCC 7.1.1 rather than libc++ (because the version of libc++ provided by MacOS X SDK 10.11 was too old)
• using CMake with wrapper and custom tool chain file to use compiler from osxcross
• using dynamic iconv from MacOS X SDK
• using static, cross compiled build of Qt 5
• no packages from Homebrew required

Build scripts for assembling this environment can be found in my PKGBUILDs repository.

This allowed me to build Syncthing Tray and Tag Editor using the following commands:

# get sources
cd $SOURCES
git clone https://github.com/Martchus/cpp-utilities.git c++utilities
git clone https://github.com/Martchus/qtutilities.git
git clone https://github.com/Martchus/subdirs.git
# for Syncthing Tray
git clone https://github.com/Martchus/syncthingtray.git
# for Tag Editor
git clone https://github.com/Martchus/tagparser.git
git clone https://github.com/Martchus/tageditor.git

# build Syncthing Tray
cd $SYNCTHING_TRAY_BUILD_DIR
/opt/osxcross/bin/x86_64-apple-darwin15-cmake \
    -DCMAKE_CXX_FLAGS='-std=c++14 -D__STRICT_ANSI__ -foc-use-gcc-libstdc++' \
    -DCMAKE_INSTALL_PREFIX:PATH=$PWD/install \
    -Diconv_DYNAMIC_LIB:FILEPATH=/opt/osxcross/SDK/MacOSX10.11.sdk/usr/lib/libiconv.2.tbd \
    -Diconv_DYNAMIC_INCLUDE_DIR=/opt/osxcross/SDK/MacOSX10.11.sdk/usr/include \
    -DENABLE_STATIC_LIBS:BOOL=ON \
    -DDISABLE_SHARED_LIBS:BOOL=ON \
    -DSTATIC_LINKAGE:BOOL=0N \
    -DENABLE_QT_TRANSLATIONS:BOOL=ON \
    -DBUILTIN_TRANSLATIONS:BOOL=ON \
    -DBUILTIN_ICON_THEMES:STRING='breeze;breeze-dark' \
    -DQT_LINKAGE=STATIC \
    $SOURCES/subdirs/syncthingtray && \
    make install -j4 VERBOSE=1

# build Tag Editor
cd $TAG_EDITOR_BUILD_DIR
/opt/osxcross/bin/x86_64-apple-darwin15-cmake \
    -DCMAKE_CXX_FLAGS='-std=c++14 -D__STRICT_ANSI__ -foc-use-gcc-libstdc++' \
    -DCMAKE_INSTALL_PREFIX:PATH=$PWD/install \
    -Diconv_DYNAMIC_LIB:FILEPATH=/opt/osxcross/SDK/MacOSX10.11.sdk/usr/lib/libiconv.2.tbd \
    -Diconv_DYNAMIC_INCLUDE_DIR=/opt/osxcross/SDK/MacOSX10.11.sdk/usr/include \
    -Dz_DYNAMIC_LIB:FILEPATH=/opt/osxcross/SDK/MacOSX10.11.sdk/usr/lib/libz.1.tbd \
    -Dz_DYNAMIC_INCLUDE_DIR=/opt/osxcross/SDK/MacOSX10.11.sdk/usr/include \
    -DENABLE_STATIC_LIBS:BOOL=ON \
    -DDISABLE_SHARED_LIBS:BOOL=ON \
    -DSTATIC_LINKAGE:BOOL=0N \
    -DENABLE_QT_TRANSLATIONS:BOOL=ON \
    -DBUILTIN_TRANSLATIONS:BOOL=ON \
    -DBUILTIN_ICON_THEMES:STRING='breeze;breeze-dark' \
    -DQT_LINKAGE=STATIC \
    -DWIDGETS_GUI:BOOL=ON \
    $SOURCES/subdirs/tageditor && \
    make install -j4 VERBOSE=1

However, I could not test whether the applications actually run.

Builds are available under https://martchus.no-ip.biz/repo/mac if you like to test.

[rakkesh]

@Martchus thanks for looking into this issue further. I have downloaded, and tested the app which you have provided, it crashed - https://gist.github.com/3606f9cee78ab08dd747ef34c9b4e44d#file-app_crash-log

Also, in the mean time I tried to get the cli version to build taking pointers from PKGBUILD repo but that failed too - https://gist.github.com/3606f9cee78ab08dd747ef34c9b4e44d probably that I don't have latest llvm installed at the moment.

[Martchus]

Another user had more success when ignoring the bundle and starting the executable directly. He claims that the tag editor at least shows up: https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/23 However, from the log I suspect your issue is differently. Does it instantly crash?

---

The compile error you're getting (ld: library not found for -l/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libiconv.2.tbd) looks like the library you specified does not exist. Additionally, CMake should not use -l for passing the library (but that maybe comes due to the fact that the library does not exists). So are you sure the library exists?

Note that this error is actually not too bad. It means that every unit of the c++utilities library could be compiled and only linking (the final step) failed. So your llvm could be recent enough.

BTW: I used llvm 4.0.1, so this version should definitely work.

[rakkesh]

Another user had more success when ignoring the bundle and starting the executable directly.

That is the first thing I had tried,

[macmini:~] % tageditor -h
Tag Editor, version 2.2.5-315.a3b8048
Linked against: C++ Utilities: 4.9.2-357.a40d6ca, Qt Utilities: 5.7.1-176.7c6483f, Tag Parser: 6.4.0-281.e9c9234, Qt Qml: 5.9.1, Qt Concurrent: 5.9.1, Qt Network: 5.9.1, Qt Widgets: 5.9.1, Qt Core: 5.9.1, Qt Svg: 5.9.1

Available arguments:
[ more information ]

Project website: https://github.com/Martchus/tageditor

[macmini:~] % ffprobe -hide_banner hits.mp3
Input #0, mp3, from 'hits.mp3':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    title           : 2000 hits
    encoder         : Lavf57.71.100
  Duration: 00:01:56.92, start: 0.025057, bitrate: 128 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s
    Metadata:
      encoder         : Lavc57.89

[macmini:~] % tageditor -g -n title -f hits.mp3
[1]    1909 abort      tageditor -e -n title -f hits.mp3

However, from the log I suspect your issue is differently. Does it instantly crash?

Yes, the app crashes immediately even before a Qt window opens. The app crash log seems to indicate that.

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libiconv.2.tbd does exist at the specified path.

[Martchus]

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libiconv.2.tbd does exist at the specified path.

Than the -l flag is a CMake bug. Maybe you can work around it by specifying the library differently:

-Diconv_DYNAMIC_LIB:STRING="-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib;-liconv"

The app crash log seems to indicate that.

The app crash log shows that the app crashes at a point where the main thread is doing some font rendering related stuff. This could also be after the GUI has shown up. However, the failing thread is not the main/GUI thread anyways. Not sure what the failing thread is supposed to do (likely a helper thread internally created by Qt).

So my build is broken somehow. Strange that on the system of the user from the Syncthing forums the GUI at least shows up.

---

Thanks for providing so much debug information. However, I don't think it will me allow to fix the issue(s).

As mentioned in the Syncthing forum, the only real solution to fix Mac related issues is that somebody with C++, CMake, Qt and Mac OS knowledge would work on them. I can only give a little bit assistance. The whole "try this, try that approach" is not very efficient and will hence not likely lead to a solution.

[rakkesh]

I was able to proceed with system iconv. The build now fails in tagparser. https://gist.github.com/9eb48f03b3078cd98a1550eaa0bb9ffb

[ 45%] Building CXX object CMakeFiles/tagparser.dir/opus/opusidentificationheader.cpp.o
/tmp/tageditor--tagparser-20170822-6518-1fc4dyt/tagparser-6.3.0/ogg/oggcontainer.cpp:298:9: error: call to 'getBytes' is ambiguous
        ConversionUtilities::BE::getBytes(0x4F70757354616773u, copyHelper.buffer());
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:146:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(int16 value, char *outputbuffer)
                                 ^
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:160:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(uint16 value, char *outputbuffer)
                                 ^
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:191:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(int32 value, char *outputbuffer)
                                 ^
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:209:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(uint32 value, char *outputbuffer)
                                 ^
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:227:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(int64 value, char *outputbuffer)
                                 ^
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:253:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(uint64 value, char *outputbuffer)
                                 ^
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:279:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(float32 value, char *outputbuffer)
                                 ^
/usr/local/Cellar/tageditor/2.2.4/libexec/vendor/include/c++utilities/conversion/./binaryconversionprivate.h:289:34: note: candidate function
CPP_UTILITIES_EXPORT inline void getBytes(float64 value, char *outputbuffer)
                                 ^
[ 47%] Building CXX object CMakeFiles/tagparser.dir/flac/flactooggmappingheader.cpp.o
[ 49%] Building CXX object CMakeFiles/tagparser.dir/flac/flacmetadata.cpp.o
1 error generated.
make[2]: *** [CMakeFiles/tagparser.dir/ogg/oggcontainer.cpp.o] Error 1

[Martchus]

From the line /tmp/tageditor--tagparser-20170822-6518-1fc4dyt/tagparser-6.3.0/ogg/oggcontainer.cpp:298:9: error: call to 'getBytes' is ambiguous I assume you use version 6.3.0 of tagparser.

I have already fixed that error on master. I would suggest building all parts (c++utilities, qtutilities, tagparser and tageditor) from master (to checkout, just copy & paste the commands in my comment above). I guess I only mentioned it in the Syncthing forum, but to make this compile I had to do a few adjustments (which have not been released yet).

[rakkesh]

I was able to finish writing a Homebrew formula [0] for tageditor with minimal steps but there is an issue relating to rpath still open (which should be handled by homebrew maintainers).

Thanks for your patience with this issue, I'll close it now.

[0] - the Homebrew formula is available here, https://gist.github.com/rakkesh/0b13b8fca5dd1d57d98537ef1dd2e0dd.

I was able to build a static binary with these options which you have mentioned -

  -DENABLE_STATIC_LIBS:BOOL=ON
  -DDISABLE_SHARED_LIBS:BOOL=ON

[Martchus]

Nice that it worked. I assume the resulting binary also actually works. Not sure what's wrong with my binaries, though. Maybe it should not use libstdc++ under Mac OS and rather upgrade to a more recent version of SDK.

From the Homebrew formula it is not clear which SDK you have been using, but I assume MacOSX10.12.sdk? Maybe I should try that instead of 10.11 which might allow me to use libc++ as well. With 10.11 I'm getting errors about missing headers (eg. initializer_list) and those header files are in fact missing in the SDK.

And thanks for providing a Homebrew formula. I'll add a link to it in the README. Maybe it can also be uploaded to upstream Homebrew repositories. It doesn't have GUI support yet, but it is a beginning.

[slhck]

@rakkesh Did you ever get this to work? I'm trying now with this formula under macOS 10.14:

class Tageditor < Formula
  desc "Tag editor for MP4/M4A/AAC, ID3, Vorbis, Opus, FLAC, Matroska"
  homepage "https://github.com/Martchus/tageditor"
  url "https://github.com/Martchus/tageditor/archive/v3.2.0.tar.gz"
  sha256 "195781362419591f8e88f636a0fc3676389718ebc6ae96014d27a3123b2b8f0f"

  depends_on "cmake" => :build
  depends_on "cppunit" => :build
  depends_on "openssl"

  resource "cpp-utilities" do
    url "https://github.com/Martchus/cpp-utilities.git"
  end

  resource "tagparser" do
    url "https://github.com/Martchus/tagparser.git"
  end

  def install
    resource("cpp-utilities").stage do
      args = std_cmake_args + %W[
        -DCMAKE_CXX_FLAGS="-std=c++1z"
        -DENABLE_THREAD_LOCAL=OFF
        -DCMAKE_INSTALL_PREFIX:PATH=#{libexec}/vendor
      ]

      mkdir "build" do
        system "cmake", "..", *args
        system "make", "install"
      end
    end

    resource("tagparser").stage do
      args = std_cmake_args + %W[
        -DCMAKE_CXX_FLAGS="-std=c++1z"
        -DENABLE_THREAD_LOCAL=OFF
        -DCMAKE_INSTALL_PREFIX:PATH=#{libexec}/vendor
        -Dc++utilities_DIR=#{libexec}/vendor/share/cmake
      ]

      mkdir "build" do
        system "cmake", "..", *args
        system "make", "install"
      end
    end

    args = std_cmake_args + %W[
      -DCMAKE_CXX_FLAGS="-std=c++1z"
      -DWIDGETS_GUI=OFF
      -DQUICK_GUI=OFF
      -DENABLE_THREAD_LOCAL=OFF
      -DCMAKE_PREFIX_PATH=#{libexec}/vendor
      -DCMAKE_INSTALL_PREFIX:PATH=#{prefix}
    ]

    mkdir "build" do
      system "cmake", "..", *args
      system "make", "install"
    end
  end

  test do
    system "true"
  end
end

and compilation succeeds, but when calling tageditor I get:

➜ tageditor
dyld: Library not loaded: @rpath/libtagparser.8.dylib
  Referenced from: /usr/local/bin/tageditor
  Reason: image not found
[1]    61231 abort      tageditor

[Martchus]

Seems like it could link against that library but can not find it at runtime. If it was Linux I'd say read man ld.so. I'm sure Mac OS provides similar documentation about library search paths.

[slhck]

Yes, that's what macOS uses, but I'm fairly certain it relates to what was previously said about "an issue relating to rpath still open". The load path for dynamically linked libraries has to include the built libtagparser. I'm sure this can be worked around by manually setting the path in the current shell, but it shouldn't be this way, and unfortunately I'm way too inexperienced with Homebrew's build system to know how to solve this…