Re: expat 2.2.2 build fail on Snow Leopard

[Kenneth F. Cunningham]

On 2017-07-15, at 8:36 PM, Richard L. Hamilton wrote:

> bypass this error by defining XML_POOR_ENTROPY

looks like you have to do the above.

Ken

Re: expat 2.2.2 build fail on Snow Leopard

[Kenneth F. Cunningham]

Too bad it wasn't a 'first try" fix. You have a few more options. Sometimes you 
can dig around in the configure script or CMakeLists.txt file and find the 
proper spot or item that way.

Or you can define  XML_POOR_ENTROPY directly in the configure.env and/or 
build.env variables in the Portfile. There is a description how to do that in 
the "port phases" part of the macports website, IIRC.

It still appears to me that is what needs to get defined on the build line. How 
it gets there remains to be discovered, it seems.

Best of luck!

Ken



On 2017-07-16, at 8:57 AM, Richard L. Hamilton wrote:

> Well, that didn't work; also didn't work using configure.cppflags-append 
> instead.  As far as I can tell, it didn't pick up the change to the 
> environment variable, at least I didn't see anything in the log indicating 
> that it did; the only reference to XML_POOR_ENTROPY was still in the error 
> message.
> 
> 
>> On Jul 16, 2017, at 00:29, Kenneth F. Cunningham 
>>  wrote:
>> 
>> Maybe something similar to this in the Portfile would work. Please give it a 
>> try. If it does, this might be your first pull request! -- Ken
>> 
>>   if {${os.platform} eq "darwin" && ${os.major} < 11} {
>>   configure.cflags-append-DXML_POOR_ENTROPY=1
>>   }
>> 
>> 
>> On 2017-07-15, at 9:03 PM, Kenneth F. Cunningham wrote:
>> 
>>> 
>>> On 2017-07-15, at 8:36 PM, Richard L. Hamilton wrote:
>>> 
>>>> bypass this error by defining XML_POOR_ENTROPY
>>> 
>>> looks like you have to do the above.
>>> 
>>> Ken
>> 
> 

LionPorts

[Kenneth F. Cunningham]

To go along with my other shadow repositories tuned for older versions of 
MacPorts, I've initiated a "LionPorts" version.

Although the _vast_ majority of ports build and work correctly on systems all 
the way back to Tiger, it is not always possible or practical to keep all ports 
retroactive to the oldest systems in the active MacPorts repository.

These repositories contain pegged versions of ports at the last version that 
worked on various systems, and in some cases modified versions of ports that 
work on these older systems but with fixes that haven't (as yet) been accepted 
into the current MacPorts repository for one reason or another. You are free to 
use them, and contribute to them, as you wish. No guarantees, of course, but 
these have all been tested out to work for me on these systems.

TigerPorts
https://github.com/kencu/TigerPorts

LeopardPorts
https://github.com/kencu/LeopardPorts

SnowLeopardPorts
https://github.com/kencu/SnowLeopardPorts

LionPorts
https://github.com/kencu/LionPorts





Ken

Re: What on earth happened with Perl?

[Kenneth F. Cunningham]

Looks like it is a security issue, and has been back ported into at least some 
perl 5.24 versions.










You can override this on your own system by setting an environment variable, 
amongst other methods.



Hope this helps at least a bit,

Ken




On 2018-03-11, at 5:52 PM, Dave Horsfall wrote:

> As the subject sez...
> 
> After being bitten by Perl 5.26 apparently being surreptitiously installed 
> last week and breaking modules[*] in the process (@INC no longer includes 
> "."), my regular Monday "port upgrade outdated" seemed to deactivate Perl 
> 5.24 (and refusing to break some dependencies) and installed 5.26, which I 
> thought it already did...
> 
> Before I post logs etc, could I please have a short summary as to what the 
> hell is happening?  I can't be the only one being done over like this...
> 
> I note that FreeBSD is still conservatively staying with 5.24, and my Penguin 
> box seems to be araldited onto 5.20, so why the rush for 5.26 that is known 
> to be backwards-incompatible?
> 
> [*]
> At least mine still works after "-I." whilst I'm developing it...
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
> If you are a Gmail/Yahoo/etc user please see http://www.horsfall.org/spam.html

