Opened 2 years ago

Last modified 2 years ago

#65270 new defect

Fish 3.4.1 fails to compile on Leopard PPC

Reported by: acjones8 (Alex Jones) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: Cc: acjones8 (Alex Jones)
Port: fish

Description

I tried to compile fish version 3.4.1 on my PowerBook G4 running Sorbet Leopard, but it fails at about the 65% mark with an error about an invalid conversion. I've attached the entire log, but I believe the error is this line right here:

/fds.cpp:108:77: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
 bool fd_readable_set_t::test(int fd) const { return fd >= 0 && FD_ISSET(fd, &fdset_); }

I was a bit surprised since fish is marked as being successfully built on Macports with Leopard by the buildbot. I'm curious if anyone else has run into this issue?

Attachments (2)

fish.log.bz2 (14.9 KB) - added by acjones8 (Alex Jones) 2 years ago.
Log of compile failure
working_fish.zip (6.1 KB) - added by acjones8 (Alex Jones) 2 years ago.
Last version of fish that works without patches

Download all attachments as: .zip

Change History (13)

Changed 2 years ago by acjones8 (Alex Jones)

Attachment: fish.log.bz2 added

Log of compile failure

comment:1 Changed 2 years ago by acjones8 (Alex Jones)

Cc: acjones8 added

comment:2 Changed 2 years ago by kencu (Ken)

Fish build issues that are unrelated to MacPorts build system specifically are usually posted to their github Issues page, and they have generally been responsive.

https://github.com/fish-shell/fish-shell/

you might ask there, as they know the code better.

The PPC Leopard buildbot I believe has been offline for some time now.

The indicator that fish built on PPC Leopard in the port health section is quite out-of-date; it looks like that success was from a fix I pushed through in 2019 to build the fish of that day. Clearly something not quite right there in the port health indicator. I guess it is thinking that "the last time the buildbot was online and tried to build fish it worked", which is quite possibly true.

comment:3 Changed 2 years ago by acjones8 (Alex Jones)

I tried opening a ticket on GitHub, but it was closed because they no longer support versions of OS X older than 10.10.

I'm still very new to MacPorts and everything, so I apologize if this is a naive question, but is there any way to retrieve an older version of a port, such as the one that worked back in 2019? I used to be a heavy user of FreeBSD and we had this capability in the form of a tool called "portdowngrade", it would let you roll back revisions to a specific port. If not, would you happen to remember which version of fish it was that worked? I currently know very little about how MacPorts works specifically, but maybe I can tinker on it and get it to use whatever version of fish that was, and hopefully it'll still work...

comment:4 Changed 2 years ago by kencu (Ken)

It is possible to install an older version of a port, if a newer one can't build and can't be fixed or you don't have time for that at the moment.

You set up a folder of portfiles that you want to use instead of the main ones. This is an "local portfile repository" or an "overlay". You then make that folder searched before the main repository is searched.

Then you clone the main repository of portfiles and find the github history that takes you back to the commit you want -- the commit before the one that updated your port to the one that will no longer build, for example, or some old version from 2019 if you want. You check out that commit, copy the Portfile (whole folder) from that date into your "overlay", and then it will be used.

MacPorts changes over time -- it's possible that old Portfile will need some updating to actually work -- but if it's not too old, it will probably work. The various dependencies however may have moved on, and the older version may not build against the newer deps, etc, etc, etc -- it's not guaranteed to work.

see:

https://guide.macports.org/#development.local-repositories

wiki:howto/InstallingOlderPort

and probably more spots for detailed info.

Last edited 2 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:5 Changed 2 years ago by acjones8 (Alex Jones)

Ah, so MacPorts has the concept of overlays too, like Gentoo. Okay, that makes plenty sense then - I'll hunt down an older version, set it up in an overlay, and then hopefully with minimal effort, it'll build an older version again. If I manage to get it working, would it be appropriate to attach a compressed archive of the older port to this issue, since I figure eventually there will be another Leopard user out there who's going to stumble on this same issue? At least until I or someone else figures out a way to fix the current version of fish.

comment:6 Changed 2 years ago by acjones8 (Alex Jones)

Alright, I've been working on this, and I think I've found some solutions.

The last git revision that worked before it fails is ae1a507 , which I believe is version 3.1.2 if memory serves me correct. This one compiles completely fine, with no errors, using g++-7.5.0 on (Sorbet) Leopard. To save anyone else from needing to use git checkout and set it up, I'll attach a .zip archive to the problem report above that has the overlay, so all that's needed is to put the extracted folder somewhere and enter it into sources.conf (ahead of the main repository).

