Re: [MacPorts-announce] MacPorts 2.6.4 has been released

[Dave Horsfall]

On Sat, 14 Nov 2020, Joshua Root wrote:

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.


Which reminds me: OK on latest (and last) Sierra, on an early MacBook Pro 
(13", mid-2010); I'm not sure if I want to try High Sierra yet (the 
upgrade failed twice for various reasons on the earlier MacBook, which is 
now dead in the water).


It is a testament to my confidence in the MacPorts developers that I am 
willing to upgrade right away :-)


-- Dave

Re: Leopard Intel compiler availability --> was Re: rebuild a package without an update

[Ken Cunningham]

> > Perhaps I can upgrade it, but that would be a soldering project.
> 
> Aha! That explains it. I was not aware that such machines existed. I 
> thought the first Intel Minis had 2 slots that could take 1GB DIMMs.
> 
> -- 
> Bill Cole
Bill, you may be correct! My last bit of internet sleuthing agrees with you… I 
think it is about time I took that beast apart and looked inside.

Ken

Re: Leopard Intel compiler availability --> was Re: rebuild a package without an update

[Bill Cole]

On 29 Nov 2020, at 16:11, Ken Cunningham wrote:

I have a MacMini 1,1 with 1GB of Ram that runs either MacOS X 10.4 or 
10.5. It doesn’t have enough ram to run 10.6. Perhaps I can upgrade 
it, but that would be a soldering project. I use it to build 
TenFourFox for Intel which I upload to the TenFourFox SourceForge 
site, amongst other things.


Aha! That explains it. I was not aware that such machines existed. I 
thought the first Intel Minis had 2 slots that could take 1GB DIMMs.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: manually upgrade some ICU dependencies - recursion between libsxslt and vala

[Ken Cunningham]

> $ xsltproc dyld: Library not loaded: /opt/local/lib/libicui18n.65.dylib 
> Referenced from: /opt/local/bin/xsltproc Reason: image not found Trace/BPT 
> trap 

This shows that icu was upgraded to version 67, but that port is still linked 
against 65.

Usually a rev-bump would have taken care of this, but you’re doing some 
occasionally hanky things, and might run into a situation where you have to fix 
it yourself. So either let rev-upgrade do it’s thing, or uninstall xsltproc and 
rebuild it from scratch against the current ICU.


Now if vala builds but won’t destroot — that is something else altogether. You 
have to run things with “-v” to see what the error is.


You do have to expect a little bit of self-care when you’re trying to run the 
current gimp2 +quartz on an OS that came out in 2006. Think of it like being on 
a hike in the woods, where you need to be somewhat self-reliant to survive. And 
 all the MacPorts and Apple OS details you will learn! To be honest, making the 
current OS versions work properly is like a walk in the park after fixing these 
kinds of issues!

You can sometimes get yourself out of a tricky situation with a temporary 
symlink, a transient downgrade to the previous version of something to build 
something you need, or some behind-the-scenes use of install_name_tool, but you 
do have to know what you’re up to if you’re doing that, and clean up after 
yourself.

If it is a systemic MacPorts issue rather than something you did yourself, it’s 
worth making a ticket. But usually — it’s something you did :>


Ken

manually upgrade some ICU dependencies - recursion between libsxslt and vala

[Riccardo Mottola via macports-users]

Hi,

I was about to fail a bug, ascii doc doesn't build for me, nor does 
vala.


I get this issue, e.g.

:info:build a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 
--stringparam navig.graphics 0 --stringparam admon.textlabel 1 
--stringparam admon.graphics 0  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_asciidoc/asciidoc/work/asciidoc-asciidoc-py3-245751e/docbook-xsl/manpage.xsl" 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_asciidoc/asciidoc/work/asciidoc-asciidoc-py3-245751e/doc/asciidoc.1.xml" 
returned non-zero exit status -5


and Vala:
Making all in manual
make[3]: Entering directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_vala/vala/work/vala-0.50.2/doc/manual'