Re: Is there and "rdist" for Mac?

[Kenneth F. Cunningham]

On 2018-03-15, at 9:30 PM, Dave Horsfall wrote:


> Running "locate rdist" on the Mac is less than helpful, so is there a tool 
> similar to BSD's "rdist"?
> 

Wow, that's old. 1998.

Here's what I have so far, which bogs down in the build pretty early due to 20 
year old weirdness, I guess….

Ken






Portfile
--
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4

PortSystem  1.0

namerdist
version 6.1.5
categories  sysutils
license GPL-2
platforms   darwin
maintainers nomaintainer

#http://www.magnicomp.com/download/rdist/rdist-6.1.5.tar.gz

description Distribute software

long_description${description}

homepagehttp://www.magnicomp.com
master_siteshttp://www.magnicomp.com/download/rdist/

checksums   rmd160  7344e137ab74192aeb2517fd63b4bbed0f70e039 \
sha256  
2bb0d0f5904eadc9e7fe3d60c15389d6897fcf884211070e289a6c710ff37f96

patch.pre_args  -p1
patchfiles  rdist-darwin.patch

use_configure   no

---

and 


rdist-darwin.patch
---



  Rdist for Darwin 6.x/7.x

   Eric Myers
 Vassar College
 Department of Physics and Astronomy
Poughkeepsie, New York 12604 USA



 6 January 2004

  This file contains the diffs required to get the handy Unix tool rdist
to build on Darwin, aka Mac OS X, including both 10.2 (Darwin 6.x, aka
"Jaguar") and 10.3 (Darwin 7.x, aka "Panther").  The diffs are against
the source code in the file rdist-6.1.5.tar as distributed from
http://www.MagniComp.com/rdist/ , which you will have to obtain separately.

  For security reasons ssh is prefered over rsh for transport, so the
default transport path is set to /usr/bin/ssh on Darwin, not rsh.

  Be warned that the code for detecting an NFS mount (i.e. -ochknfs)
probably won't work (it has not been tested).  If someone fixes this in
the future it would be nice to also be able to detect an AFS mount.

To apply the patches, begin with the source tar file from MagniComp
and this patch file in the same directory.  Unpack the tar file, cd into
the directory it creates , and then run `patch -p1` from that directory,
like so:

  %  tar xf rdist-6.1.5.tar
  %  cd rdist-6.1.5
  %  patch -p1 <../rdist-6.1.5-darwin.patch

Then build rdist as usual (see the README file for details):

  % make
  % make install
  % make install.man

The rdist and rdistd executables are installed in /usr/local/bin, while
the man pages are installed in /usr/local/share/man/man{1,8}.
You can change these destinations by editing config/mf.darwin .



--PATCHES-BEGIN-HERE-

diff -Naurb rdist-6.1.5/ChangeLog rdist-6.1.5-darwin/ChangeLog
--- rdist-6.1.5/ChangeLog   Mon Nov  9 23:26:38 1998
+++ rdist-6.1.5-darwin/ChangeLogTue Jan  6 11:44:21 2004
@@ -1,3 +1,13 @@
+2004-01-06 Eric Myers 
+   
+   * Ported more generally to Darwin 6.x and 7.x, which includes
+ changing to VAR_STDARG
+   
+2003-07-31  Eric Myers 
+
+   * Ported to Darwin 6.6  (Mac OS X 10.2.6)
+
+   
 1998-11-09  Michael A. Cooper  
 
* Version 6.1.5-RELEASE
diff -Naurb rdist-6.1.5/README rdist-6.1.5-darwin/README
--- rdist-6.1.5/README  Fri Jul 19 13:24:09 1996
+++ rdist-6.1.5-darwin/README   Tue Jan  6 10:39:57 2004
@@ -19,9 +19,9 @@
 indirectly provide full backward compatibility.  See COMPATIBILITY
 below for details.
 
-The current official version of rdist is available via anonymous ftp
-on usc.edu under /pub/rdist.  The current version is always
-retrievable as file "/pub/rdist/rdist.tar.gz".
+The official home of RDist has moved to http://www.MagniComp.com as
+of 12-April-98.
+
 
   CHANGES/FEATURES
 
