Misc. bug: Installing llama.cpp on macOS through lemonade-idk

[Geramy]

Name and Version

Hello it seems the macOS file size for llama.cpp has changed from 39MB to 8MB after version b8828

What was the reason for this? I believe it has caused issues in lemonade-sdk.
Please let me know if there where any important changes that we must implement specifically for macOS/metal in order to install the latest llama.cpp and any required runtime binaries that may have been removed, (only guessing) or perhaps by accident. Thanks!

This stops us from upgrading to the "LATEST" but we can upgrade to 8828.

lemonade-sdk/lemonade#1669

Operating systems

Mac

Which llama.cpp modules do you know to be affected?

llama-server

Command line

Problem description & steps to reproduce

install latest lemonade and manually change backend, stop the service and restart it after changing backend version code to the newest. File path is accessible here with instructions.

lemonade-sdk/lemonade#1675

First Bad Commit

No response

Relevant log output

Logs

[Geramy]

Prior b8766 worked.

[ggerganov]

See #21936

[Geramy]

=== reason ===
{'codes': '0x0000000000000001, 0x0000000000000000', 'rawCodes': [1, 0], 'type': 'EXC_BAD_ACCESS', 'signal': 'SIGSEGV', 'subtype': 'KERN_INVALID_ADDRESS at 0x0000000000000000'}

=== crashed thread stack ===
  libsystem_platform.dylib         _platform_strlen
  libc++.1.dylib                   std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::insert(unsigned long, char const*)
  libllama-common.0.0.8884.dylib   fs_get_cache_directory()
  libllama-common.0.0.8884.dylib   hf_cache::migrate_old_cache_to_hf_cache(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, bool)
  libllama-common.0.0.8884.dylib   common_params_parse(int, char**, common_params&, llama_example, void (*)(int, char**))
  llama-server                     main
  dyld                             start
geramyloveless@Geramys-MacBook-Pro-2 lemonade % 

[Geramy]

It seems that llama is not handling when the env variable for HOME is unset.

EXC_BAD_ACCESS (SIGSEGV) at 0x0
  _platform_strlen
  std::string::insert
  fs_get_cache_directory()            ← NULL returned from somewhere
  hf_cache::migrate_old_cache_to_hf_cache()
  common_params_parse()
  main

When HOME isn't set, getenv returns NULL.

=== common/common.cpp lines 970-975 at tag b8884 ===
        }
#elif defined(__APPLE__)
        cache_directory = std::getenv("HOME") + std::string("/Library/Caches/"); -> BUG WHEN HOME IS NULL
#elif defined(_WIN32)
        cache_directory = std::getenv("LOCALAPPDATA");
#elif defined(__EMSCRIPTEN__)

=== direct URL ===
https://github.com/ggml-org/llama.cpp/blob/b8884/common/common.cpp#L973

[Geramy]

I'll submit a PR.