I’m a couple weeks into my Haiku journey now, and starting to get the hang of things a little more. Running a nightly build of the 64bit version (largely because I didn’t see much in the old BeOS software that sounded necessary to my purposes), I’ve been toying with trying to get my favorite MUD client compiling on Haiku: Mudlet
So far, it seems I’m making some progress. Most of the requirements cmake asks for have been found by simply making sure to install the dev version. However, YAJL is turning out to be a problem.
Specifically, despite installing the YAJL dev packages, I get:
CMake Error at /boot/system/data/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find YAJL (missing: YAJL_LIBRARIES)
Call Stack (most recent call first):
/boot/system/data/cmake/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
cmake/FindYAJL.cmake:77 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
3rdparty/lua_yajl/CMakeLists.txt:4 (FIND_PACKAGE)
– Configuring incomplete, errors occurred!
See also “/boot/home/Mudlet/build/CMakeFiles/CMakeOutput.log”.
I’ve tried some less package intensive clients like TinTin (only requires zlib, pcre and gnutls), but keep running into errors when trying to find sockets - thus stopping those compile efforts short when a function tries to call for any sort of connectivity feature.
My C++ is rusty, having not touched it in almost two decades before now, but I’m using this opportunity as an experiement to get myself back up to speed enough to at least compile/port existing open-source software. Any insight as to where I need to look for help with dependencies would be appreciated. I’ve installed almost every dev package I can find in the Depot at this point.
About yajl:
Their FindYAJL.cmake provided in the source tarball (tarbomb, yeah!) they have hardcoded paths for the headers and for the libs.
Just open the “/cmake/FindYAJL.cmake” file, and add this line to the “FIND_PATH(YAJL_INCLUDE_DIR yajl/yajl_version.h” section (after the last /opt/ in that section in a new line):
/boot/system/develop/headers
And add this to the “FIND_LIBRARY(YAJL_LIBRARY_RELEASE” (after the last /opt line, in a new line, ofc):
/boot/system/develop/lib
And just try again.
Seems to working on x86_64.
1 Like
So, what did you do to get it to compile properly? I’m still running into an error when it tries to find Sockets. Got past the YAJL problem, and make didn’t run into any compile-stopping errors, but when I get to the compile step itself I’m stopped about 70% through when it tries to find sockets.
As stated previously, I’m VERY rusty on my C++,but this screenshot has emboldened my resolve. Mudlet is a great client, and seeing it running on Haiku is a thing of beauty. I’m running the x86_64 version, because I believe it best represents what Haiku COULD be.
I understand the nostalgic desire to keep BeOS compatibility, but in today’s computing world those apps just don’t seem worth the trouble when the OS itself could be so much more.
I habe absolutely no idea, what’s wrong on your side.
Which trouble? I rarely hear the devs complaining about the BeOS support. Please show us how it is creating trouble? We do have a 64 bit version, why call it a “could be”? It is part of what Haiku is already. Now go annoy app developers to get their app to run there, or port/write your own apps. On the OS side, 64 bit is a long solved problem.
@extrowerk :Thank you for the haikuporter recipe. That worked beautifully. I’m not sure what exactly my issues were with trying to compile it myself other than my own lacking knowledge in the area. Clearly some studying is required if I’m going to try to port apps!
@PulkoMandy : I believe I mispoke. I don’t find an issue with the 64bit version at all. When I said ‘could be’, what I meant simply was that as an end-user looking in I see the 64bit version as Haiku being its own modern interpretation of the BeOS method, while the hybrid version looks like a confusing reason to maintain a version with old architecture in order to run old apps from an old operating system.
That is, however, just a novice observation from the outside. I haven’t nearly the documentation or experience to evaluate how the multiple versioning might be impacting development as a whole, or reception in the wider audience.
In retrospect, I can see where such a comment would have been poorly taken and apologize for the clumsy wording.
