Bug#985946: patch proposal
Just an update, I can build tomboy-ng fine on ppc64le using the current FPC and Lazarus direct from the FPC. I have pushed a new release of tomboy-ng up to my sponsor, Philipp and it has pie hardening turned off for ppc64le, something I found necessary and believe is worthy of further investigation. I have not tested using Sid/Bookworm Debian FPC and Lazarus as they are in somewhat of a state of flux at present so, because of that, and the PIE issue, will leave this ticket open for now. Just some notes relating to the things I mentioned previously - On Sat, 2021-10-30 at 15:32 +1100, David Bannon wrote: > > > 1. The debian package has some problem with the version numbers. It > has This problem is not unique to ppc64le, its in Bullesye on AMD64 too. Does not prevent Lazarus from being used to build a preexisting app. > 2. So, I built from source and the bigide version will not build due > to Problem seems to be limited to lhelp, other parts of Lazarus build fine on ppc64le. You can get by without lhelp but perhaps it needs to attention. I have not tried using the Lazarus IDE (ie in GUI mode) in this iteration. Hard work over qemu Davo
Bug#985946: patch proposal
Topic : Lazarus on a ppc64el Hi Paul, Abou. Thats great timing, I deleted my PPC image about a week ago to save some diskspace. :-) I was initially approached to help get tomboy-ng built on ppc64el and, as an old IBM Power user I thought that would be fun. But I quickly found I would need some debugging and for Lazarus users, that means the Lazarus IDE, there I struck some problems and it appeared Debian people also lost interest. Personally, I would quite like to be involved here (but the usual time constraints apply, we all know about that ...) I am not sure what I told (Abou ?) earlier this year but here is a summary of my notes going back to then (current comments following the "Further -" point. 1. The debian package has some problem with the version numbers. It has been given a version number in ide/version.inc of 2.0.10+dfsg-4, says "welcome to 2.0.10+dfsg-4+b2" but is nicely tucked away /usr/lib/lazarus/2.0.10 and the IDE is rightly confused. And it did not install libqt5pas-dev. Further - I notice (only yesterday) that Lazarus on Debian Bullseye amd64 has a similar problem, the deb install thinks it has one version number and the Lazarus source code another. As the Lazarus IDE is routinely rebuilt, that causes problems until the user bites the bullet and edits the source code. Generally, many Lazarus users prefer building from SRC. 2. So, I built from source and the bigide version will not build due to a strange error in PascalScript, while lots of warnings about pointer not portable, it appears to fail at the end of the file without a specific error message. Not seen anything like that. Further - sadly I don't remember the details here. Pointer not being portable on x86 is not an issue, "might" be here. 3. Will build without 'bigide'. However, the simplest app crashes at exit with a floating point error when run with the debugger. Does not crash outside debugger ? Further - being unable to work with gdb is a problem. But newer releases of Lazarus include a built in debugger, may be interesting to try that ? I generally use Lazarus trunk/main but understand that Debian frowns on such approaches (for good reason). 4. Qt5 version of Lazarus IDE does not show component and tool bars. Further - Generally, Lazarus users use the GTK2 version, it will make a Qt5 a application and life is just a touch simpler using GTK2 Lazarus. I understand that Debian wants to downplay GTK2 right now but I suspect getting the whole thing going with GTK2 initially might be easier. This is using above command line, appears to give me a POWER8 with VGA. Cannot find any qemu docs about what machine is what, so, maybe a trial and error approach with other machines ? The XFCe terminal does not seem to get me any copy and paste or screen dump capabilities (within the machine) so if I am to do any more I think I will have to try a Mate install. Further - by "above command line, I meant - qemu-img create -f qcow2 ppc64le.img 15G qemu-system-ppc64le -machine pseries-2.12 -m 2048 -boot d -net nic -net user -hda ppc64le.img -cdrom debian-bullseye-DI-alpha3-ppc64el- netinst.iso It is quite possible, given my inexperience with qemu and current power processors that the above is quite, quite wrong ! I am, of course, willing to listen to any suggestion ! Davo On Thu, 2021-10-28 at 14:49 +0200, Paul Gevers wrote: > Hi David, > > I was just pointed to this bug. > > On Tue, 6 Apr 2021 10:21:43 +1000 David Bannon > wrote: > [...] > > > then I built Lazarus from source (my prefered model) and found more > > issues that relate, I think, to LCL, particularly under Qt5. So, > > in my > > very uneducated opinion, Lazarus is not yet ready for ppc64el and > > as its > > not on the Lazarus's supported list, they won't be very interested > > in > > finding out why that is. They would definitely accept patches but > > a bug > > report with no solution will not attract a lot of attention. > > > > I suggest its not really a very good idea to list Lazarus as a > > supported > > Debian package on ppc64el. FPC is fine, but not Lazarus. Just my > > opinion. > > I think Abou (on the list in CC) would love to discuss your > experience. > The Debian FreePascal team likes to support Lazarus (and FPC) on all > Debian supported architectures where feasible, but we need to be made > aware of issues before we can fix them. > > Paul >
Bug#985946: patch proposal
Hi David, I was just pointed to this bug. On Tue, 6 Apr 2021 10:21:43 +1000 David Bannon wrote: [...] > then I built Lazarus from source (my prefered model) and found more > issues that relate, I think, to LCL, particularly under Qt5. So, in my > very uneducated opinion, Lazarus is not yet ready for ppc64el and as its > not on the Lazarus's supported list, they won't be very interested in > finding out why that is. They would definitely accept patches but a bug > report with no solution will not attract a lot of attention. > > I suggest its not really a very good idea to list Lazarus as a supported > Debian package on ppc64el. FPC is fine, but not Lazarus. Just my opinion. I think Abou (on the list in CC) would love to discuss your experience. The Debian FreePascal team likes to support Lazarus (and FPC) on all Debian supported architectures where feasible, but we need to be made aware of issues before we can fix them. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#985946: patch proposal
Topic : tomboy-ng not working on ppc64el Frédéric, I have now done some testing using a more recent version of qemu and results are somewhat mixed. My plan was to install the Debian versions of FPC and Lazarus, build my app and run it under the IDE debugger. However, I encountered several problems long before I un-tared my source. Now, I am a new qemu user and have not worked on POWER for a very long time, but I believe I found first a Lazarus packaging problem, then I built Lazarus from source (my prefered model) and found more issues that relate, I think, to LCL, particularly under Qt5. So, in my very uneducated opinion, Lazarus is not yet ready for ppc64el and as its not on the Lazarus's supported list, they won't be very interested in finding out why that is. They would definitely accept patches but a bug report with no solution will not attract a lot of attention. I suggest its not really a very good idea to list Lazarus as a supported Debian package on ppc64el. FPC is fine, but not Lazarus. Just my opinion. Given the Debian Testing feature freeze, is there scope to address the Lazarus problems I have found ? Davo
Bug#985946: patch proposal
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 > wrote: >> OK Frédéric, I confess to being on very shaky
Bug#985946: patch proposal
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" 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. signature.asc Description: PGP signature
Bug#985946: patch proposal
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. 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. > >
Bug#985946: patch proposal
Here is a patch proposal which fixes the build. The patch header details the issue and the possible workaround. Regards, F. --- a/buildit.bash +++ b/buildit.bash @@ -156,6 +156,9 @@ CPU="i386" fi TARGET="$CPU-$OS" +if [ "$CPU" = "powerpc64le" ]; then +CPU="powerpc64" +fi CheckFPC CheckLazBuild CheckForQt5 @@ -193,12 +196,12 @@ FPCHARD=" -Cg -k-pie -k-znow " FPCKOPT=" -MObjFPC -Scgi -Cg -O1 -g -gl -l -vewnibq -vh- -Fi$K_DIR" -FPCKUNITS=" -Fu$LAZ_DIR/packager/units/$TARGET -Fu$LAZ_DIR/components/lazutils/lib/$TARGET" -FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/buildintf/units/$TARGET -Fu$LAZ_DIR/components/freetype/lib/$TARGET" -FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/lib/$TARGET -Fu$LAZ_DIR/lcl/units/$TARGET -Fu$LAZ_DIR/lcl/units/$TARGET/$WIDGET" -FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$TARGET/$WIDGET -Fu$LAZ_DIR/components/lazcontrols/lib/$TARGET/$WIDGET" -FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/ideintf/units/$TARGET/$WIDGET -Fu$LAZ_DIR/components/printers/lib/$TARGET/$WIDGET" -FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/tdbf/lib/$TARGET/$WIDGET -Fu. -FUlib/$TARGET" +FPCKUNITS=" -Fu$LAZ_DIR/packager/units/$CPU-$OS -Fu$LAZ_DIR/components/lazutils/lib/$CPU-$OS" +FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/buildintf/units/$CPU-$OS -Fu$LAZ_DIR/components/freetype/lib/$CPU-$OS" +FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/lib/$CPU-$OS -Fu$LAZ_DIR/lcl/units/$CPU-$OS -Fu$LAZ_DIR/lcl/units/$CPU-$OS/$WIDGET" +FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$CPU-$OS/$WIDGET -Fu$LAZ_DIR/components/lazcontrols/lib/$CPU-$OS/$WIDGET" +FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/ideintf/units/$CPU-$OS/$WIDGET -Fu$LAZ_DIR/components/printers/lib/$CPU-$OS/$WIDGET" +FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/tdbf/lib/$CPU-$OS/$WIDGET -Fu. -FUlib/$TARGET" RUNIT="$COMPILER $EXCLUDEMESSAGE $FPCKOPT $FPCHARD $FPCKUNITS kmemo.pas" @@ -210,7 +213,7 @@ # exit -if [ ! -e "$K_DIR/lib/$CPU-$OS/kmemo.o" ]; then +if [ ! -e "$K_DIR/lib/$TARGET/kmemo.o" ]; then echo "ERROR failed to build KControls, exiting..." K_DIR="" exit 1 @@ -254,15 +257,15 @@ OPT1="-MObjFPC -Scghi -CX -Cg -O3 -XX -Xs -l -vewnibq $EXCLUDEMESSAGE -Fi$SOURCE_DIR/lib/$TARGET" UNITS="$UNITS -Fu$K_DIR/lib/$TARGET" -UNITS="$UNITS -Fu$LAZ_DIR/components/tdbf/lib/$TARGET/$WIDGET" -UNITS="$UNITS -Fu$LAZ_DIR/components/printers/lib/$TARGET/$WIDGET" -UNITS="$UNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$TARGET/$WIDGET" -UNITS="$UNITS -Fu$LAZ_DIR/components/lazcontrols/lib/$TARGET/$WIDGET" -UNITS="$UNITS -Fu$LAZ_DIR/components/lazutils/lib/$TARGET" -UNITS="$UNITS -Fu$LAZ_DIR/components/ideintf/units/$TARGET/$WIDGET" -UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$TARGET/$WIDGET" -UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$TARGET" -UNITS="$UNITS -Fu$LAZ_DIR/packager/units/$TARGET" +UNITS="$UNITS -Fu$LAZ_DIR/components/tdbf/lib/$CPU-$OS/$WIDGET" +UNITS="$UNITS -Fu$LAZ_DIR/components/printers/lib/$CPU-$OS/$WIDGET" +UNITS="$UNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$CPU-$OS/$WIDGET" +UNITS="$UNITS -Fu$LAZ_DIR/components/lazcontrols/lib/$CPU-$OS/$WIDGET" +UNITS="$UNITS -Fu$LAZ_DIR/components/lazutils/lib/$CPU-$OS" +UNITS="$UNITS -Fu$LAZ_DIR/components/ideintf/units/$CPU-$OS/$WIDGET" +UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$CPU-$OS/$WIDGET" +UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$CPU-$OS" +UNITS="$UNITS -Fu$LAZ_DIR/packager/units/$CPU-$OS" UNITS="$UNITS -Fu$SOURCE_DIR/" UNITS="$UNITS -FU$SOURCE_DIR/lib/$TARGET/" signature.asc Description: PGP signature
