Issue : tomboy-ng not building on ppc64el Frédéric, I don't think I will be able to do anything about this until I get home, some time after Easter.
My laptop has U18.04 on it, that has offered me QEMU 2.11.1 and it seems quite unhappy with ppc64le. There are known issues that limit me to using tcg, not kvm. I have to set machine to pseries-2.12 because it can apparently workaround the bug that stops tcg working. Buts its still not good. I can get a commandline but not a working GUI (have tried XFCE4) - I suspect my limited knowledge about QEMU is preventing me from establishing a suitable graphics config. Could you share your QEMU command line to start your test rig please ? Without a test env, I cannot determine the reason behind that crash on Search you are seeing, can you remember what you tried to do ? It could have been an "in note" find, ctrl-F or right click 'Find' or, alternatively, a Search of the whole note collection, Menu 'Search' ?? The target cpu issue ? Its not really an issue IMHO. FPC uses a switch called 'powerpc64' to generate ppc64 code of either endianess. It picks up whatever endianess the host has and uses that. Lazarus, which is a different product, uses $HOSTTYPE to name the object file directories and on Debian at least thats 'powerpc64le'. I guess we could campaign to add 'powerpc64le' to FPC options, having it select both PPC instruction set and little endian but FPC is slow to change ... For now, an if statement will work fine. My build needs a few (surprisingly few) changes to support PPC64le, easy. Fixing that access violation, not so easy until I can run it under the debugger. Sorry. Davo On 30/3/21 1:25 am, Frédéric Bonnard wrote: > Hi, > >> "ppc64el" ? "endian little" ? Is that the same as ppc64le ? > indeed > >> As inIBM Power8 ? > yes > >> I do have a history with IBM Power systems, once managed a >> couple of largeish BlueGene machines. But a long time ago. I now have no >> hope of getting direct access to P8 hardware. FPC 320 does apparently >> support ppc64le and maybe I can cross compile ? > For development use, yes cross-compilation may be an option, but for > Debian package generation, I guess it follows a bit different path > compared to native package build. > >> But sooner or later I'd have to use MiniCloud and bring X back over ssh. >> Brazil to Australia ? Wow, thats going to be fun. > There's also OSUOSl : > https://osuosl.org/services/powerdev/request_hosting/ > > In both case, testing on X may be "fun" :) > Now, I wonder if just having a local ppc64el qemu machine running in > a x86 host isn't better for both compilation (tomboy-ng is not a big > build) and runtime testing. > >> Now, Lazarus, and in this case, I mean LCL, does not offer any PPC64le >> support at all. But you seem to have installed some LCL at least so I >> suspect I should be able to solve the KControls issue that you hit just >> with an understanding of what the OS offers. I expect there will be # >> defines there that think they are looking at an old Mac PPC and thats >> sure not going to work. >> >> So, its possible, the question is, is it practical ? > Well my understand is that LCL is provided on ppc64el : > https://tracker.debian.org/pkg/lazarus > https://packages.debian.org/unstable/lcl-2.0 > ... > >> Personally, I'd consider it pretty cool but I have to ask, is anyone >> using IBM Power8 desktop systems ? > Probably few, but there are desktop oriented Power based systems : > https://www.raptorcs.com/content/base/products.html > https://www.talospace.com/ > > I do not not use the desktop side on Power, but if software compile without > much effort I try to enable them, and also for the sake of portability > and the fact that Debian does support ppc64el officially. > >> OK, you are way ahead of me Frédéric, please disregard my previous response. >> >> Great that your patch works, really cool. And thanks ! However, do you >> mind if I query something ? I don't quite see why you call the - >> >> +if [ "$CPU" = "powerpc64le" ]; then >> + CPU="powerpc64" >> +fi >> >> AFTER the line - >> >> TARGET="$CPU-$OS" >> >> If we set TARGET after the "if" statement. the patch is heaps simpler. >> And I like simple patches ... >> >> Now, I cannot test it here but if you can while you have a terminal to a >> P8 machine, and don't have a reason for the way you have done it, could >> you test please ? >> >> Otherwise, if you think it needs to be as per your patch, I am quite >> happy to apply that. > I always try my patches :) (this one let tomboy-ng build well, and I > didn't see regression on other arches) and I'm always open to discussing it > for sure, > you have the last word. > >> Do you want me to run up a new release or would you prefer to use the >> patch on a Debian downstream release model ? > oh great, I didn't realize you were the upstream too. > > On Sun, 28 Mar 2021 21:58:29 +1100, David Bannon <dban...@internode.on.net> > wrote: >> OK Frédéric, I confess to being on very shaky ground here. But I have >> been doing some reading, but still assuming quite a lot so please pull >> me up if necessary. >> >> Firstly, I believe you are building on a PowerPC64 little endian system >> ? So no compiler switch is needed (like -Ppowerpc64) to get it to build >> an appropriate binary but my script looks in particular places for its >> object files. > I didn't > >> (Or, are you cross compiling ? I cross compile (on a intel 64 linux >> box) to make 32bit linux and Windows 32 and 64 bit.) > Not cross compiling, building on a native system (well, in a schroot > inside a Debian VM in a ppc64el host). > >> For my purposes, I have no plans to directly support other platforms >> (such as Power based Mac), so our only issue here is that we don't break >> Debian supported platform builds. >> >> As well as the powerpc64le, Debian does seem to list bigendian hardware >> as 'supported' ? > ppc64 is not part of the officially supported architectures (grayed in > the following build history) : > > https://buildd.debian.org/status/package.php?p=tomboy-ng > > It's a "port" (Debian meaning) at the moment, relying on individuals in > Debian. > As opposed to ppc64el that is officially supported in Debian. > >> But even if they do, if the build is happening on native hardware, there >> will be no sharing of object files anyway ? > right > >> Or, am I taking a vastly too simplified view of what you and Debian are >> trying to achieve ? >> >> The underlying issue, it seems to me is that FPC does not seem to have a >> separate target CPU switch for the big and little endian Power chips. >> And that surprises me. There is a big endian override switch but not a >> little endian. Hmm... > the build log here : > https://buildd.debian.org/status/fetch.php?pkg=tomboy-ng&arch=ppc64el&ver=0.32-1&stamp=1612358331&raw=0 > > shows this : > /usr/bin/fpc -vm6058,2005,5027 -MObjFPC -Scgi -Cg -O1 -g -gl -l -vewnibq > -vh- -Fi/<<PKGBUILDDIR>>/kcontrols/source -Cg -k-pie -k-znow > -Fu/etc/alternatives/lazarus/packager/units/powerpc64le-linux > -Fu/etc/alternatives/lazarus/components/lazutils/lib/powerpc64le-linux > -Fu/etc/alternatives/lazarus/components/buildintf/units/powerpc64le-linux > -Fu/etc/alternatives/lazarus/components/freetype/lib/powerpc64le-linux > -Fu/etc/alternatives/lazarus/lib/powerpc64le-linux > -Fu/etc/alternatives/lazarus/lcl/units/powerpc64le-linux > -Fu/etc/alternatives/lazarus/lcl/units/powerpc64le-linux/gtk2 > -Fu/etc/alternatives/lazarus/components/cairocanvas/lib/powerpc64le-linux/gtk2 > > -Fu/etc/alternatives/lazarus/components/lazcontrols/lib/powerpc64le-linux/gtk2 > -Fu/etc/alternatives/lazarus/components/ideintf/units/powerpc64le-linux/gtk2 > -Fu/etc/alternatives/lazarus/components/printers/lib/powerpc64le-linux/gtk2 > -Fu/etc/alternatives/lazarus/components/tdbf/lib/powerpc64le-linux/gtk2 -Fu. > -FUlib/powerpc64le-linux kmemo.pas > > So I guess the compiler itself, or its settings somewhere make it aware > of where it is and what it should build (here the /etc/.*/powerpc64le-linux > paths > are wrong) > >> Also, and I admit I am struggling here, it seems to me even your longer >> patch is a problem if someone is cross compiling, you will be making >> little endian object files in ~powerpc64 and if someone then tries to >> cross compile to big endian, they will look in exactly the same place. > Here is what is produced with the patch : > > The generated (MSB/LSB for big and little endian) .o and paths look > good to me : on ppc64el I have : > > --- > (unstable-ppc64el)debian@forge:/build/tomboy-ng-WIYquF/tomboy-ng-0.32$ find > ./ -name '*.o' > ./kcontrols/source/lib/powerpc64le-linux/kfunctions.o > ./kcontrols/source/lib/powerpc64le-linux/kcontrols.o > ./kcontrols/source/lib/powerpc64le-linux/kdialogs.o > ./kcontrols/source/lib/powerpc64le-linux/kedits.o > ./kcontrols/source/lib/powerpc64le-linux/kgraphics.o > ./kcontrols/source/lib/powerpc64le-linux/kmemortf.o > ./kcontrols/source/lib/powerpc64le-linux/kmemo.o > ./kcontrols/source/lib/powerpc64le-linux/kprintpreview.o > ./kcontrols/source/lib/powerpc64le-linux/klog.o > ./kcontrols/source/lib/powerpc64le-linux/khexeditor.o > ./kcontrols/source/lib/powerpc64le-linux/kmessagebox.o > ./kcontrols/source/lib/powerpc64le-linux/kres.o > ./kcontrols/source/lib/powerpc64le-linux/keditcommon.o > ./kcontrols/source/lib/powerpc64le-linux/kprintsetup.o > ./source/lib/powerpc64le-linux/syncutils.o > ./source/lib/powerpc64le-linux/Tomboy_NG.o > ./source/lib/powerpc64le-linux/hunspell.o > ./source/lib/powerpc64le-linux/transfileand.o > ./source/lib/powerpc64le-linux/commonmark.o > ./source/lib/powerpc64le-linux/tb_sdiff.o > ./source/lib/powerpc64le-linux/searchunit.o > ./source/lib/powerpc64le-linux/settings.o > ./source/lib/powerpc64le-linux/rollback.o > ./source/lib/powerpc64le-linux/editbox.o > ./source/lib/powerpc64le-linux/notebook.o > ./source/lib/powerpc64le-linux/markdown.o > ./source/lib/powerpc64le-linux/tomdroid.o > ./source/lib/powerpc64le-linux/transfile.o > ./source/lib/powerpc64le-linux/syncerror.o > ./source/lib/powerpc64le-linux/savenote.o > ./source/lib/powerpc64le-linux/libnotify.o > ./source/lib/powerpc64le-linux/resourcestr.o > ./source/lib/powerpc64le-linux/recover.o > ./source/lib/powerpc64le-linux/syncgui.o > ./source/lib/powerpc64le-linux/spelling.o > ./source/lib/powerpc64le-linux/autostart.o > ./source/lib/powerpc64le-linux/transandroid.o > ./source/lib/powerpc64le-linux/backupview.o > ./source/lib/powerpc64le-linux/tb_utils.o > ./source/lib/powerpc64le-linux/tomdroidfile.o > ./source/lib/powerpc64le-linux/note_lister.o > ./source/lib/powerpc64le-linux/notifier.o > ./source/lib/powerpc64le-linux/sync.o > ./source/lib/powerpc64le-linux/cli.o > ./source/lib/powerpc64le-linux/k_prn.o > ./source/lib/powerpc64le-linux/loadnote.o > ./source/lib/powerpc64le-linux/trans.o > ./source/lib/powerpc64le-linux/mainunit.o > ./source/lib/powerpc64le-linux/index.o > ./source/lib/powerpc64le-linux/colours.o > (unstable-ppc64el)debian@forge:/build/tomboy-ng-WIYquF/tomboy-ng-0.32$ file > ./source/tomboy-ng > ./source/tomboy-ng: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco > 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, > stripped > (unstable-ppc64el)debian@forge:/build/tomboy-ng-WIYquF/tomboy-ng-0.32$ file > ./kcontrols/source/lib/powerpc64le-linux/kcontrols.o > ./kcontrols/source/lib/powerpc64le-linux/kcontrols.o: ELF 64-bit LSB > relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), with debug_info, > not stripped > --- > > and for ppc64 : > --- > (sid-ppc64)debian@amure:/build/tomboy-ng-09nYKj/tomboy-ng-0.32$ find ./ -name > '*.o' > ./kcontrols/source/lib/powerpc64-linux/kmemo.o > ./kcontrols/source/lib/powerpc64-linux/kgraphics.o > ./kcontrols/source/lib/powerpc64-linux/kprintsetup.o > ./kcontrols/source/lib/powerpc64-linux/kres.o > ./kcontrols/source/lib/powerpc64-linux/kfunctions.o > ./kcontrols/source/lib/powerpc64-linux/kcontrols.o > ./kcontrols/source/lib/powerpc64-linux/kedits.o > ./kcontrols/source/lib/powerpc64-linux/khexeditor.o > ./kcontrols/source/lib/powerpc64-linux/kmessagebox.o > ./kcontrols/source/lib/powerpc64-linux/keditcommon.o > ./kcontrols/source/lib/powerpc64-linux/klog.o > ./kcontrols/source/lib/powerpc64-linux/kmemortf.o > ./kcontrols/source/lib/powerpc64-linux/kprintpreview.o > ./kcontrols/source/lib/powerpc64-linux/kdialogs.o > ./source/lib/powerpc64-linux/notifier.o > ./source/lib/powerpc64-linux/syncgui.o > ./source/lib/powerpc64-linux/trans.o > ./source/lib/powerpc64-linux/syncerror.o > ./source/lib/powerpc64-linux/tomdroid.o > ./source/lib/powerpc64-linux/sync.o > ./source/lib/powerpc64-linux/editbox.o > ./source/lib/powerpc64-linux/hunspell.o > ./source/lib/powerpc64-linux/autostart.o > ./source/lib/powerpc64-linux/index.o > ./source/lib/powerpc64-linux/savenote.o > ./source/lib/powerpc64-linux/transfileand.o > ./source/lib/powerpc64-linux/notebook.o > ./source/lib/powerpc64-linux/syncutils.o > ./source/lib/powerpc64-linux/tb_sdiff.o > ./source/lib/powerpc64-linux/note_lister.o > ./source/lib/powerpc64-linux/Tomboy_NG.o > ./source/lib/powerpc64-linux/commonmark.o > ./source/lib/powerpc64-linux/backupview.o > ./source/lib/powerpc64-linux/libnotify.o > ./source/lib/powerpc64-linux/mainunit.o > ./source/lib/powerpc64-linux/colours.o > ./source/lib/powerpc64-linux/searchunit.o > ./source/lib/powerpc64-linux/transandroid.o > ./source/lib/powerpc64-linux/rollback.o > ./source/lib/powerpc64-linux/k_prn.o > ./source/lib/powerpc64-linux/tb_utils.o > ./source/lib/powerpc64-linux/transfile.o > ./source/lib/powerpc64-linux/settings.o > ./source/lib/powerpc64-linux/tomdroidfile.o > ./source/lib/powerpc64-linux/spelling.o > ./source/lib/powerpc64-linux/cli.o > ./source/lib/powerpc64-linux/resourcestr.o > ./source/lib/powerpc64-linux/loadnote.o > ./source/lib/powerpc64-linux/markdown.o > ./source/lib/powerpc64-linux/recover.o > (sid-ppc64)debian@amure:/build/tomboy-ng-09nYKj/tomboy-ng-0.32$ file > ./source/tomboy-ng > ./source/tomboy-ng: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco > 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, > stripped > (sid-ppc64)debian@amure:/build/tomboy-ng-09nYKj/tomboy-ng-0.32$ file > ./kcontrols/source/lib/powerpc64-linux/kcontrols.o > ./kcontrols/source/lib/powerpc64-linux/kcontrols.o: ELF 64-bit MSB > relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), with debug_info, > not stripped > --- > >> So, perhaps, the solution is to flush ALL object files at the start of a >> build ?? > (In Debian packaging, a make clean is done beforehand everytime.) > Now, for a developer, cleaning before building may not be the best in a > make spirit, because you only want to build what needs to be built, such > as object files older that source file. > On the other hand, I see, you don't use that make specificity, so you could > remove object files. > But as I showed above, with the patch, the object files should end up in > the proper directories : powerpc64-linux for ppc64 and powerpc64le-linux > for ppc64el. > >> Sorry I have caused so much trouble here ! > It's legitimate to understand things, especially before merging in your > source. > > I've attached screenshots of tomboy-ng running in a ppc64el qemu VM. > Two things to note : > - I had to remove the pie options in buildit.bash, else the binary fails > which is a behaviour I already saw. So, that may be another point to > take into account for powerpc64[le] at least. > - searching seems to fail with the message "Access violation" .. not > sure what it this... > > but the build with the patch, seemed to have done well overall. > > F. > >> Davo >> >> >> On 27/3/21 6:08 pm, Frédéric Bonnard wrote: >>> Hi Davo, >>> answering quickly as I see you're active right now. >>> But I'll come back on Monday on your questions in more details because they >>> deserve answers, but I don't have much time this weekend, so going straight >>> to the point for now. >>> >>> March 27, 2021 7:20 AM, "David Bannon" <dban...@internode.on.net> wrote: >>> >>>> OK, you are way ahead of me Frédéric, please disregard my previous >>>> response. >>>> >>>> Great that your patch works, really cool. And thanks ! However, do you >>>> mind if I query something ? I don't quite see why you call the - >>>> >>>> +if [ "$CPU" = "powerpc64le" ]; then >>>> + CPU="powerpc64" >>>> +fi >>>> >>>> AFTER the line - >>>> >>>> TARGET="$CPU-$OS" >>>> >>>> If we set TARGET after the "if" statement. the patch is heaps simpler. >>>> And I like simple patches ... >>> Yes, I didn't like it as well, because of the same reason and I was kinda >>> reluctant >>> to send and tried to justify it in the patch :) >>> The reason I complexified this is that I wanted to keep the local objects >>> produced into a ppc64el related directory which is what is done generally. >>> Of course this is in the build directory so more or less temporary. >>> Still if the patch is meant to go upstream, that could make a little bit >>> more sense there. >>> And, powerpc64-linux and powerpc64el-linux objects are not compatible, so >>> same >>> path does not make sense to me. If cross compiling or doing some other >>> specific builds, >>> the build directory could end up with .o overwriting each other. >>> On the other hand, lazarus source package produces ppc64 and ppc64el and >>> store .o for >>> binary packages in the very same paths... and I don't really get why >>> lazarus does this. >>> >>> So, if the patch remains in Debian, I think you can perfectly simplify >>> it as you explain. >>> I'd still be interested to understand the root "issue" in lazarus. I saw >>> other >>> distros have the same paths and from digging in lazarus, I didn't find >>> in the time I had, a way to change this and to try if things still work :) >>> That would be a question for upstream. >>> >>> Anyway, the simple patch works well too, that was what I did initially. >>> I'll come back later for your other questions! >>> >>> F. >>> >>>> Now, I cannot test it here but if you can while you have a terminal to a >>>> P8 machine, and don't have a reason for the way you have done it, could >>>> you test please ? >>>> >>>> Otherwise, if you think it needs to be as per your patch, I am quite >>>> happy to apply that. >>>> >>>> Do you want me to run up a new release or would you prefer to use the >>>> patch on a Debian downstream release model ? >>>> >>>> Davo >>>> >>>> On 27/3/21 3:00 am, Frédéric Bonnard wrote: >>>> >>>>> Here is a patch proposal which fixes the build. >>>>> The patch header details the issue and the possible workaround. >>>>> Regards, >>>>> >>>>> F.