@@ -80,7 +80,7 @@
 INSTALLATION
 
 1) Determine whether the local machine is running a supported OS by
-   running the command "config/os-type".  If the command reports the
+   running the command "build/os-type".  If the command reports the
local OS is "unknown", then you cannot proceed until rdist is
ported to the local system OS.  (See the PORTING section).
 
@@ -158,6 +158,7 @@
 6) Send me your "os-YOUR_OS.h" and "mf.YOUR_OS" files, along with context
diffs to any other files you changed.
 
+
NOTES
 
 rcmd() vs. rsh(1c)
@@ -179,29 +180,31 @@
All of this information on HP/UX is third-hand.  I don't have 
access to any HP/UX machines to test rdist on.
 
-Unlike HPUX version 7, version 8 does not come standard with yacc
-which is now part of the C/ANSI C Development Bundle.  If that bundle
-is on the system, then rdist compiles fine with the changes to the
-Make

Re: Trouble compiling with gcc 4.8 on 10.5 PowerPC

[Kenneth F. Cunningham]

On 2018-03-17, at 4:17 PM, Andreas Falkenhahn wrote:

> Hi,
> 
> I need to compile C++11 sources for PowerPC OS X so I installed gcc48 using 
> Mac Ports. Although the binary generated by gcc-mp-4.8 actually works, I do 
> get some warning messages which are worrying me.
> 
> When linking my project, I get this warning:
> 
>ld: warning: 32-bit absolute address out of range (0x100521C58 max is 
> 4GB): from _REQUIRED_TAGS + 0x0034 (0x00521C5C) to 0x100521C58
> 
> For reference, this is how I link my project:
> 
>gcc-mp-4.8 -fPIC -dynamiclib -exported_symbols_list exports.def -o 
> macppc48/plugin.dylib macppc48/plugin.o -Llibharu/macppc48 -Llibapng/macppc48 
> -Lpdfium/macppc48 -L../freetype-2.8/macppc48/objs/.libs -lharu -lapng 
> -lpdfjpeg -lfreetype -lcms -lopenjpeg -lagg -lpdfium -lfdrm -lfpdfdoc 
> -lfpdfapi -lfpdftext -lfxcodec -lopenjpeg -lfxcrt -lfxge -lpwl -lformfiller 
> -ljavascript -lpdfiumbase -lfdrm -lfreetype -lpdfjpeg -lagg -lcms -lm -lpwl 
> -lfpdfdoc -lz -lstdc++ -framework AppKit -framework CoreFoundation
> 
> When running my project, I get lots of these errors:
> 
>testprogram(151,0xa0b96820) malloc: *** error for object 0x41384d0: 
> Non-aligned pointer being freed (2)
>*** set a breakpoint in malloc_error_break to debug
> 
> My project is a cross-platform project which already runs fine on many other 
> platforms (x86/x64 Mac; Windows; x86/x64/ppc/arm Linux, etc.) so I'm pretty 
> certain that those issues are not related to bugs in my code but that either 
> something is wrong with gcc 4.8 or that I'm not using it correctly.
> 
> Anyone here who knows how to solve these issues? As I said, despite those 
> warnings the program seems to work correctly but of course these warnings are 
> worrying me and I want them to disappear.
> 
> Thanks!
> 

As a first step, if you don't specifically require gcc-4.8, try instead with 
gcc-6 (macports-gcc-6) which works quite a bit better in most cases.

Also, make sure you have cctools installed, which includes a number of updated 
basic toolchain pieces that help out a lot.

The specific error you're seeing "32-bit absolute address out of range" tends 
to happen when things are compiled with clang-3.4 on PPC, so if you see 
anything being compiled with clang-3.4, rebuild it with gcc-6 instead.

After that, we slog through. It's a great system, PPC, but there are not so 
many of us using it any more. We need to stick together!

Best,

Ken

Re: Trouble compiling with gcc 4.8 on 10.5 PowerPC

[Kenneth F. Cunningham]

On 2018-03-18, at 7:32 AM, Andreas Falkenhahn wrote:

