Hi Johannes,
I looked through your pad and noticed that you removed Ada support. Since you already have GCC 7.3 on your system you could install the GNAT Community 2018 version which also uses GCC 7.3. Both requirements to build the toolchain with Ada support should be possible
I'll try this out in case it helps with the error I'm getting ("cannot find libstdc++..") and report back on the etherpad, thank you!
Hi John,
(For those who don't know, TuneTracker is the premier showcase ap
Thanks for the kind words. We used to have a reputation as not only being more userfriendly than competitors, but also rock solid... With Genode I'm hoping we return there :-)
I have come to the exact same conclusion myself. Genode's design is very elegant (IMHO), the team is highly professional, and although it is still evolving, the platform is pretty mature at this point. All in all, I think it is the best bet going forward for an open-source, trustworthy computing base.
Concur.. Almost done reading genode_18.05.pdf; whenever I'm done reading a few pages I start day dreaming about how to apply all the great concepts, then I visualize a strategy for creating a "libhaiku.so" port to facilitate porting.. Then I get back the urge to tackle the dang GCC compiler again, hoping to succeed if I try one more time *g*.
I'm probably getting ahead of myself here, but when thinking about the future of TTS apps on Genode I believe much of the work will have to go in re-creating the BFS filesystem, at least feature wise (file attributes and indexing especially) -- BFS of course has little support outside of Haiku -- I think I've only heard of a some sort of read-only BFS fs in a linux distro once -- yet it is central to how our apps function. Many of our competitors resort to storing album/title/other metadata in an SQL-server database (!) running on a second (!) computer to be purchased separately. Life is much simplier for us and our clients in that respect.
One thing that occured to me, reading about the powerful mechanisms for delegation in Genode, is that a special purpose component/process could sit "in between" the vfs component and my app/components, so as to intercept read/write file system calls. The idea would be to re-route some of the calls: the read/write's to the plain "body" of the file would be sent to ext2 (or whichever) as normal; however, the ReadAttr()/WriteAttr() calls would be handled with custom code, to indeed store and retrieve attribute contents, and to maintain consistency of their indexing; there would be a guarantee of consistency (provided the "in between" component is correct) since it would be impossible to alter the filesystem without the in-between snopping on it. Just a raw thought at this point, I did not yet create an XML 'policy' file about that or anything yet, let alone any code.
Maybe actually doing a full-fledged port of BFS would be a better idea. Or I've heard there is /some/ support for attributes in ext2/ext3 ..etc but attributes are untyped (would have to understand the significance of that) and limited to 64KB in size (this one would probably not be a problem).
Others may be able to help you with the build system, but it might be easier to set up a multi-OS environment using virtualization.
Looks like that suggestion would be a big improvement to my "last chance" option indeed: Install ubuntu, download and install the official tool chain to get to work; then also run Haiku in a VM; I suppose it' possible to share a data partition between both (it would have to be a format that both Linux and Haiku understand, like FAT32); I have almost no experience with VMs but my co-dev at TTS does, If I go that way I'll pick his brain indeed.
Cedric