MacPorts 2.6.4 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.6.4. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from Big Sur 11.0 all the way back to 10.4 (11.0 is
universal arm64/x86_64, 10.6 is i386/x86_64, 10.5 and 10.4 are i386/ppc,
the rest are x86_64) at [2]. The source is also available as tarballs
compressed with gzip or bzip2, or from the git tag [3].

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 
[4] 

Re: rebuild a package without an update

[Ryan Schmidt]

On Nov 13, 2020, at 17:45, Riccardo Mottola wrote:

> On 2020-11-08 08:18:22 +0100 Ryan Schmidt wrote:
> 
>> On Nov 7, 2020, at 12:46, Riccardo Mottola wrote:
>>> I need to rebuild a package which is not working due to a dependency 
>>> upgrde. revdep "catches" it but revdep fails to build it because it uses 
>>> the wrong compiler and I need to force it (also because the compiler itself 
>>> is broken because it is broken because the library is broken)
>>> I usually in these cases just run "port upgrade  
>>> configure.compiler=xxx" but in this case there is nothing to upgrade, I 
>>> need to rebuild in place.
>>> How can I do?
>> This situation should not arise. But: you can force a rebuild of a port 
>> using:
> 
> Indeed, but we have an issue that ICU upgrades break libxml2 and that one 
> breaks *all* clang compilers.
> Since gcc now links using clang also al macports clangs are broken!
> 
> So I have to force the "gcc-4.2" of xcode... that one works (and, luckily, 
> libxml2 still compiles with it)

My point is that "sudo port upgrade outdated" should work. If it does not, we 
may have a bug somewhere that we need to fix, and what you're describing above 
sounds like we haven't declared dependencies correctly somewhere, or maybe we 
have a circular dependency. Forcibly rebuilding a port is nice to know how to 
do, I just wanted to emphasize that it is not a task we expect users to need to 
do on a regular basis.

failure to link most programs on Leopard

[Riccardo Mottola via macports-users]

Hi!

during my upgrade cycle... I noticed I cannot upgrade a lot of software, 
linking fails. Be it asciidoc or gcc48, I get this error:


ld: warning: could not create compact unwind for 
__Unwind_RaiseException: non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_ForcedUnwind: 
non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_Resume: does 
not use EBP or ESP based frame
ld: warning: could not create compact unwind for 
__Unwind_Resume_or_Rethrow: non-standard register 0 being saved in prolog
ld: illegal text-relocation to '___cpu_indicator_init' in cpuinfo_s.o 
from 'anon' in cpuinfo_s.o for architecture i386

collect2: error: ld returned 1 exit status
make[3]: *** [libgcc_s.dylib] Error 1
make[3]: *** Waiting for unfinished jobs
:485:11: warning: section "__textcoal_nt" is deprecated
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
 ^  ~
:485:11: note: change section name to "__text"
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
 ^  ~


That doesn't look promising... Any ideas? Ken?

Riccardo

Re: failure to link most programs on Leopard

[Ken Cunningham]

> ld: illegal text-relocation to '___cpu_indicator_init' in cpuinfo_s.o 
> from 'anon' in cpuinfo_s.o for architecture i386

This is a fairly common error when linking 32 bit software

You fix it with something like this, from the x265 Portfile




if {[variant_exists universal] && [variant_isset universal]} {
lappend merger_configure_ldflags(i386) -Wl,-read_only_relocs,suppress
} else {
if {${build_arch} eq "i386"} {
configure.ldflags-append -Wl,-read_only_relocs,suppress
}
}

===


I notice that block ignores “ppc” which also tends to throw the same error, 
being 32bit as well.


I’m not positive, but I think at one point in time macports base added this 
flag to most or all builds, but that went by the wayside when most builds 
became 64bit intel. 

Ken

Re: failure to link most programs on Leopard

[Ken Cunningham]

Here is another more complex block I added to another port, that also 
suppresses the compact unwind issue too:


===

if {[variant_isset universal]} {
lappend merger_configure_env(i386)  
LDFLAGS=-Wl,-read_only_relocs,suppress,-no_compact_unwind
} else {
if {${build_arch} eq "i386"} {
configure.env-append
LDFLAGS=-Wl,-read_only_relocs,suppress,-no_compact_unwind
}
}

===

Re: failure to link most programs on Leopard

[Ryan Schmidt]

On Nov 14, 2020, at 14:31, Ken Cunningham wrote:

> I’m not positive, but I think at one point in time macports base added this 
> flag to most or all builds, but that went by the wayside when most builds 
> became 64bit intel. 
> 

I have no recollection of that being the case, and searching the macports-base 
repository via the GitHub web interface for read_only_relocs gives me no hits. 
We try not to break compatibility with older systems in MacPorts base.

Re: failure to link most programs on Leopard

[Ken Cunningham]

One last thing…

this noise:

:485:11: warning: section "__textcoal_nt" is deprecated
 .section __TEXT,__textcoal_nt,coalesced,pure_instructions
  ^  ~
:485:11: note: change section name to "__text"
 .section __TEXT,__textcoal_nt,coalesced,pure_instructions
  ^  ~

