On 04/11/2015 22:54, KI7MT wrote: > Hi Bill, Hi Greg, > > Ok, thanks for the info. > > Now, to convolute this whole picture a bit more. Sean told me he's > running Ubuntu-Mate on a G5 iMac. From my understanding, the G5 iMac is > a ppc 32-bit box, and the Ubuntu kernel ( don't ask me how this works, > as I've no idea ) is 64-bit smp ( uname -r = 4.2.0-16-powerpc64-smp ). Linux certainly run on PPC and like Windows it supports 32-bit applications with a 64-bit kernel (and vice versa I believe). > > Question is, will WSJT-X support this combination, 32-bit packaging with > a 64-bit Kernel ? I would think yes, as long as the packages are > available through the repository ( in this case 32-bit Ubuntu ppc ) and > / or there is nothing funky with the WSJT-X code that wont work with ppc > (32-bit). This is way outside my WheelHouse for sure. The first question will be are Qt 5 and FFTW3 supported which I believe is so, if they are then there is a fair chance that WSJT-X can be built and run. If he is actually trying to get WSJT-X running on that hardware then I am happy to help out. > > I can say, nothing in the JTSDK-Nix base package requires any ARCH > specific packaging that is not available for ppc (32-bit) or ppc64el, > mainly, bash, autotools and dialog. I'm not sure bout Python packages, > but Sean was able to get WSPR running so that must be OK as is. There will probably have to be a couple CMake script enhancements for WSJT-X building on Linux/ppc. > The other unknown is, what about the KVASD binary for PPC? If this is a > non-starter, would this not limit the availability to WSJT-X v1.6.1 > where the new Non-KVASD decoder is / has been implemented. I can't > recall if this is been added to the v1.6.0 branch or not. A KVASD build could be made for Linux PPC if an account on a suitable build machine were made available to Joe, obviously that would not necessarily happen fast given Joe's many commitments. The move to eliminate KVASD is still in progress and as far as WSJT-X is concerned is only in wsjtx_exp and not yet complete although there is not much left to do (mainly eliminating it from the build and packaging).
I wonder how many OMs have an old G4 or G5 PPC under the bench that could be revived with Linux/ppc for shack usage. It's been a few years since I worked with them, I always remember the rush of air around my feet in the Morning when they had crashed overnight (they fail safe at full fan speed). > > Thanks > > 73's > Greg, KI7MT 73 Bill G4WJS. > > On 11/04/2015 08:08 PM, Bill Somerville wrote: >> On 04/11/2015 18:46, KI7MT wrote: >>> To be honest, I'm a bit fuzzy on the -fPIC v.s. >>> -fPIE flag usage. >> Hi Greg, >> >> PIC code is required if the relocatable object code is to be linked into >> a shared library. This is necessary so that the image loader can map the >> library into more than one process address space without wasting large >> amounts of address space (which would be the case if it had to be mapped >> at the same address in every process that needed it). >> >> PIE executables are executables that contain only PIC code and therefore >> can be loaded at any address. This is not normally required since >> executables are normally loaded at he same address. PIE executables can >> be used in a form of security hardening when load addresses are randomized. >> >> The gcc compiler suite recognizes -fPIC and -fpic (also -fPIE and >> -fpie), the lower case forms are more efficient on some processors but >> the differences are not very significant. >> >> Richard KF5OIM recently reported that WSJT-X code that is not used in a >> shared library had to be compiled as PIC, this make no sense to me but >> it is possible that recent versions of gcc have changed the meaning or >> requirements for PIC code. He was using a recent Fedora (FC23) which >> uses gcc v5. Having said that I have built Hamlib 3 and WSJT-X on FC23, >> which is now released, without having to change any compiler flags. So I >> am not yet sure what is going on. >> >> 73 >> Bill >> G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
