In my PPC Debian world, my 64-bit installation of Debian PPC is quite able to run 32 bit software.
Linux does this by putting the libraries into lib64 or lib32 subfolders, as Linux does not use "Fat binaries". So if you go down this road with MacPorts, then presumably that ability will be lost as there will be only one library folder. Whether MacPorts will ever meaningfully support Linux and whether anyone who does will ever care about running 32 bit software on it is another question. K > On Sep 17, 2024, at 4:12 AM, Sergey Fedorov <vital....@gmail.com> wrote: > > I just checked the CMake PG, and for Darwin it has a flag with the same > effect, but it is MacOS-specific. So yes, we do not need this for Darwin at > all, and I can make it specific to non-Apple. > > On Tue, Sep 17, 2024 at 12:55 AM Christopher Jones via macports-dev > <macports-dev@lists.macports.org <mailto:macports-dev@lists.macports.org>> > wrote: >> >> Hi, >> >> I would say unless there is a need to also use this flag on darwin builds, >> and it would appear not, then as long as whatever you add to the PG it >> *only* activates for linux, and not darwin, then it cannot have any serious >> impact. >> >> Chris >> >>> On 15 Sep 2024, at 1:59 PM, Sergey Fedorov <vital....@gmail.com >>> <mailto:vital....@gmail.com>> wrote: >>> >>> Currently nothing in MacPorts sets libdir for CMake ports. On MacOS this is >>> no issue. On Linux this leaves multiple ports broken, since CMake throws >>> libs into ${prefix}/lib64, where nothing looks for them, so all dependents >>> are broken. >>> As a few examples: libdeflate, lerc, libjpeg-turbo. >>> >>> I think this should be fixed in cmake PG. Any objections to this? >>> >>> Original PR for libdeflate, should be changed to a general fix: >>> https://github.com/macports/macports-ports/pull/25757 >>> >>
