/usr/local/bin/lynx: Bad CPU type in executable

[Richard L. Hamilton]

Another reality is that a LOT of open-source software has /usr/local embedded in its search for components, both for building and running. I think various other software does too; so for example if anything in Xcode (needed to build other compilers) does, the problem could arise that way  too. macOS itself has at least a few references to /usr/local, AFAIK.

MacPorts AFAIK tries not to use /usr/local; but the difficulties in entirely preventing that are considerable;  and having something around with possibly incompatible components will cause problems that are beyond what anyone is prepared to assist with.

Some totally self-written programs could go there, and not conflict, as long as they didn't install libraries, frameworks, or include files similar to those used by some MacPorts port. Some commercial software like Parallels or VirtualBox will want to put a few things there, and that's generally not a problem.  But other open-source packaging follows its own rules, and the conflicts could cause the problem.

My personal view is that it's worst if that's there while installing or upgrading ports that are compiled locally; that's where really tough problems might result, because something might be built wrong, which moving the conflicting files away later wouldn't fix. I turned off SIP long enough to change /usr/local to a  symlink; so any time I want what the symlink points to out of the way, I just  rename that, and it's no longer visible; usually good enough to do that while building ports, (I would likely have to redo such tinkering after a macOS upgrade, since it tends to want to revert unapproved changes.)



> On Dec 23, 2019, at 17:30, Michael Newman via macports-users <macports-users at lists.macports.org> wrote:
> 
> On Dec 23, 2019, at 21:06, Ryan Schmidt <ryandesign at macports.org <mailto:ryandesign at macports.org>> wrote:
>> 
>> As far as I know, yes it does, by default, which is why, if you install them to their default locations, you should only use one package manager and uninstall the other to prevent conflicts.
> 
> I supposed that in an ideal world where a single package manager had all available packages and where broken packages were fixed quickly, that might work.
> 
> Unfortunately, this is not the case.
> 
> I have been using ffmpeg from MacPorts daily for several years. It broke with the release of Catalina. A ticket has been filed (59750). But, I can’t wait for it to get fixed. I need it every day. The only alternative I could find was avconv, which MacPorts doesn’t have. I don’t know how long it will be before ffmpeg works again.
> 
> However, I do have some experience. I used to use sunwait. It broke. I filed a ticket (51700). It took two years before sunwait was fixed. In the meantime, I had to find an alternative.
> 
> I’m not trying to be critical here. I understand the situation. This is all done by volunteers who have way more smarts and ability than I have. 
> 
> The reality is that people are going to use more than one package manager if the need arises. 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20191223/a67fd8af/attachment.html>