> 
> Thanks, this indeed solved all my problems!

Great!


> There's just one little problem remaining: I cannot use gcc-ar-mp-6 because
> it reports the following error: "Cannot find plugin liblto_plugin.so".

Will see how this is on my PPC machines at home.


> 
> Another question: How can I make my program compatible with 10.4?

The symbols and linkage and construction are os version dependent. 

The easiest thing to do would be to install ibgcc on the 10.4 system using 
MacPorts, and see if that works to support your application when you build it 
on 10.5 and move it backwards. It might work just doing that. It might not.

If not, then it gets complicated. Cameron Kaiser builds TenFourFox for PPC 
machines, a Firefox clone. It's about as complicated a piece of software that 
exists for PPC these days, and he has all these issues. He has a lot of 
documentation regarding how he does this on his github repo, but in essence, 
builds against the 10.4u SDK on 10.5, and sets the deployment target to 10.4. 
Then moves the parts into the application bundle and rejigs the library links.

All rather complicated, but interesting in how it's done.

Far easier to just build your application on 10.4 PPC in the first place. 
That's what I do for most things.


>  I'm also running MorphOS on my PowerPC Macs. This
> is another PPC operating system inspired by AmigaOS.

I'll check that out. Thanks for the tip.

Best,

K

Re: portindex fails due to portfile parsing

[Kenneth F. Cunningham]

On 2018-03-20, at 4:22 PM, Jeremy Huddleston Sequoia wrote:
> 
>  I cringe at trying to get an older Xcode's toolchain to work with a newer 
> SDK.
> 
> 

Perhaps I shouldn't even say it, but here's what I do:

symlink into the Xcode SDK the following toolchain bits from current MacPorts 
installs:

clang
clang++
ld64
strings
nm

set the compiler to clang 1.0 and the standard lib to libc++.

And a tremendous amount of things then build on 10.6.8.

Now I will duck before someone punches me.

Ken

Re: Trouble compiling with gcc 4.8 on 10.5 PowerPC

[Kenneth F. Cunningham]

On 2018-03-18, at 8:44 AM, Kenneth F. Cunningham wrote:


>> There's just one little problem remaining: I cannot use gcc-ar-mp-6 because
>> it reports the following error: "Cannot find plugin liblto_plugin.so".
> 

Looks like this is just broken on all MacPorts versions of gcc, for example on 
this Intel 10.7.5 box I have with me now:

$ /opt/local/bin/x86_64-apple-darwin11-gcc-ar-mp-7
/opt/local/bin/x86_64-apple-darwin11-gcc-ar-mp-7: Cannot find plugin 
'liblto_plugin.so'

Re: jupyter-2.7 vs. ipython

[Kenneth F. Cunningham]

On 2018-03-21, at 11:49 PM, pagani laurent via macports-users wrote:

> pkg_resources.DistributionNotFound: The 'testpath' distribution was not found 
> and is required by nbconvert
> 

Looks like you should install py27-testpath and see if that fixes it.

Best,

Ken

re: Macports Gnucash needs different settings locations?

[Kenneth F. Cunningham]

Fort gtk2 and gtk3 based ports, the following link may be of use regarding 
fonts, icons, window appearance, etc:



Hope this is helpful.

Ken

Re: rdepof:wine-devel +x11 +universal fails on installing xattr

[Kenneth F. Cunningham]

On 2018-09-07, at 1:57 PM, Ryan Schmidt wrote:


> The problem is that you are asking MacPorts to install *all* of wine-devel's 
> recursive dependencies with the universal variant:
> 
> On Sep 7, 2018, at 12:19, Gijs Vermeulen wrote:
> 
>> I tried running port install -v rdepof:wine-devel +x11 +universal but it 
>> fails when it tries to install xattr.
> 
> That includes the xattr port which you don't need.


I guess the real problem is that xattr is not a dependency on almost any 
system, and so it should not come into the list when you look for the rdeps.

That sounds like a base bug.

Ken

Re: rdepof:wine-devel +x11 +universal fails on installing xattr

[Kenneth F. Cunningham]

On 2018-09-07, at 5:20 PM, Ryan Schmidt wrote:


>> I guess the real problem is that xattr is not a dependency on almost any 
>> system, and so it should not come into the list when you look for the rdeps.
>> 
>> That sounds like a base bug.
> 
> What, specifically, do you think the bug is?
> 
> Are you saying that you don't want rdeps to include bin or lib dependencies 
> that are already satisfied? Why would that be good?
> 
> 

The bug would be that xattr is put forward as an dependency on systems where it 
is not needed.

ie

port echo rdepof:wine-devel +x11 +universal

should not list "xattr" as a dependency on any system other than 10.4.


Ken

qt5-x11 project?

[Kenneth F. Cunningham]

As qt5 moves along it is using new SDK features (as fully expected) and in the 
process leaving behind lots of systems.

Patching qt5 to use older SDKs is hard as they use non-trivial features. Adding 
these features to older MacOS versions via the legacysupport PG is also very 
difficult / nearly impossible as they are generally complex MacOS technologies 
that aren't backportable.

It seems the only long-term solution here would be to somehow enable a qt5-x11 
version to build on MacOS (there once was a qt4-x11 version, so it's perhaps 
not impossible), and then transition systems to that once they reach a certain 
vintage.



Ken

Re: clang++'s (c++17) support

[Kenneth F. Cunningham]

This might be the change that gets us installing a new version of libc++ for 
more systems...

There are different versions of libc++ -- I'm not certain if the newly built 
versions are fully compatible with old versions. If not, and we replace the old 
system one with the new one, a mess will ensue.

There is also no easy way right now to switch back and forth between the system 
libc++ and a new macports replacement for the system libc++. People would have 
to do that manually, by booting into the recovery partition and running the 
terminal app, maybe?

There is a way to install a new libc++ in parallel with the system one, and 
using some DYLD* magic, have MacPorts-built software use that. I have no 
practice with that.

Ken

Re: nm issue with gimp on 10.5

[Kenneth F. Cunningham]

> On Aug 9, 2019, at 06:32, Riccardo Mottola wrote:
> 
> > I am re-building current GIMP on 10.5 (I have a couple of local patches to 
> > adapt it, last time they gave me a nice working app).
> > 
> > Buld fails for me with:
> > 
> > 
> > .0 -lintl -Wl,-framework -Wl,CoreFoundation -lbabl-0.1   -ljpeg
> > libtool: link: /usr/bin/nm -p  .libs/gimpmodule.o .libs/pygimp-item.o 
> > .libs/pygimp-display.o .libs/pygimp-drawable.o .libs/pygimp-image.o 
> > .libs/pygimp-parasite.o .libs/pygimp-pdb.o .libs/pygimp-tile.o 
> > .libs/pygimp-vectors.o   |  | /opt/local/bin/gsed 's/.* //' | sort | uniq > 
> > .libs/gimp.exp
> > ../../libtool: eval: line 1734: syntax error near unexpected token `|'
> > ../../libtool: eval: line 1734: `/usr/bin/nm -p .libs/gimpmodule.o 
> > .libs/pygimp-item.o .libs/pygimp-display.o .libs/pygimp-drawable.o 
> > .libs/pygimp-image.o .libs/pygimp-parasite.o .libs/pygimp-pdb.o 
> > .libs/pygimp-tile.o .libs/pygimp-vectors.o   |  | /opt/local/bin/gsed 's/.* 
> > //' | sort | uniq > .libs/gimp.exp'
> > make[4]: *** [gimp.la] Error 1
> > 
> > 
> > I have already seen this issue months ago, perhaps in another port, I don't 
> > remember where, the nm version used is too old and using the MacPorts one 
> > should fix it.
> > 
> > How do I accomplish this? = tried setting NM on the command line but it 
> > doesn't ork.
> > 
> > I guess the portfile needs a hack... and, in case, can it be done for 
> > everybody in the official portfile?
> 
> Well the obvious problem in the above output is the two pipes next to each 
> other: "|  |". That's what's causing the system error, and it wouldn't matter 
> what version of nm you're using. There's obviously supposed to be some other 
> program being called between those pipes, a program which perhaps is not 
> being found on your system. I don't know what that program is; you'd have to 
> read the build system files and see if you can find the variable that's 
> between those two pipes and from that variable name figure out what program 
> it's meant to be.
This is a rather weird error, but it indeed is caused by a too-old version of 
NM. Forcing a newer NM does fix it.