is coming because cctools now sends assembly to clang if clang >= 5.0 is 
installed. It’s harmless.

I don’t think that clang being the assembler is bringing out the compact_unwind 
or text_reloc errors, but I’d have to experiment with that to be certain. To do 
that, deactivate clangs >= 5.0 before your gcc48 build, for example.

Back when gcc48 was being implemented, and even now when Iain tests the builds 
of gcc on older systems, he does it “neat” on an unmodified i386 Leopard 
system, he does not do it in MacPorts.

So our changes, like a newer linker, or sending assembly to clang instead of 
“gas” , can have unexpected consequences sometimes.

Iain always says that he’s prepared to fix gcc for older systems (apparently he 
has gcc10 building on 10.4 PPC and 10.4 Intel and up), but he’s not going to 
work inside MacPorts to undo our shenanigans.

I have some personal patches that force our builds of gcc to use the older 
“gas” assembler that fixes up the build gcc8+ on older systems, but as things 
are working quite well at present. I haven’t started forcing those changes into 
MacPorts as yet.

And - you know that i have built most of this software and put it on the ‘older 
systems’ binary site I sent you the link to, so if you get frustrated, you can 
download the prebuilt binaries from there.

Ken

Re: failure to link most programs on Leopard

[Jeffrey Walton]

On Sat, Nov 14, 2020 at 3:56 PM Ken Cunningham
 wrote:
> ...
> Back when gcc48 was being implemented, and even now when Iain tests the 
> builds of gcc on older systems, he does it “neat” on an unmodified i386 
> Leopard system, he does not do it in MacPorts.
>
> So our changes, like a newer linker, or sending assembly to clang instead of 
> “gas” , can have unexpected consequences sometimes.

You can disable Clang's integrated assembler with -no-integrated-as,
if needed. I've had to use it several times because Clang cannot
consume the same programs as GCC even though Clang defines __GNUC__.

Jeff

Re: failure to link most programs on Leopard

[Ken Cunningham]

> On Nov 14, 2020, at 1:39 PM, Jeffrey Walton  wrote:

> You can disable Clang's integrated assembler with -no-integrated-as,
> if needed. I've had to use it several times because Clang cannot
> consume the same programs as GCC even though Clang defines __GNUC__.
> 
> Jeff

However, our “cctools” port modifications have changed the “as” driver to send 
the assembly right back to “clang” again (if clang >= 5.0 is installed) …

I’m not sure how this loop would end up, in the end — I have not tested that 
one.

K

zsh hanging on Big Sur w/2.6.4

[Mike Cappella]

I’m having an issue with zsh hanging on Big Sur, just installed after 
installing MacPorts via the new Big Sur 2.6.4 installer.  It cannot be quit or 
interrupted.

Anyone else having issues, or not?

Re: zsh hanging on Big Sur w/2.6.4

[Andrew Udvare]

> On 2020-11-14, at 17:52, Mike Cappella  wrote:
> 
> I’m having an issue with zsh hanging on Big Sur, just installed after 
> installing MacPorts via the new Big Sur 2.6.4 installer.  It cannot be quit 
> or interrupted.
> 
> Anyone else having issues, or not?

I had a similar issue with GNU rm, date, unzip. The `date` command was hanging.

I don't know what happened but after a while it stopped doing this. I could not 
even attach dtruss to the process.

My best guess is it has something to do with code signing.

Port Application Issues (Launching Issues)

[Jonathan Allen via macports-users]

I fully installed the Mac Ports application successfully, and then once that 
was finished I entered “sudo port install homebank” in the command line, no 
errors were presented. I then went to the “MacPorts” folder in the Application 
Folder and didn’t see the “HomeBank” application icon in there at all, as if it 
wasn’t installed. I double-checked using “port info homebank” and the output 
stated it had been installed.

The problem is, I can’t find the application icon at all and even searched the 
MacPorts help pages to see if there was a “launch this application” command and 
didn’t see one. I am a first time MacPorts user. How do I fix this so I can 
launch the HomeBank application, or have it show up in the MacPorts folder of 
the applications folder.

If it helps, I am using the BigSur version of MacPorts.

- Jonathan

Re: Port Application Issues (Launching Issues)

[Ryan Schmidt]

On Nov 14, 2020, at 17:53, Jonathan Allen wrote:

> I fully installed the Mac Ports application successfully, and then once that 
> was finished I entered “sudo port install homebank” in the command line, no 
> errors were presented. I then went to the “MacPorts” folder in the 
> Application Folder and didn’t see the “HomeBank” application icon in there at 
> all, as if it wasn’t installed. I double-checked using “port info homebank” 
> and the output stated it had been installed.
> 
> The problem is, I can’t find the application icon at all and even searched 
> the MacPorts help pages to see if there was a “launch this application” 
> command and didn’t see one. I am a first time MacPorts user. How do I fix 
> this so I can launch the HomeBank application, or have it show up in the 
> MacPorts folder of the applications folder.
> 
> If it helps, I am using the BigSur version of MacPorts.

MacPorts is not an application, and not all ports install applications either. 
Use "port contents homebank" to see what it did install. You should find that 
it installed a program /opt/local/bin/homebank which you can launch from your 
Terminal.