It’s definitively x86, because the code doesn’t build under the gcc2 compiler. As it doesn’t support the C++14 extensions.
The correct naming should be appname_x86-x.x-x-x86_gcc2.hpkg for the secondary arch, that’s probably why you’re getting that error, i could be wrong, maybe it doesn’t really matter?.
Is this correct? I don’t think a version requirement should be needed there, without the ins and outs for the package hard to tell what the problem is here. 
uppercase letters in the “name” field are converted to lowercase which causes some confusion. Try using “i.disk” instead.
But the architecture field has to match the system architecture. Hence @khallebal is correct. You can check one of the _x86 packages present on the system itself to see what its PackageInfo looks like to confirm how this works.
So in looking for a non gcc2 hpkg to examine I first checked /boot/system/packages but they are all x86_gcc2, so not what I’m looking for right?
Then I looked at the haikuports lzip package, which in it’s recipe specifically says “!x86_gcc2” so I built that with:
./haikuporter.py lzip_x86
And what do I get?
grabbing lzip_x86-1.23-1-x86_gcc2.hpkg and moving it to /boot/home/haikuports/packages/lzip_x86-1.23-1-x86_gcc2.hpkg
Hmmm well ok then. Is that not how you build a “x86” package verses “x86_gcc2”?
Nope, that’s exactly how you do it! That package is built with the modern GCC.
The package architecture refers to the primary system architecture the package was built for, not the compiler that was used. Hence the _x86 in the name, which indicates the “secondary” architecture of the package.
It’s a bit confusing, indeed.
Runs on my system. A Deskbar entry would be nice.
So if I make the architecture “x86_gcc2” in my .PackageInfo the package will install but:
/boot/system/apps> ./i.Disk
runtime_loader: Cannot open file liblgi.so (needed by /boot/system/apps/i.Disk): No such file or directory
/boot/system/apps> find .. -iname liblgi.so
../lib/liblgi.so
Yeah it doesn’t actually run. liblgi.so was built under “setarch x86”.
In examining lzip, they use x86_gcc2 as the .PackageInfo architecture so that’s correct. But in conflict with the documentation for .PackageInfo.
liblgi.so needs to be put in /system/lib/x86, not /system/lib in order to be found. But if this is a library for only this one application and no others, you can put it in a lib subdirectory (i.e. /boot/system/apps/i.Disk/lib, with your binary in /boot/system/apps/i.Disk.)
1 Like
Thanks waddlesplash, that was the last missing piece in the puzzle and now I have a working 32bit x86 build. I’ve added that release to the home page.
3 Likes