Comments (29)
@benjioh5 I personally plan to look into supporting clang when it could be done ^^
from imhex.
@WerWolv After looking over @nmantani's comment and making the suggested tweak, ImHex does indeed build as expected on MacOS. As per #93, the app does look a little weird on Retina displays, but I'm working a fix for that too.
I've uploaded the patches as well as a script to apply them for anyone that would like them here.
from imhex.
As of 310059f, build on macOS is officially supported.
from imhex.
I have fixed the problem with concepts
in this way:
brew install gcc
cd ImHex/build
cmake .. -DCMAKE_C_COMPILER=/usr/local/bin/gcc-10 -DCMAKE_CXX_COMPILER=/usr/local/bin/g++-10
but I have a new problem:
/Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:187:59: error: no matching function for call to 'max(u64&, size_t&)'
187 | unionSize = std::max(memberSize, unionSize);
| ^
all log:
make
Scanning dependencies of target ImHex
[ 2%] Building CXX object CMakeFiles/ImHex.dir/source/main.cpp.o
[ 5%] Building CXX object CMakeFiles/ImHex.dir/source/window.cpp.o
[ 8%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/utils.cpp.o
[ 11%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/crypto.cpp.o
[ 13%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/patches.cpp.o
[ 16%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/math_evaluator.cpp.o
[ 19%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/project_file_handler.cpp.o
[ 22%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/loader_script_handler.cpp.o
[ 25%] Building CXX object CMakeFiles/ImHex.dir/source/lang/preprocessor.cpp.o
[ 27%] Building CXX object CMakeFiles/ImHex.dir/source/lang/lexer.cpp.o
[ 30%] Building CXX object CMakeFiles/ImHex.dir/source/lang/parser.cpp.o
[ 33%] Building CXX object CMakeFiles/ImHex.dir/source/lang/validator.cpp.o
[ 36%] Building CXX object CMakeFiles/ImHex.dir/source/lang/evaluator.cpp.o
/Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp: In member function 'std::pair<hex::lang::PatternData*, long unsigned int> hex::lang::Evaluator::createUnionPattern(hex::lang::ASTNodeVariableDecl*, u64)':
/Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:187:59: error: no matching function for call to 'max(u64&, size_t&)'
187 | unionSize = std::max(memberSize, unionSize);
| ^
In file included from /usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/specfun.h:45,
from /usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/cmath:1927,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/providers/provider.hpp:5,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/lang/evaluator.hpp:5,
from /Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:1:
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algobase.h:254:5: note: candidate: 'template<class _Tp> constexpr const _Tp& std::max(const _Tp&, const _Tp&)'
254 | max(const _Tp& __a, const _Tp& __b)
| ^~~
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algobase.h:254:5: note: template argument deduction/substitution failed:
/Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:187:59: note: deduced conflicting types for parameter 'const _Tp' ('long long unsigned int' and 'size_t' {aka 'long unsigned int'})
187 | unionSize = std::max(memberSize, unionSize);
| ^
In file included from /usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/specfun.h:45,
from /usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/cmath:1927,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/providers/provider.hpp:5,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/lang/evaluator.hpp:5,
from /Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:1:
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algobase.h:300:5: note: candidate: 'template<class _Tp, class _Compare> constexpr const _Tp& std::max(const _Tp&, const _Tp&, _Compare)'
300 | max(const _Tp& __a, const _Tp& __b, _Compare __comp)
| ^~~
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algobase.h:300:5: note: template argument deduction/substitution failed:
/Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:187:59: note: deduced conflicting types for parameter 'const _Tp' ('long long unsigned int' and 'size_t' {aka 'long unsigned int'})
187 | unionSize = std::max(memberSize, unionSize);
| ^
In file included from /usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/string:52,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/providers/provider.hpp:9,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/lang/evaluator.hpp:5,
from /Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:1:
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algo.h:3480:5: note: candidate: 'template<class _Tp> constexpr _Tp std::max(std::initializer_list<_Tp>)'
3480 | max(initializer_list<_Tp> __l)
| ^~~
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algo.h:3480:5: note: template argument deduction/substitution failed:
/Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:187:59: note: mismatched types 'std::initializer_list<_Tp>' and 'long long unsigned int'
187 | unionSize = std::max(memberSize, unionSize);
| ^
In file included from /usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/string:52,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/providers/provider.hpp:9,
from /Users/dmitriysmotrov/space/dsxack/ImHex/include/lang/evaluator.hpp:5,
from /Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:1:
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algo.h:3486:5: note: candidate: 'template<class _Tp, class _Compare> constexpr _Tp std::max(std::initializer_list<_Tp>, _Compare)'
3486 | max(initializer_list<_Tp> __l, _Compare __comp)
| ^~~
/usr/local/Cellar/gcc/10.2.0/include/c++/10.2.0/bits/stl_algo.h:3486:5: note: template argument deduction/substitution failed:
/Users/dmitriysmotrov/space/dsxack/ImHex/source/lang/evaluator.cpp:187:59: note: mismatched types 'std::initializer_list<_Tp>' and 'long long unsigned int'
187 | unionSize = std::max(memberSize, unionSize);
| ^
make[2]: *** [CMakeFiles/ImHex.dir/source/lang/evaluator.cpp.o] Error 1
make[1]: *** [CMakeFiles/ImHex.dir/all] Error 2
make: *** [all] Error 2
from imhex.
@dsxack Oh that's one place I forgot. You can fix it by explicitly casting unionSize to and u64. I'll fix that soon.
@WerWolv thank you, I did that, but have a new problem:
make
[ 2%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_hexeditor.cpp.o
/Users/dmitriysmotrov/space/dsxack/ImHex/source/views/view_hexeditor.cpp: In member function 'bool hex::ViewHexEditor::loadFromFile(std::string, std::vector<unsigned char>&)':
/Users/dmitriysmotrov/space/dsxack/ImHex/source/views/view_hexeditor.cpp:496:23: error: 'ftello64' was not declared in this scope; did you mean 'ftello'?
496 | size_t size = ftello64(file);
| ^~~~~~~~
| ftello
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_hexeditor.cpp.o] Error 1
make[1]: *** [CMakeFiles/ImHex.dir/all] Error 2
make: *** [all] Error 2
I did use ftello
instead ftello64
and this goes further but I have the same problem with lglfw
:
ld: library not found for -lglfw
I go to fix it now, I think it is my local problem
from imhex.
@WerWolv I've tried compiling ImHex using four different versions of LLVM, every single one throws an error of one kind or another. The only way I've been able to get a successful build is by using GCC 10, which will successfully build ImHex and then lead to a linking failure.
I've narrowed the actual issue down to the symbol __cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
, which is apparently part of the CXX11 ABI. This is apparently a common enough issue encountered when trying to cross-compile Python extensions for multiple OS's (discussion of which are where I found the descriptions and solutions to the issue). The most helpful-seeming thing I found was this explanation of what's causing the issue - a difference in the way that GCC and clang handle namespace changes.
As near as I can tell, there are two options - either apply the fix / patch detailed in the link so that GCC can be used to compile or figure a way to use just LLVM. I'd imagine that the ideal solution would be to get ImHex to compile exclusively with LLVM / clang, and if I'm understanding correctly that's just a matter of forcing LLVM to use the C++20 standard instead of the default of... not that. I haven't been able to get cmake or llvm to actually do that, so I'm at a bit of an impasse.
Hopefully what I've turned up is useful enough that someone else can get us over the finish line with it.
from imhex.
Latest commit fixes some of the issues with building on MacOS. If possible, please test it with a appropriate C++20 compiler.
from imhex.
Latest commit fixes some of the issues with building on MacOS. If possible, please test it with a appropriate C++20 compiler.
@WerWolv Total coincidence, but I was trying to get ImHex to compile last night and left everything up to come back to it this morning. There are fewer errors with the new changes, but it still fails to compile. I made a gist of the output here.
I did have to add some environment variables so that cmake would correctly find all the packages it was looking for, but all the dependencies are available via Homebrew. The extra environment variables I used are:
export CC=/usr/local/opt/llvm/bin/clang
export CPP=/usr/local/opt/llvm/bin/clang++
export PATH="/usr/local/opt/llvm/bin:$PATH"
export CPPFLAGS="-I/usr/local/opt/llvm/include -I/usr/local/opt/openssl/include"
export LDFLAGS="-L/usr/local/opt/openssl/lib -L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig"
Oh! And in case it's relevant, I also have the OpenSSL / libcrypto libraries symlinked to /usr/local/lib
thusly:
for lib in $(ls /usr/local/Cellar/openssl\@1.1/1.1.1h/lib/lib*); do ln -s $lib /usr/local/lib/; done
Does this help at all?
from imhex.
Okay, look like it's all on Apple / clang now. All those errors are just XXXX is unavailable: introduced in macOS 10.15
. Once clang updates, this should work then :)
from imhex.
@the-wondersmith I did same thing on my environment. [email protected] or libressl works fine now.
this is my fish setting.
# apple llvm to homebrew llvm
set -gx LDFLAGS "-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
set -gx CPPFLAGS "-I/usr/local/opt/llvm/include"
set -g fish_user_paths "/usr/local/opt/llvm/bin" $fish_user_paths
# add [email protected]
#set -gx LDFLAGS "-L/usr/local/opt/[email protected]/lib"
#set -gx CPPFLAGS "-I/usr/local/opt/[email protected]/include"
#set -gx PKG_CONFIG_PATH "/usr/local/opt/[email protected]/lib/pkgconfig"
# add libressl
set -gx LDFLAGS "-L/usr/local/opt/libressl/lib" $LDFLAGS
set -gx CPPFLAGS "-I/usr/local/opt/libressl/include" $CPPFLAGS
set -g fish_user_paths "/usr/local/opt/libressl/bin" $fish_user_paths
But still C++20 concepts library makes build fail.
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/helpers/crypto.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
'concepts' file not found
#include <concepts>
from imhex.
@the-wondersmith I did same thing on my environment. [email protected] or libressl works fine now.
this is my fish setting.
# apple llvm to homebrew llvm set -gx LDFLAGS "-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib" set -gx CPPFLAGS "-I/usr/local/opt/llvm/include" set -g fish_user_paths "/usr/local/opt/llvm/bin" $fish_user_paths # add [email protected] #set -gx LDFLAGS "-L/usr/local/opt/[email protected]/lib" #set -gx CPPFLAGS "-I/usr/local/opt/[email protected]/include" #set -gx PKG_CONFIG_PATH "/usr/local/opt/[email protected]/lib/pkgconfig" # add libressl set -gx LDFLAGS "-L/usr/local/opt/libressl/lib" $LDFLAGS set -gx CPPFLAGS "-I/usr/local/opt/libressl/include" $CPPFLAGS set -g fish_user_paths "/usr/local/opt/libressl/bin" $fish_user_paths
But still C++20 concepts library makes build fail.
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/helpers/crypto.cpp:3: /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error: 'concepts' file not found #include <concepts>
Yeah, I just tracked that down. Looking for a work around right now. This seems to be pretty informative, but I'm still making my way through it...
from imhex.
@the-wondersmith how about using preprocessor on specific code? msgpack-c project works around this way.
replace line 49
#include "adaptor/cpp17/optional.hpp"
with this// XCode 9.3 workaround
#if defined(__has_include) && __has_include()
#include "adaptor/cpp17/optional.hpp"
#endif // __has_include()
from imhex.
@the-wondersmith how about using preprocessor on specific code? msgpack-c project works around this way.
replace line 49
#include "adaptor/cpp17/optional.hpp"
with this
// XCode 9.3 workaround
#if defined(__has_include) && __has_include()
#include "adaptor/cpp17/optional.hpp"
#endif // __has_include()
I'm 100% game to test it if you tell me how / where to apply the fix. Full disclosure, I'm primarily a Python programmer. I can do C / C++ in a pinch if I have to, but it's very much not my programming "mother tongue" so to speak 😅
from imhex.
@dsxack I've reached the same point of progress you did, though I had to fiddle with the flags passed to cmake.
It seems like we're pretty close. Any idea of how to get the build to complete?
from imhex.
@dsxack Oh that's one place I forgot. You can fix it by explicitly casting unionSize
to and u64
. I'll fix that soon.
from imhex.
@dsxack Oh that's one place I forgot. You can fix it by explicitly casting
unionSize
to andu64
. I'll fix that soon.
That did it. Got a new error though...
MacBook-Pro:build user$ make -j
Scanning dependencies of target ImHex
[ 2%] Building CXX object CMakeFiles/ImHex.dir/source/lang/evaluator.cpp.o
[ 5%] Linking CXX executable ImHex
ld: library not found for -lglfw
collect2: error: ld returned 1 exit status
make[2]: *** [ImHex] Error 1
make[1]: *** [CMakeFiles/ImHex.dir/all] Error 2
make: *** [all] Error 2
from imhex.
Looks like you just don't have the right libraries installed now. You need glfw for starters. And a bunch of other ones that are mentioned in the readme
from imhex.
Looks like you just don't have the right libraries installed now. You need glfw for starters. And a bunch of other ones that are mentioned in the readme
It looks that way, but that's not the case. I'm sure it's probably just a local configuration thing, but I fixed it by explicitly providing the requisite paths thusly -
cmake .. -DCMAKE_C_COMPILER=/usr/local/bin/gcc-10 -DCMAKE_CXX_COMPILER=/usr/local/bin/g++-10 -DCMAKE_C_FLAGS="-I/usr/local/Cellar/[email protected]/1.1.1h/include -I/usr/local/Cellar/llvm/11.0.0/include" -DCMAKE_CXX_FLAGS="-I/usr/local/Cellar/[email protected]/1.1.1h/include -I/usr/local/Cellar/llvm/11.0.0/include" -DCMAKE_EXE_LINKER_FLAGS="-L/usr/local/opt/openssl/lib -L/usr/local/Cellar/glfw/3.3.2/lib -L/usr/local/opt/llvm/lib -L/usr/local/Cellar/libmagic/5.39/lib -L/usr/local/Cellar/capstone/4.0.2/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
Everything builds now, but I'm hitting a linking error -
[100%] Linking CXX executable ImHex
Undefined symbols for architecture x86_64:
"__ZN4llvm8demangleERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE", referenced from:
__ZN3hex9ViewTools13drawDemanglerEv in view_tools.cpp.o
__ZN3hex11ViewStrings23createStringContextMenuERKNS_11FoundStringE in view_strings.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [ImHex] Error 1
make[1]: *** [CMakeFiles/ImHex.dir/all] Error 2
make: *** [all] Error 2
I've updated the gist I made with the full output, if that's helpful
from imhex.
It can't find llvm::demangle
now. Make sure you have up-to-date llvm-libs installed. That function can be found in libLLVMDemangle
, possible requiring v11.0.0 since that's the one I'm using
from imhex.
Now I have the same problem which have @the-wondersmith
gcc that installed by HomeBrew:
make
[ 2%] Linking CXX executable ImHex
ld: warning: dylib (/usr/local/Cellar/glfw/3.3.2/lib/libglfw.dylib) was built for newer macOS version (11.0) than being linked (10.16)
ld: warning: dylib (/usr/local/Cellar/[email protected]/1.1.1h/lib/libcrypto.dylib) was built for newer macOS version (11.0) than being linked (10.16)
ld: warning: dylib (/usr/local/Cellar/capstone/4.0.2/lib/libcapstone.dylib) was built for newer macOS version (11.0) than being linked (10.16)
ld: warning: dylib (/usr/local/Cellar/[email protected]/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/libpython3.8.dylib) was built for newer macOS version (11.0) than being linked (10.16)
ld: warning: dylib (/usr/local/opt/llvm/lib/libunwind.dylib) was built for newer macOS version (11.0) than being linked (10.16)
ld: warning: dylib (/usr/local/opt/llvm/lib/libunwind.dylib) was built for newer macOS version (11.0) than being linked (10.16)
Undefined symbols for architecture x86_64:
"__ZN4llvm8demangleERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE", referenced from:
__ZN3hex9ViewTools13drawDemanglerEv in view_tools.cpp.o
__ZN3hex11ViewStrings23createStringContextMenuERKNS_11FoundStringE in view_strings.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [ImHex] Error 1
make[1]: *** [CMakeFiles/ImHex.dir/all] Error 2
make: *** [all] Error 2
gcc that installed by MacPorts:
make
[ 2%] Linking CXX executable ImHex
Undefined symbols for architecture x86_64:
"__ZN4llvm8demangleERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE", referenced from:
__ZN3hex9ViewTools13drawDemanglerEv in view_tools.cpp.o
__ZN3hex11ViewStrings23createStringContextMenuERKNS_11FoundStringE in view_strings.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [ImHex] Error 1
make[1]: *** [CMakeFiles/ImHex.dir/all] Error 2
make: *** [all] Error 2
Now I try to fix that with advice that @WerWolv given: updating llvm-libs
from imhex.
@WerWolv @dsxack This seems relevant, but I'm not familiar enough with the actual source (or C++ for that matter) to tell if it actually is or how to implement the applicable fix if it is.
from imhex.
Yeah, it's simply a linker error caused by the linker not finding the implementation of a function that was used in ImHex. That function in this case is std::string llvm::demangle(std::string)
, most likely caused by them not having the right version of llvm installed. It can find libLLVMDemangle but not that function.
from imhex.
@WerWolv @dsxack It looks like (from reading over this) some kind of oversight or omission in the llvm package from Homebrew, at least as compared to options that were apparently previously available for the Homebrew llvm package. I'm going to try compiling and installing llvm11 from source and see if that fixes it.
from imhex.
@the-wondersmith Thanks for the link you provide, I tried following:
> echo __ZN4llvm8demangleERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE | c++filt
llvm::demangle(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
> nm /usr/local/opt/llvm/lib/libLLVM.dylib | grep -e "llvm.demangle"
0000000000002a80 T __ZN4llvm8demangleERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEE
> echo __ZN4llvm8demangleERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEE | c++filt
llvm::demangle(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
I guess build LLVM using g++-10 may get this problem fixed. Or we can let g++-10 compile the symbols in the clang style. Another clever way may exist is to translate the g++-10 style symbols (std::__cxx11
) to clang style symbols (std::__1
) in the ImHex object files.
from imhex.
FreeBSD also has the same issue of undefined symbol error with libLLVMDemangle.a because FreeBSD LLVM packages are built with Clang and ImHex needs GCC 10 to build it.
from imhex.
@nmantani I saw your posting about the patches you made to the codebase to get ImHex to compile on FreeBSD. That's awesome, by the way.
Do you have any idea if the same (or possibly similar) patches will solve the issues we've been experiencing on MacOS ?
from imhex.
@WerWolv @nmantani My curiosity got the better of me. Turns out, the answer is "sort of" I pulled the absolute latest revision, then applied your patches. I had to manually fiddle with the patches to CMakeLists.txt
, but it all seemed fine. I issued the configuration command as:
cmake -DCMAKE_C_COMPILER=$CCGCC -DCMAKE_CXX_COMPILER=$CPPGCC \
-DCMAKE_C_FLAGS="-I/usr/local/Cellar/[email protected]/1.1.1h/include -I/usr/local/llvm11/include -I/usr/local/Cellar/freetype/2.10.4/include -I/usr/local/Cellar/freetype/2.10.4/include/freetype2" \
-DCMAKE_CXX_FLAGS="-std=c++14 -std=c++17 -std=gnu++2a -I/usr/local/Cellar/[email protected]/1.1.1h/include -I/usr/local/Cellar/freetype/2.10.4/include -I/usr/local/Cellar/freetype/2.10.4/include/freetype2" \
-DCMAKE_EXE_LINKER_FLAGS="-L/usr/local/opt/openssl/lib -L/usr/local/Cellar/glfw/3.3.2/lib -L/usr/local/Cellar/libmagic/5.39/lib -L/usr/local/Cellar/capstone/4.0.2/lib -L/usr/local/opt/llvm/lib -L/usr/local/Cellar/freetype/2.10.4/lib -Wl,-rpath,/usr/local/opt/llvm/lib" ..
Which got ImHex to compile just fine (same as before), but now the missing symbols are different:
[ 97%] Building CXX object CMakeFiles/imhex.dir/libs/ImGui/source/TextEditor.cpp.o
[100%] Linking CXX executable imhex
Undefined symbols for architecture x86_64:
"_FT_Add_Default_Modules", referenced from:
__ZN13ImGuiFreeType14BuildFontAtlasEP11ImFontAtlasj in imgui_freetype.cpp.o
"_FT_Done_Face", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont9CloseFontEv in imgui_freetype.cpp.o
"_FT_Done_Library", referenced from:
__ZN13ImGuiFreeType14BuildFontAtlasEP11ImFontAtlasj in imgui_freetype.cpp.o
"_FT_Get_Char_Index", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont9LoadGlyphEj in imgui_freetype.cpp.o
__Z28ImFontAtlasBuildWithFreeTypeP14FT_LibraryRec_P11ImFontAtlasj in imgui_freetype.cpp.o
"_FT_GlyphSlot_Embolden", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont9LoadGlyphEj in imgui_freetype.cpp.o
"_FT_GlyphSlot_Oblique", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont9LoadGlyphEj in imgui_freetype.cpp.o
"_FT_Load_Glyph", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont9LoadGlyphEj in imgui_freetype.cpp.o
"_FT_New_Library", referenced from:
__ZN13ImGuiFreeType14BuildFontAtlasEP11ImFontAtlasj in imgui_freetype.cpp.o
"_FT_New_Memory_Face", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont8InitFontEP14FT_LibraryRec_RK12ImFontConfigj in imgui_freetype.cpp.o
"_FT_Render_Glyph", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont21RenderGlyphAndGetInfoEPNS_9GlyphInfoE in imgui_freetype.cpp.o
"_FT_Request_Size", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont14SetPixelHeightEi in imgui_freetype.cpp.o
"_FT_Select_Charmap", referenced from:
__ZN12_GLOBAL__N_112FreeTypeFont8InitFontEP14FT_LibraryRec_RK12ImFontConfigj in imgui_freetype.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [imhex] Error 1
make[1]: *** [CMakeFiles/imhex.dir/all] Error 2
make: *** [all] Error 2
Thoughts?
from imhex.
@the-wondersmith Though I did not see this error on FreeBSD, it seems that the missing symbols are FreeType functions. Adding find_package(Freetype REQUIRED) line and adding ${FREETYPE_LIBRARIES} to target_link_libraries() in CMakeLists.txt fix the error?
This Q&A has an example of CMakeLists.txt.
https://stackoverflow.com/questions/23888274/linking-freetype-with-cmake
from imhex.
ok, so... we have the GUI issue on mac (plenty of people have their own patches, and I pushed PR #92 already (can build with latest clang and gcc10, at least), so won't be talking about compiling ImHex here).
Here's something I posted on the free type PR (low audience because it was after it was closed), and is relevant for this:
I've tried that, but it didn't work too well.
Changing font scale "works" but the UI is still drawn as if the font is large. I can, though, hack it like this:diff --git a/source/window.cpp b/source/window.cpp index f30f1ee..ed99407 100644 --- a/source/window.cpp +++ b/source/window.cpp @@ -223,7 +223,8 @@ namespace hex { glfwGetMonitorContentScale(monitor, &xscale, &yscale); // In case the horizontal and vertical scale are different, fall b ack on the average - this->m_globalScale = this->m_fontScale = std::midpoint(xscale, ys cale); + //this->m_globalScale = this->m_fontScale = std::midpoint(xscale, yscale); + this->m_globalScale = 1.0;
This is... obviously wrong. But I'm not familiar with the codebase, maybe someone else can figure out what the correct fix is with this info.
Thank you,
Filipe
io.DisplayFramebufferScale
is 2 on both dimensions
The window has these properties when running: w: 1440, h: 855, display_w: 2880, display_h: 1710
The patch above works, but is probably not ideal?
Though it does seem like we're scaling more than once, so setting one of the scales to 1 might help.
from imhex.
Related Issues (20)
- [Bug] Double-free on exit in font manager plugin with custom font
- [Bug] Window scaling is not updated HOT 1
- [Bug] Crash on startup HOT 2
- [Bug] Existing bookmarks don't update when the base address is changed
- [Bug] Using #pragma bitfield_order crashes the application
- [Bug] placement doesn't work in if outside of a struct HOT 3
- [Bug] Hex Editor scroll don't work properly using "Jump To" HOT 1
- [Bug] UI doesn't start without raising an error on Ubuntu
- [Bug] File dialog is no longer parented properly on Linux X11 HOT 1
- [Bug] find_sequence can fail if based_address is not zero.
- [Feature] Highlight multiple paragraphs with the same color when creating a bookmark
- [Bug] Base64 provider does not work on files with newlines HOT 3
- [Bug] Graphical corruption and mouse clicking incorrect on Windows 10 HOT 2
- [Bug] Chinese(Simplified) got doubled in the language list
- [Bug] Window becomes completely unresponsive after resizing HOT 12
- [Feature]
- [Feature] Enhance data processing feature
- [Bug] "Edit the hex" achievement doesn't unlock HOT 2
- [Bug] Context menus fail to close
- [Bug] Byte-by-byte diffing view not properly displaying adding/removing of data at the end
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from imhex.