/opt/local/bin/xsltproc \
--xinclude \
--path . \
--output devhelp/vala-0.50.devhelp2 \
./devhelp.xsl \
./manual.xml
dyld: Library not loaded: /opt/local/lib/libicui18n.65.dylib
  Referenced from: /opt/local/bin/xsltproc
  Reason: image not found


However, I think the issue is related to "xlstproc"... :

$ xsltproc
dyld: Library not loaded: /opt/local/lib/libicui18n.65.dylib
  Referenced from: /opt/local/bin/xsltproc
  Reason: image not found
Trace/BPT trap


I did run port-revupgrade, which wants to rebuild libxslt but it 
pulls in vala, which it can't compile because it runs xsltproc:


Continue? [Y/n]:
--->  Computing dependencies for xar
--->  Cleaning xar
--->  Computing dependencies for libxslt
--->  Cleaning libxslt
--->  Computing dependencies for vala
--->  Fetching archive for vala
Warning: Your DNS servers incorrectly claim to know the address of 
nonexistent hosts. This may cause checksum mismatches for some ports. 
See this page for more information: 

--->  Attempting to fetch vala-0.50.2_0.darwin_9.i386.tbz2 from 
http://lil.fr.packages.macports.org/vala
--->  Attempting to fetch vala-0.50.2_0.darwin_9.i386.tbz2 from 
http://packages.macports.org/vala
--->  Attempting to fetch vala-0.50.2_0.darwin_9.i386.tbz2 from 
http://fco.it.packages.macports.org/vala

--->  Building vala
--->  Staging vala into destroot
Error: Failed to destroot vala: command execution failed

can I somehow force to rebuild libsxslt without rebuilding vala? it's 
vicious !


Riccardo

Re: Leopard Intel compiler availability --> was Re: rebuild a package without an update

[Ken Cunningham]

> Can you explain any practical justification for supporting Leopard on 
> Intel?
> 
> I'm not suggesting that it's in any way "wrong" but I just can't see 
> where the utility for such machines is. I'm still making use of a 2006 
> Core Duo iMac which is 10.6/i386, so I'm familiar with the fact that the 
> very first Intel Mac can run 10.6 and that for a variety of reasons it 
> is a generally good idea to do that update. I'm curious about what your 
> thinking is.

No doubt, it is the lowest on my list, and I fix the other compilers, linkers, 
and cctools first. But it has some uses. 

I have a MacMini 1,1 with 1GB of Ram that runs either MacOS X 10.4 or 10.5. It 
doesn’t have enough ram to run 10.6. Perhaps I can upgrade it, but that would 
be a soldering project. I use it to build TenFourFox for Intel which I upload 
to the TenFourFox SourceForge site, amongst other things.

For building things for 10.4 and 10.5 PPC (of which I currently have 8 running 
machines) it’s sometimes handy to buzz something up on 10.4 or 10.5 Intel. For 
example my 10.5 VM runs with 8 processors and 16 GB of RAM on a dual Quad-Core 
Intel Xeon, so I can build things very quickly there to test out build issues.

And there are people (like Riccardo, and many others) who are just stuck on the 
nostalgia or the system or the software they have or … who knows why? If 
MacPorts _can_ support them without too much trouble, and if there are 
interested people around like me and others who don’t mind doing it from time 
to time — why not? It’s all one big family, and keeps people in MacPorts rather 
than floating off to the other options.

You’ll be really happy with the 68030 SE/30 that is currently running on my 
desk, and the 30 other Mac systems I keep running here in the Mac Museum :>

I would not dare to interfere with progress — if there is a decision that 
involves moving MacPorts forward to arm64 vs maintaining support for 10.4 
Intel, well that is not even a question to ask.

I have ways for that. libSDL2 runs fairly well on 10.4 and 10.4 PPC and Intel, 
but I keep that in my custom overlays for people to find. So hopefully no sweat 
off anyone’s brow about this.

Ken

Re: Leopard Intel compiler availability --> was Re: rebuild a package without an update

[Bill Cole]

On 29 Nov 2020, at 6:55, Riccardo Mottola via macports-users wrote:

This is all on 10.5/i386 - then I already started my luck on PPC, then 
10.6/universal - and last 10.5/x86_64