Before pounding on me about it, I didn't figure this out, so don't blame me for 
the seeming inconsistencies of it.  Somewhere back in the ancient MacPorts 
tickets archives, Jeremy sorted out that when the version of NM was too old it 
caused this odd error. So feel free to ask him why this presents itself this 
way.

Ken

Re: I'm already using Homebrew for a couple of things, Is it problematic to use Homebrew and MacPorts side by side?

[Kenneth F. Cunningham]

> On Aug 9, 2019, at 18:50, Andrew Udvare wrote:
> 
> > I can see one way: alias port or the Homebrew command to fix PATH to remove 
> > either because this is the main point of conflict. And you have to make 
> > sure you don't install other conflicting commands. So something that is 
> > installed with MacPorts may also need PATH to be fixed.
> 
> MacPorts ignores the PATH while building ports. Yet build problems can still 
> appear if you have Homebrew (or Fink) installed to their default locations 
> (or other software installed to a common location like /usr/local) while 
> building something with MacPorts.

Compilers like clang are prebuilt to search first in /usr/local for include 
files and libraries, and then after that in /usr (or -isysroot).

SO -- if you have things installed in /usr/local then those headers and 
libraries will be found automatically and, helpfully, USED.

THIS is why people love HomeBrew so much -- things seem to  "just work" because 
they are installed (or symlinked) into /usr/local. 

However, this is also why things break cryptically without being able to figure 
out what the heck is going on. Because headers in /usr/local are being used 
instead of the ones you thought would be used.

IF you are very very clever, and can keep track of all this, you can use 
multiple different systems together successfully. 

Otherwise, you are doomed to never knowing what the H*LL is going on with your 
failed builds.

Best,

K

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F. Cunningham]

> > I tried building with clang-3.7 but it doesn't work, because the port wants 
> > then to issue -stdlib=macports-libstdc++, which clang 3.7 does not 
> > understand.
>
> We didn't backport that feature to clang-3.7? I wonder why we didn't.

The supporting technology for macports-libstdc++ did not exist in llvm until 
the 3.9 release.

I backported it into llvm-3.8 for my own use on PPC 
 but there was 
no reason to make that available for MacPorts so I never submitted it (and 
clang-3.8 has been deleted from MacPorts anyway now).

Ken

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F. Cunningham]

> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
> error: shift expression '(1853123693 << 8)' overflows [-fpermissive]
>   kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),

I have fixed this error on several occasions previously -- I believe by adding 
"-fpermissive" as it suggests in the error.

I thought I had that committed somewhere in my LeopardPorts repo, but 
apparently not. I know I have it somewhere, probably on my 10.5 Intel VM.

Ken

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F . Cunningham]

On 2019-08-14, at 7:52 AM, Kenneth F. Cunningham wrote:

>> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
>> error: shift expression '(1853123693 << 8)' overflows [-fpermissive]
>>  kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
> 
> I have fixed this error on several occasions previously -- I believe by 
> adding "-fpermissive" as it suggests in the error.
> 
> I thought I had that committed somewhere in my LeopardPorts repo, but 
> apparently not. I know I have it somewhere, probably on my 10.5 Intel VM.
> 


Ah yes -- I put the info here (and a lot more harfbuzz analysis as well):

<https://trac.macports.org/ticket/58031>

Ken

Re: poppler and leopard - LegacySupport issues

[Kenneth F. Cunningham]