I was able to get versions after that, including the most recent one (3.4.1 as of the time of this writing), to compile by adding " configure.cxxflags-append -fpermissive " underneath the two configure.args-append statements. This tells GCC to ignore the casting issues - probably not an advisable solution, but given that it appears as though it's only casting from final and it would fail on a modern compiler if it was incorrectly altered, there shouldn't be any code that actually affects it. And for what it's worth, I've been using it for the entire day and have yet to notice any issues or problems from it, though I'll update this comment here if I run into any. Hopefully, if I brush up on my C++, I can figure out why exactly this issue is occurring at some point and figure out a proper workaround, but for now, this seems to work.

Thank you so much kencu for your guidance! You were extremely helpful, and it's great being able to use my full config and all its creature comforts on OS X.

Changed 2 years ago by acjones8 (Alex Jones)

Attachment: working_fish.zip added

Last version of fish that works without patches

comment:7 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)

If adding -fpermissive is all that was required to get it to work, you may want to report that to the developers in the bug report you filed with them. It's understandable that developers may not wish to invest a great deal of time discovering how to fix issues on obsolete systems, or adding a lot of code to support obsolete systems, but they may accept a small fix such as this.

And, in the mean time, we can add this flag to the MacPorts fish portfile, if you know what criteria we should use. For example, if the criteria is just "whenever the compiler is any version of gcc", that's easy to do, though I would be surprised if nobody else had ever tried to compile fish with gcc, so the criteria may be more specific than that.

comment:8 Changed 2 years ago by evanmiller (Evan Miller)

I've been running Fish 3.3.1 for a while now on 10.4.11 PPC with no hiccups. The only thing preventing me from running 3.4.1 are some terminal color incompatibilities with OS X Terminal (some things are blinking which shouldn't be).

For your amusement here are a couple of patches I sent upstream last year:

https://github.com/fish-shell/fish-shell/pull/8153

https://github.com/fish-shell/fish-shell/pull/8097

The "terminal for the 90s" appears quite amenable to supporting machines from the early 2000s!

comment:9 Changed 2 years ago by acjones8 (Alex Jones)

Unfortunately I don't know enough to fix it properly upstream myself, but I looked into making a proper patch, and my solution so far is to add a specific fix for darwin 9, which covers Leopard. This should eliminate the possibility of interference with any modern versions of OS X. It's super simple, just:

platform darwin 9 {
     # Fixes build issue on (Sorbet) Leopard
     # See: https://trac.macports.org/ticket/65270
     configure.cxxflags-append -fpermissive
}

This works perfectly in my overlay, and I haven't observed any further issues since last week either. This is my first time working with MacPorts though, so if there's a better way of doing this or if I'm misunderstanding how platform works, I would definitely appreciate any suggestions on how to improve it. But if this looks good, I'll submit it to GitHub in a few days.

However, @evanmiller , you mentioned that 3.3.1 works fine? If so, that's very interesting, since I couldn't get anything past 3.1.2 to work without this modification. It would be very strange that Tiger would be more compatible than Leopard, so perhaps this is an issue to my specific setup... although I haven't done anything unusual or non-standard, at least as far as I'm aware. Did you also compile it with GCC 7.5.0?

comment:10 Changed 2 years ago by acjones8 (Alex Jones)

So just a short update to this ticket. With newer versions of fish (at least 3.4.1 and 3.5.0, and potentially older), my copy of OMF (a very popular framework for fish that adds a lot of extra packages) has issues with package management; Specifically, it won't install any new packages or detect any of the existing ones. Temporarily downgrading to 3.1.2 causes it to work perfectly, and once I re-activate 3.5.0, it goes right back to not working. The actual packages themselves work great on either version, it's solely the administration tool that has problems.

This could be entirely separate and just a coincidence it lines up with the versions I compiled with and without -fpermissive, but just on the off chance that it's related, I'm not going to suggest this as a pull request until I'm confident it's not the cause.

comment:11 Changed 2 years ago by evanmiller (Evan Miller)

Update on the

terminal color incompatibilities with OS X Terminal

mentioned above. 10.4-10.6 Terminal self-reports as xterm-color, but does not support 256 colors. Until Fish 3.4 there was special detection logic for Terminal, which was removed in this commit:

https://github.com/fish-shell/fish-shell/commit/8259bf7c7eb95f5718b1bb84029c95fc36739fad

As a workaround, you can run

set -U fish_term256 false

and fish will revert to 16 colors. I am currently running fish 3.5.1 on 10.4/PPC, works great!

Note: See TracTickets for help on using tickets.