Can you explain any practical justification for supporting Leopard on 
Intel?


I'm not suggesting that it's in any way "wrong" but I just can't see 
where the utility for such machines is. I'm still making use of a 2006 
Core Duo iMac which is 10.6/i386, so I'm familiar with the fact that the 
very first Intel Mac can run 10.6 and that for a variety of reasons it 
is a generally good idea to do that update. I'm curious about what your 
thinking is.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Fix for postfix not launching reliably at boot time

[Bill Cole]

On 29 Nov 2020, at 6:02, Gerben Wierda via macports-users wrote:

I think I shared this before, but I’m not certain so I am doing so 
now (again).


The MacPorts postfix master process will not launch reliably at boot 
if it is set up with ‘port load postfix’. The reason for the 
unreliable boot is that macOS during boot for about 60 seconds or so 
claims port 25 (and 587) because it launches its own postfix, then 
quickly kills it. When Apple’s postfix master launches first (there 
is no control in launchd what launches first) this can block the 
MacPorts version, which then fails.


By changing /etc/postfix/master.cf of Apple’s postfix the boot by 
MacPorts launches reliably.


This means patching Apple’s files, which I frown upon, but I’m 
still using Mojave and I think Apple updates leave master.cf alone and 
macOS itself doesn’t really use postfix, it is a leftover. I don’t 
know if this is still possible in later versions of macOS. If it 
isn’t because Apple has locked these down, a more intelligent 
startup command could be written that works around this macOS 
behaviour.


Another approach is to boot into "Recovery Mode" and disable the launchd 
startup:


   launchctl unload -w 
/System/Library/LaunchDaemons/com.apple.postfix.master.plist


If you've persistently disabled SIP (which you really shouldn't...) you 
can do that as root without booting into Recovery Mode.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Leopard Intel compiler availability --> was Re: rebuild a package without an update

[Ken Cunningham]

I have a patch for gcc that forces it to use the old assembler ever if 
clang-5.0 is installed. I haven't pushed it yet, but I can send it to you if 
you like.

The binaries server I put up basically _is_ an Intel builder...covers 10.4 & 
10.5 PPC and Intel. Use it if you want.

Glad you're well! British Columbia is going through a major second wave 
noweveryone at home again...waiting for vaccine...

K


> On Nov 29, 2020, at 03:55, Riccardo Mottola  
> wrote:
> 
> Hi Ken,
> 
> 
>> On 2020-11-18 17:07:43 + Ken Cunningham 
>>  wrote:
>> 
>> Riccardo et al,
>> I have finished rebuilding all the common compilers for Leopard Intel i386, 
>> up to clang-9.0.
>> It is apparently possible now to build up to gcc-10 on Tiger and up, and I 
>> have built some of these, but MacPorts has presently held some older systems 
>> back a bit to avoid overly-complicating things without benefit for now.
>> Riccardo: All these compilers are available on the older systems prebuilt 
>> binaries site.
> 
> that's an impressive list... right now I only need gcc 48 and gcc6 (and 
> newer? soon?) gcc 4.8 being needed for TenFourFox work, all the rest is 
> updated enought o work with gcc6 (which is actually a life-saver when clang 
> fails and also a testbed, since on PPC then I use gcc).
> 
> I still think I should be able to build from sources, a bit "proud" bu also a 
> test to see everything still chains up in MacPorts... tweaking a command line 
> or getting some order is acceptable, but e.g. deactivating all clang ports is 
> rather not.
> We should find a way to do do without clang with options inside the portfile 
> or at least on the command line.
> 
> This is all on 10.5/i386 - then I already started my luck on PPC, then 
> 10.6/universal - and last 10.5/x86_64
> 
> I updated 10.7 all fine instead, except one nasty package, syntax-highlighter 
> which is broken since years (a blocker for a fresh install though).
> 
> Maybe it makes sense to ads an autobuilder 10.5 instance ?
> 
> 
> Riccardo
> 

Re: rebuild a package without an update

[Ryan Schmidt]

On Nov 29, 2020, at 06:24, Riccardo Mottola wrote:

> On 2020-11-17 00:30:33 + Ryan Schmidt wrote:
> 
>> On Nov 16, 2020, at 17:58, Riccardo Mottola wrote:
> 
>>> Here were are in the situation that if, for some upstream reason, libxml2 
>>> stops compiling with gcc 4.2, the user has no workaround and is stuck in an 
>>> endless dependency.
>> If such a situation were to arise, then indeed we would want to do something 
>> about it. We do have automated build machines for Mac OS X 10.6 and later so 
>> if such a situation did arise we would probably notice it on the build 
>> machines. As far as I know, we do not have such a situation at present.
> 
> No, luckily we don't - some packages still compile with Apple system.
> 
> The only issue is that to do that build of libxml2 successfully, I had to 
> deactivate all clang compilers. Something similar I had to do more recently 
> to compile gcc48 and gcc6, although coming from a different error).

Then we may have a bug that needs to be fixed, because you're not supposed to 
need to do that.


> Maybe a 10.5 autobuilder wouldn't be a bad idea, 32bit.

We used to have a 10.5 PowerPC builder but the hardware failed. I may revive it 
some day. We have never had a 10.5 Intel builder because all Intel Macs can and 
should be upgraded to Snow Leopard or later. I have no plans to add a 10.5 
Intel builder at this time.

Re: failure to link most programs on Leopard

[Riccardo Mottola via macports-users]

Hi,


On 2020-11-14 22:29:52 + Ken Cunningham  
wrote:

> 
> 
>> 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.


perhaps this cctools modification is too much. DO you remember why it was done 
in the first place?

I'd be more inclined to say if you use clang, use clang assembler, if you use 
gcc, gas. That's usually what I do on linux when I have issues. Mixing the two 
issues just causes stranger issues (allt he mess we have when building 
TenFourFox or ArcticFox where sub-projects seem to work better with another 
compiler)

Riccardo

Re: failure to link most programs on Leopard

[Riccardo Mottola via macports-users]

Hi Ken!


On 2020-11-14 20:56:20 + Ken Cunningham  
wrote:

> 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.

Good to know it is harmless. As a software developer, when I have a fatal 
error, I go up to see if there were any warnings before since they could (or 
not) be related.

> 
> 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.

That's what I ended doing. What is annoying is that gcc6 has exactly the same 
issue though!

> 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.

eheh, wow, even gcc 10 sounds super cool, that would give us access at least to 
"minor" Objective-C upgrades that gcc got (although the full new stuff is 
unfortunately still only in clang).

> 
> 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.

given the gcc problems, libxml2 problems, etc... a more convenient way to build 
a port with clang or gas is needed, the trick og "cctools uses clang always" is 
perhaps too invasive.

> 
> 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.

Right now I am still trying, since anyway I have 10.5-64bit to update later.

Riccardo

Re: rebuild a package without an update

[Riccardo Mottola via macports-users]

Hi,

On 2020-11-17 00:30:33 + Ryan Schmidt  
wrote:





On Nov 16, 2020, at 17:58, Riccardo Mottola wrote:


Here were are in the situation that if, for some upstream reason, 
libxml2 
stops compiling with gcc 4.2, the user has no workaround and is 
stuck in an 
endless dependency.


If such a situation were to arise, then indeed we would want to do 
something 
about it. We do have automated build machines for Mac OS X 10.6 and 
later so 
if such a situation did arise we would probably notice it on the 
build 
machines. As far as I know, we do not have such a situation at 
present.


No, luckily we don't - some packages still compile with Apple system.

The only issue is that to do that build of libxml2 successfully, I had 
to deactivate all clang compilers. Something similar I had to do more 
recently to compile gcc48 and gcc6, although coming from a different 
error).


Maybe a 10.5 autobuilder wouldn't be a bad idea, 32bit.

Riccardo

Re: failure to link most programs on Leopard

[Riccardo Mottola via macports-users]

Hi,


On 2020-11-14 20:38:43 + Ryan Schmidt  wrote:

> 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.


I appreciate not trying to build things... Just at the beginning of this year 
everything was very smooth, now we have iccups, but I bet we can solve them.
It is actually impressive what MacPorts deliver to these "older system" which 
Apple and sometimes even upstream declared abandoned.