> [  1%] Building CXX object CMakeFiles/poppler.dir/goo/gbasename.cc.o
> /opt/local/bin/clang++-mp-5.0  -Dpoppler_EXPORTS 
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/fofi
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/poppler
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build/poppler
>  
> -I/opt/local/include -I/opt/local/include/freetype2 
> -I/opt/local/include/openjpeg-2.3  -Wall -Wextra -Wpedantic 
> -Wno-unused-parameter -Wcast-align -Wformat-security 
> -Wframe-larger-than=65536 -Wmissing-format-attribute -Wnon-virtual-dtor 
> -Woverloaded-virtual -Wmissing-declarations -Wundef 
> -Wzero-as-null-pointer-constant -Wshadow -pipe -Os -std=c++14 
> -D_GLIBCXX_USE_CXX11_ABI=0 -DNDEBUG -I/opt/local/include/LegacySupport 
> -I/opt/local/include/LegacySupport -stdlib=macports-libstdc++ -arch 
> x86_64 -mmacosx-version-min=10.5 -fPIC   -std=c++14 -o 
> CMakeFiles/poppler.dir/goo/gbasename.cc.o -c 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbasename.cc
> /opt/local/bin/clang++-mp-5.0  -Dpoppler_EXPORTS 
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/fofi
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/poppler
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build
>  
> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build/poppler
>  
> -I/opt/local/include -I/opt/local/include/freetype2 
> -I/opt/local/include/openjpeg-2.3  -Wall -Wextra -Wpedantic 
> -Wno-unused-parameter -Wcast-align -Wformat-security 
> -Wframe-larger-than=65536 -Wmissing-format-attribute -Wnon-virtual-dtor 
> -Woverloaded-virtual -Wmissing-declarations -Wundef 
> -Wzero-as-null-pointer-constant -Wshadow -pipe -Os -std=c++14 
> -D_GLIBCXX_USE_CXX11_ABI=0 -DNDEBUG -I/opt/local/include/LegacySupport 
> -I/opt/local/include/LegacySupport -stdlib=macports-libstdc++ -arch 
> x86_64 -mmacosx-version-min=10.5 -fPIC   -std=c++14 -o 
> CMakeFiles/poppler.dir/goo/gbase64.cc.o -c 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbase64.cc
> In file included from 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.79.0/goo/gbasename.cc:46:
> /opt/local/include/LegacySupport/stdlib.h:44:14: error: conflicting asm 
> label
> extern char *realpath(const char * __restrict, char * __restrict)
>   ^
> /usr/include/stdlib.h:226:60: note: previous declaration is here
> char*realpath(const char * __restrict, char * __restrict) 
> __DARWIN_EXTSN(realpath);
>^
> /usr/include/sys/cdefs.h:365:36: note: expanded from macro '__DARWIN_EXTSN'
> #define __DARWIN_EXTSN(sym) __asm("_" __STRING(sym) 
> __DARWIN_SUF_EXTSN)
>^
> 1 error generated.
> make[2]: *** [CMakeFiles/poppler.dir/goo/gbasename.cc.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> 
> 
> Am I missing some other "trick" ?
> 
> 
> Thank you,
> 
> Riccardo

Ah, this looks similar to  the error you reported for cmake, now.

I think you are seeing this because you are trying to build poppler as 64bit on 
10.5 Intel. 

You are quite possibly the only one

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F. Cunningham]

> Since PPC does not have clang, it will be bitten by this issue.

PPC does not have this issue. Many details in the referenced harfbuzz ticket.

Ken

Re: strange SDKs in El Capitan...

[Kenneth F. Cunningham]

Thanks -- I do this quite a lot (too much, probably), but somehow I obviously 
have missed some Xcode update here.

Nothing shows up in the upgrade list / App Store, but clearly there is one ...

Best,

Ken




On 2020-04-01, at 4:57 PM, Franco Vaccari wrote:

