base: (linux) fails to determine build arch correctly

[kencu (Ken)]

On Ubuntu 20.04, base builds ports as 64bit x86_64, but registers them as "i386".

Manually setting build_arch to x86_64 in macports.conf overrides this and they are properly registered as x86_64

[kencu (Ken)]

Rene, I have started to dabble in installing MacPorts on linux. I have heard from others that there is interest in this.

I know you are very much further down this road than I am, and I am aware of your "linuxports" project.

I think -- I am not sure -- that I might be able to very slowly get some uptake with linux-specific fixes into base, if we proceed very carefully, and if we can get Josh and Marcus on board. This will be a delicate dance, as we cannot make MacPorts any less functional on MacOS in any way, and we cannot add undue complexity to an already burdensome load supporting older systems.

With that in mind, if you can help steer me towards the fixes you have found for this issue, and the other couple of similar tickets with their own individual issues I have opened, we can see what support we might get for rounding out the linux support on Macports.

I would suggest we start with Ubuntu, as that is where almost everyone starts, and there is no point working on a project that nobody cares about with some variant flavour of Linux that is not in common use.

Appreciate any help you care to be able to provide.

[RJVB (René Bertin)]

Quick reply: I'm running a patched "base" that's formalised in the MacPorts-devel port in my macstrop project; it has a number of Linux-specific patches but the port builds to something that installs on my Mac and Linux machines. On the former I just run a make install after checking that the destroot step completed OK. On Linux, I make a .deb install image first (after bringing back the required code from the dead).

I'll come back to this, I am already part way down too many other rabbit holes at the moment ;)

[RJVB (René Bertin)]

Ken, I have not forgotten about this, have been bringing my base install (and thus my MacPort-devel port) up-to-date and polishing things up here and there. I can now also install base via dpkg on Mac, so reverting to a previous install is more straightforward (I asked about up/down-grading with the native Mac packages on the ML but missed any answers I might have gotten).

With that off my chest I'll try to find some time to look at the tickets you mentioned, but feel free to have a look at my various patches. I do have a number of patches that are not applied on Mac, but that's mostly to keep the installed code clean on Mac.

It might not be a bad idea keep this kind of separation if not everyone on the team is fine with the idea of having a single code base that works on both platforms. This could also send a clearer signal to potential users that they should expect to be able to install just any port "as is". There are a lot of patches (and Portfile operations) in the ports tree that introduce unconditional Mac specifics, and the chance of running into conflicts with (esp.) headerfiles installed through the distribution is much bigger. It happens quite regularly that I need to uninstall distro -dev packages, or worse, to remove crucial components from them by hand because uninstalling would also uninstall other packages that I don't want to uninstall for some reason. There's also an issue with rpaths; meson has a knack of stripping the carefully tuned settings I added from the final binaries, which means a wrapper script is necessary. There's also a lot of trickyness going on with GLib, GTk3 and Vala. I don't think they're really designed to support having a newer version in a parallel prefix (gentoo-prefix might have an answer to that).

In practice, my Linux-specific ports tree is a bit of a cardhouse of ports with dropped dependencies that are expected to be provided through the system (mostly because of lazyness and not having to build and have them doubly installed) or that are actual wrappers for things installed in the system (the llvm and clang ports, for instance).

Have you looked into a replacement for the machista library? This is about the only function from base that does not currently work under Linux. Not that I really miss it, most of the time, so I haven't tried to come up with a replacement myself.