Maybe it wasn't that flag, but somethign which caused that... I'll see how 
10.5/x86_64 will do

Riccardo

Re: Leopard Intel compiler availability --> was Re: rebuild a package without an update

[Riccardo Mottola via macports-users]

Hi Ken,


On 2020-11-18 17:07:43 + Ken Cunningham 
 wrote:



Riccardo et al,

I have finished rebuilding all the common compilers for Leopard Intel 
i386, 
up to clang-9.0.


It is apparently possible now to build up to gcc-10 on Tiger and up, 
and I 
have built some of these, but MacPorts has presently held some older 
systems 
back a bit to avoid overly-complicating things without benefit for 
now.


Riccardo: All these compilers are available on the older systems 
prebuilt 
binaries site.


that's an impressive list... right now I only need gcc 48 and gcc6 
(and newer? soon?) gcc 4.8 being needed for TenFourFox work, all the 
rest is updated enought o work with gcc6 (which is actually a 
life-saver when clang fails and also a testbed, since on PPC then I 
use gcc).


I still think I should be able to build from sources, a bit "proud" bu 
also a test to see everything still chains up in MacPorts... tweaking 
a command line or getting some order is acceptable, but e.g. 
deactivating all clang ports is rather not.
We should find a way to do do without clang with options inside the 
portfile or at least on the command line.


This is all on 10.5/i386 - then I already started my luck on PPC, then 
10.6/universal - and last 10.5/x86_64


I updated 10.7 all fine instead, except one nasty package, 
syntax-highlighter which is broken since years (a blocker for a fresh 
install though).


Maybe it makes sense to ads an autobuilder 10.5 instance ?


Riccardo

Re: failure to link most programs on Leopard

[Riccardo Mottola via macports-users]

Hi,

after some days with the "head under water" I had time to resume work on 
MacPorts upgrades.

I restarted and the error I pasted below happened for me e.g. in gcc 48 and 
gcc6 upgrade. 

On 2020-11-14 20:31:40 + Ken Cunningham  
wrote:

>> 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.


While what you proposed makes sense to me, it didn't help in my case. Strange, 
gcc 4.8 gets rebuild trarely, but gcc6 built without issues just somemonths 
ago, I believe.
I just pasted your snipped into the port...

What helped was deactivating all clangs, then both gcc48 and gcc6 were happy, 
then reactivating.

This "proves" that the issue is the AS going through clang. 

Riccardo

Fix for postfix not launching reliably at boot time

[Gerben Wierda via macports-users]

I think I shared this before, but I’m not certain so I am doing so now (again).

The MacPorts postfix master process will not launch reliably at boot if it is 
set up with ‘port load postfix’. The reason for the unreliable boot is that 
macOS during boot for about 60 seconds or so claims port 25 (and 587) because 
it launches its own postfix, then quickly kills it. When Apple’s postfix master 
launches first (there is no control in launchd what launches first) this can 
block the MacPorts version, which then fails. 

By changing /etc/postfix/master.cf of Apple’s postfix the boot by MacPorts 
launches reliably.

This means patching Apple’s files, which I frown upon, but I’m still using 
Mojave and I think Apple updates leave master.cf alone and macOS itself doesn’t 
really use postfix, it is a leftover. I don’t know if this is still possible in 
later versions of macOS. If it isn’t because Apple has locked these down, a 
more intelligent startup command could be written that works around this macOS 
behaviour.

14,15c14,16
< smtp  inet  n   -   n   -   1   postscreen
< smtpd pass  -   -   n   -   -   smtpd
---
> # GW: Commented postscreen, smtpd commands as Apple's postfix master gets run 
> for 60 sec at boot
> #smtp  inet  n   -   n   -   1   postscreen
> #smtpd pass  -   -   n   -   -   smtpd
18,19c19,20
< submission inet n   -   n   -   -   smtpd
<   -o smtpd_tls_security_level=encrypt
---
> #submission inet n   -   n   -   -   smtpd
> #  -o smtpd_tls_security_level=encrypt

Yours,

G