> If it may help, on my PowerMac running El Cap I find both showing 10.12:
> 
> [:~]% ls -la 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
> total 16
> drwxr-xr-x  3 root  wheel  136 Dec 16  2017 .
> drwxr-xr-x  5 root  wheel  170 Dec 15  2016 ..
> drwxr-xr-x  4 root  wheel  170 Sep 17  2017 MacOSX.sdk
> lrwxr-xr-x  1 root  wheel   10 Dec 16  2017 MacOSX10.12.sdk -> MacOSX.sdk
> [:~]% ls -la /Library/Developer/CommandLineTools/SDK*
> total 16
> drwxr-xr-x  3 root  wheel  136 Dec 16  2017 .
> drwxr-xr-x  5 root  admin  170 Dec 16  2017 ..
> drwxr-xr-x  4 root  wheel  170 Sep 17  2017 MacOSX.sdk
> lrwxr-xr-x  1 root  wheel   10 Dec 16  2017 MacOSX10.12.sdk -> MacOSX.sdk
> [dstx03:~] vaccari% exit
> 
> Xcode there is v.8.2.1
> 
> Ciao
> 
> Franco
> 
>> On 2 Apr 2020, at 01:43, Ken Cunningham  
>> wrote:
>> 
>> In trying to track down a build failure of clang-3.7 on El Cap, I found it 
>> only builds there if “use_xode yes” is selected...
>> 
>> In trying to understand why that is, I find this odd SDK difference. It’s on 
>> two different El Cap machines I have. Does everyone with El Cap have this 
>> issue - the last Xcode has MacOSX10.11 SDK but the CLTs have MacOSX10.12 
>> SDK? 
>> 
>> If so, no wonder we see strange errors:
>> 
>> 
>> $ ls -la 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
>> total 0
>> drwxr-xr-x  3 root  wheel  102  3 Mar  2016 .
>> drwxr-xr-x  5 root  wheel  170 26 Apr  2016 ..
>> drwxr-xr-x  5 root  wheel  170 20 Oct  2020 MacOSX10.11.sdk
>> 
>> 
>> $ ls -la /Library/Developer/CommandLineTools/SDK*
>> total 8
>> drwxr-xr-x  4 root  wheel  136  1 Jul  2017 .
>> drwxr-xr-x  5 root  admin  170  1 Jul  2017 ..
>> drwxr-xr-x  5 root  wheel  170 17 Sep  2017 MacOSX.sdk
>> lrwxr-xr-x  1 root  wheel   10  1 Jul  2017 MacOSX10.12.sdk -> MacOSX.sdk
>> 
>> 
>> 
> 

Re: libpsl doesn't build on older versions of Mac OS X because it depends on python38

[Kenneth F. Cunningham]

I pushed the python38 fix I have been using the past four months or so.

It works, and should get you moving. It has been well tested.

Upstream is looking to see if they might do an official integration of a fix 
that follows their usual Makefile pattern, and if they do, this fix may not be 
needed in some future release of python.

Thanks to everyone for their reviews and looking things over.

For Chris, the patches have been restricted to ancient systems only, and cannot 
affect 10.6 or newer in any way, as requested.

Ken

Re: Mpv doesn't install

[Kenneth F. Cunningham]

There is a "quite simple" Portfile patch that makes mpv work on the older 
systems here .

mpv has an active macos version, and the objective-c and SDK requirements 
advance fairly quickly.

but the fallback x11 version works OK, if you can live with it.

making the newer objective-c compatible with older SDKs is a bigger project -- 
I just don't have it in me.

Building against a newer SDK and deploying on older systems to get the macOS 
version is a better bet -- I don't know how much support is written into mpv 
for that with my quick look. Anyway, macports doesn't have much support for 
that yet, although who knows what the future may hold in that regard?

Best,

Ken

Re: Was the clang <> GCC 5 ABI incompatibility overcome at some point?

[Kenneth F. Cunningham]

> Hi!
> 
> I remember a few years ago when a change in GCC 5 caused ABI
> incompatibility with clang. I'm searching for updates on this, and it seems
> like clang applied the same change eventually, but can they considered
> binary compatible at this moment? Is it now safe to link object code coming
> from GCC and from clang?
> 
> Thanks!
> 
> César

The issue is not so much with the compiler as with the c++ standard library.

Any compiler can use any c++ standard library.

But *by default* (1) clang will use libc++ and gcc will use libstdc++, and 
these are not compatible with each other.

So if you are going to mix objects (and libraries) coming out of clang and gcc, 
you have to be sure that they all use the same c++ standard library. 

With c++ code, that is quite tricky to do properly.

If you use gcc just to build "c" code, or fortran code, there is no problem 
mixing those libraries or objects with clang c++ code.

Ken




1. By default, on current MacOS and on all MacOS on MacPorts. Further needless 
and sometimes confusing detail omitted for clarity of focus, ask if truly 
curious. -K