Re: Restarting from scratch on Snow Leopard

[Franco Vaccari]

> On 1 Mar 2019, at 21:10, Ken Cunningham  
> wrote:
> 
> 
> On 2019-03-01, at 11:43 AM, Ken Cunningham wrote:
> 
>> But that is what you get when you want to run 2019 software on a 2006 system 
>> :>
> 
> 
> So in the end, you now have a whole new system infrastructure installed in 
> /opt/local/lib
> 
> Your ssl and TLS are up to date, if you use apache from macports you get 
> current security, if you use pretty much anything from macports you are as up 
> to date as anyone.
> 
> 
> For a browser, I suggest TenFourFox-Intel version, ArcticFox, or FireFox 
> 45.9.0 ESR version. I am working on a new browser for 10.6.8 using 
> webkit2-gtk and epiphany, but it still has some issues with timing, TLS 1.3, 
> and IPC communication failures.
> 
> For email -- let me know if something in Macports works well for you. I 
> haven't explored much. The 10.6.8 email client has old TLS and won't connect 
> to every IMAP server, but you can tell gmail to use that TLS version so 
> that's good enough for now. 
> 
> If you try to build software, you might run into MacOS SDK issues, but there 
> are fixes and workarounds for a lot of that. You will have trouble building 
> things with XCode, as teaching Xcode 3.26 about the installed clangs, 
> cctools, and ld64 stuff in  MacPorts is a bit tricky. I have done all that, 
> but have to write up how to make it work for general users.
> 
> You will probably be happy -- hundreds and hundreds of current ports will 
> "just work" on 10.6.8 with the setup you have now. But there will be some 
> that won't build, like qt5, that will be disappointing.
> 
> Trac tickets using Libcxx installations are accepted, as all of macports will 
> be going in the direction you've gone in soon enough -- people like me just 
> don't use the libstdc++ installation any more, so there may be nobody to fix 
> those issues eventually.
> 
> Ken

Went a long way with package installation in the last days, I’d say 98% of my 
needs. 

Now stopped at 

install qgis +grass 

All dependencies installed properly, but qgis failed. At first, had to modify 
qgis Portfile according to , adding 

configure.args-append   "-DWITH_INTERNAL_FUTURE=OFF"

After that, build process went quite far but stopped at about 49%. Any guess 
from the tail of the log shown below? 

Ready to file a ticket with the full log, but I’m afraid that being an old 
version of qgis failing on a non-standard MacPorts configuration on an ancient 
system, it may not deserve much of attention…

Franco

…
…
…
:info:build /opt/local/bin/cmake -E copy 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis/qgis/work/QGIS-2_18_17/src/gui/editorwidgets/core/qgswidgetwrapper.h
 output/lib/qgis_gui.framework/Versions/2.18/Headers/qgswidgetwrapper.h
:info:build [ 49%] Linking CXX shared library 
../../output/lib/qgis_gui.framework/qgis_gui
:info:build cd 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis/qgis/work/build/src/gui
 && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/qgis_gui.dir/link.txt 
--verbose=ON
:info:build /opt/local/bin/clang++-mp-5.0 -pipe -Os -DNDEBUG 
-I/opt/local/include -stdlib=libc++ -DSPATIALITE_VERSION_GE_4_0_0 
-DSPATIALITE_VERSION_G_4_1_1 -DSPATIALITE_HAS_INIT_EX -std=c++11 
-Wno-error=c++11-narrowing -Wall -Wextra -Wno-long-long -Wformat-security 
-Wno-strict-aliasing -Wno-return-type-c-linkage -Wno-overloaded-virtual 
-Qunused-arguments -arch x86_64 -mmacosx-version-min=10.6 -dynamiclib 
-Wl,-headerpad_max_install_names -L/opt/local/lib 
-Wl,-headerpad_max_install_names -Qunused-arguments -F/Library/Frameworks 
-compatibility_version 2.18.17 -current_version 2.18.17 -o 
../../output/lib/qgis_gui.framework/Versions/2.18/qgis_gui -install_name 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis/qgis/work/build/output/lib/qgis_gui.framework/Versions/2.18/qgis_gui
 CMakeFiles/qgis_gui.dir/raster/qgsmultibandcolorrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgspalettedrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgsrasterhistogramwidget.cpp.o 
…
…

…
…
CMakeFiles/qgis_gui.dir/editorwidgets/moc_qgswebviewwidgetwrapper.cxx.o  
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis/qgis/work/build/src/core
  
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis/qgis/work/build/src/gui
 -Wl,-rpath,/opt/local/lib -Wl,-rpath,/Applications/MacPorts/lib 
../../output/lib/qgis_core.framework/Versions/2.18/qgis_core 
/opt/local/libexec/qt4/lib/libQtUiTools.dylib 
/opt/local/libexec/qt4/lib/libqwt.dylib 
/opt/local/libexec/qt4/lib/libqscintilla2_qt4.dylib -framework CoreFoundation 
-framework IOKit 

Re: Restarting from scratch on Snow Leopard

[Ken Cunningham]

>  No network and fiddle the date?
Sounds likely. 

The internet seems to have no shortage of suggestions.

I can’t really say macports could or would recommend a site called “LIfeHacker” 
but ...

https://lifehacker.com/psa-an-expired-certificate-means-youll-need-to-remake-1762704972
 


has a suggestion near the bottom that would be my first try.

K
 

 

Re: Restarting from scratch on Snow Leopard

[James Linder]

> On 1 Mar 2019, at 8:00 pm, macports-users-requ...@lists.macports.org wrote:
> 
>>> is llvm39 still the one to be used?
>> 
>> I still use +llvm39
>> 
>> $ port -v installed | grep ld64
>>  ld64 @3_1+universal-ld64_127-ld64_236-ld64_97 (active) platform='darwin 10' 
>> archs='i386 x86_64' date='2018-09-20T16:56:39-0700'
>>  ld64-latest @274.2_2+llvm39+universal-llvm34 (active) platform='darwin 10' 
>> archs='i386 x86_64' date='2017-11-26T13:19:27-0800'
>> 
>> 
>> One thing you learn in this, is to be current but not too current. There is 
>> no benefit to trying to ride the dragon's tale here -- you just run into a 
>> lot of new errors that haven't been dealt with yet.
>> 
>> llvm3.9 is about equal to Sierra. That's a pretty good spot. I haven't 
>> really tried anything newer yet.
>> 
>> I was configured to use clang-3.9 as my primary compiler up until a few 
>> weeks ago, when I fixed clang-5.0+ to enable thread_local storage, and so 
>> have just recently set clang-5.0 as my default compiler.
> 
> 
> Right now I’ve finished the whole procedure described in
> 
> 
> 
> 
> without hitting any issue (unlike when I had Xcode 4.2 installed). Will now 
> attempt installing the usual packages I need.
> 
> Thanks for your help, Ken!


I bought a mac. It came with Snow Leopard CDs. I cleaned the disk and want to 
re-install Snow Leopard. I can’t “Certificate Expired”.
Google: easy: iTunes -> purchased: download (ooops I never purchesed or 
downloaded a copy, I have the CDs), OK Apple Download: only the earliest is 
later than that. (IIRC Yosemite)
Oh Apple! he politely lamented

So how does the poor boy install Snow Leopard? Brain surgery on the CD springs 
to mind but that is too involved for moi. No network and fiddle the date?

James

Re: Restarting from scratch on Snow Leopard

[Bill Cole]

On 1 Mar 2019, at 14:43, Ken Cunningham wrote:


Do you see other anomalies in the output I’ve produced?


No, everything else looks perfect. Go ahead with that line to upgrade 
to the emulated_tls variant of libcxx.


I'll ponder adding a new instruction to the Libcxx... page to lead to 
the +emulated_tls variant.


It's a bit tricky to automate, as you need to install libcxx, then 
several clang versions, then clang-5.0+, and then you can build libcxx 
+emulated_tls.


NOW you tell me... I wish I'd known the right order when I had to scrap 
and rebuild my SL/libcxx machine 2 months ago. FWIW, I can't reproduce 
exactly what I did, but where I ended up has worked since, including 
using clang 6.0 by default. Here's what's installed:


#  port -v installed libcxx cctools ld64\* clang\*
The following ports are currently installed:
  cctools @921_1+llvm50-llvm34-llvm37-llvm39 (active) platform='darwin 
10' archs='i386' date='2019-02-03T23:33:59-0500'
  clang-3.4 @3.4.2_12+analyzer+assertions (active) platform='darwin 10' 
archs='i386' date='2019-01-01T00:58:28-0500'
  clang-5.0 @5.0.2_3+analyzer+defaultlibcxx+emulated_tls-libstdcxx 
(active) platform='darwin 10' archs='i386' 
date='2019-01-01T19:06:46-0500'
  clang-6.0 @6.0.1_2+analyzer+defaultlibcxx+emulated_tls-libstdcxx 
(active) platform='darwin 10' archs='i386' 
date='2019-02-04T05:35:24-0500'
  clang_select @2_0 (active) platform='darwin 10' archs='noarch' 
date='2019-01-02T16:22:49-0500'
  ld64 @3_1-ld64_127-ld64_236-ld64_97 (active) platform='darwin 10' 
archs='i386' date='2019-01-02T16:25:33-0500'
  ld64-latest @274.2_2+llvm34-llvm37-llvm39 (active) platform='darwin 
10' archs='i386' date='2019-01-02T23:00:37-0500'
  libcxx @5.0.1_4+emulated_tls+universal (active) platform='darwin 10' 
archs='i386 x86_64' date='2019-02-03T23:37:40-0500'


As you can see, I had to get a bit stern with what MP's variant urges in 
some cases.



But that is what you get when you want to run 2019 software on a 2006 
system :>


IF you care to help MacPorts remain interested in older systems, feel 
free to install "mpstats" which will register your system as using 
10.6 to MacPorts auditing system.


Done.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole

Re: Restarting from scratch on Snow Leopard

[Franco Vaccari]

> On 1 Mar 2019, at 21:10, Ken Cunningham  
> wrote:
> 
> 
> On 2019-03-01, at 11:43 AM, Ken Cunningham wrote:
> 
>> But that is what you get when you want to run 2019 software on a 2006 system 
>> :>

And some of the Xserves that keep the lab going are even older than that… :-/

I’m trying to get an updated MacPorts on this test iMac, with all the packages 
we need, from scratch, so that I could eventually clone it around on the other 
hardware running 10.6.8, where some historical MacPorts installation still does 
its job... 

> So in the end, you now have a whole new system infrastructure installed in 
> /opt/local/lib
> 
> Your ssl and TLS are up to date, if you use apache from macports you get 
> current security, if you use pretty much anything from macports you are as up 
> to date as anyone.
> 
> 
> For a browser, I suggest TenFourFox-Intel version, ArcticFox, or FireFox 
> 45.9.0 ESR version. I am working on a new browser for 10.6.8 using 
> webkit2-gtk and epiphany, but it still has some issues with timing, TLS 1.3, 
> and IPC communication failures.
> 
> For email -- let me know if something in Macports works well for you. I 
> haven't explored much. The 10.6.8 email client has old TLS and won't connect 
> to every IMAP server, but you can tell gmail to use that TLS version so 
> that's good enough for now. 
> 
> If you try to build software, you might run into MacOS SDK issues, but there 
> are fixes and workarounds for a lot of that. You will have trouble building 
> things with XCode, as teaching Xcode 3.26 about the installed clangs, 
> cctools, and ld64 stuff in  MacPorts is a bit tricky. I have done all that, 
> but have to write up how to make it work for general users.
> 
> You will probably be happy -- hundreds and hundreds of current ports will 
> "just work" on 10.6.8 with the setup you have now. But there will be some 
> that won't build, like qt5, that will be disappointing.
> 
> Trac tickets using Libcxx installations are accepted, as all of macports will 
> be going in the direction you've gone in soon enough -- people like me just 
> don't use the libstdc++ installation any more, so there may be nobody to fix 
> those issues eventually.
> 
> Ken

Thanks for all the suggestions. I’ve already installed gnuplot, ImageMagick and 
some other packages. What I do really need now is a working gcc (for gfortran), 
gmt4 and gmt5, texlive, some python packages and hopefully Qgis (v.2, as v.3 
requires qt5). 

I’ve just started with gcc49, it’s currently compiling libcc7, will see 
tomorrow morning if it will end with a success, so that I can continue with 
this adventure… It would be much faster to compile on the Xserve, with dual 
quad-core, but that is the main production machine, so can’t dismantle that...

Franco

Re: Restarting from scratch on Snow Leopard

[Franco Vaccari]

> On 27 Feb 2019, at 21:58, Ken Cunningham  
> wrote:
> 
>> is llvm39 still the one to be used?
> 
> I still use +llvm39
> 
> $ port -v installed | grep ld64
>   ld64 @3_1+universal-ld64_127-ld64_236-ld64_97 (active) platform='darwin 10' 
> archs='i386 x86_64' date='2018-09-20T16:56:39-0700'
>   ld64-latest @274.2_2+llvm39+universal-llvm34 (active) platform='darwin 10' 
> archs='i386 x86_64' date='2017-11-26T13:19:27-0800'
> 
> 
> One thing you learn in this, is to be current but not too current. There is 
> no benefit to trying to ride the dragon's tale here -- you just run into a 
> lot of new errors that haven't been dealt with yet.
> 
> llvm3.9 is about equal to Sierra. That's a pretty good spot. I haven't really 
> tried anything newer yet.
> 
> I was configured to use clang-3.9 as my primary compiler up until a few weeks 
> ago, when I fixed clang-5.0+ to enable thread_local storage, and so have just 
> recently set clang-5.0 as my default compiler.
> 
> 
> Ken

One question about setting clang-5.0 as the default compiler. Do I have to 
repeat the whole LibcxxOnOlderSystems procedure or is it enough to install 
clang-5.0 (hoping it will install) and then change macports.conf to look 
something like this?

default_compilers macports-clang-5.0 macports-clang-3.9 macports-clang-3.7 
macports-clang-3.4 gcc-4.2 apple-gcc-4.2 gcc-4.0

I’m currently having success with most of the package installations I’m doing, 
but couldn’t install gcc. I’ve started with trying gcc49, but it failed when 
trying to install the libgcc7 dependency (while libgcc8 was successfully 
installed). I then tried to install gcc8 but failed as well.

I’m not sure if I should file some tickets about those failures, given that I 
no longer have a plain MacPorts installation, after having gone through the 
LibcxxOnOlderSystems stuff

Thanks

Franco

Re: Restarting from scratch on Snow Leopard

[Franco Vaccari]

> On 27 Feb 2019, at 21:58, Ken Cunningham  
> wrote:
> 
>> is llvm39 still the one to be used?
> 
> I still use +llvm39
> 
> $ port -v installed | grep ld64
>   ld64 @3_1+universal-ld64_127-ld64_236-ld64_97 (active) platform='darwin 10' 
> archs='i386 x86_64' date='2018-09-20T16:56:39-0700'
>   ld64-latest @274.2_2+llvm39+universal-llvm34 (active) platform='darwin 10' 
> archs='i386 x86_64' date='2017-11-26T13:19:27-0800'
> 
> 
> One thing you learn in this, is to be current but not too current. There is 
> no benefit to trying to ride the dragon's tale here -- you just run into a 
> lot of new errors that haven't been dealt with yet.
> 
> llvm3.9 is about equal to Sierra. That's a pretty good spot. I haven't really 
> tried anything newer yet.
> 
> I was configured to use clang-3.9 as my primary compiler up until a few weeks 
> ago, when I fixed clang-5.0+ to enable thread_local storage, and so have just 
> recently set clang-5.0 as my default compiler.
> 
> 
> Ken


Right now I’ve finished the whole procedure described in

 


without hitting any issue (unlike when I had Xcode 4.2 installed). Will now 
attempt installing the usual packages I need.

Thanks for your help, Ken!

Franco

Re: Restarting from scratch on Snow Leopard

[Ken Cunningham]

> is llvm39 still the one to be used?

I still use +llvm39

$ port -v installed | grep ld64
  ld64 @3_1+universal-ld64_127-ld64_236-ld64_97 (active) platform='darwin 10' 
archs='i386 x86_64' date='2018-09-20T16:56:39-0700'
  ld64-latest @274.2_2+llvm39+universal-llvm34 (active) platform='darwin 10' 
archs='i386 x86_64' date='2017-11-26T13:19:27-0800'


One thing you learn in this, is to be current but not too current. There is no 
benefit to trying to ride the dragon's tale here -- you just run into a lot of 
new errors that haven't been dealt with yet.

llvm3.9 is about equal to Sierra. That's a pretty good spot. I haven't really 
tried anything newer yet.

I was configured to use clang-3.9 as my primary compiler up until a few weeks 
ago, when I fixed clang-5.0+ to enable thread_local storage, and so have just 
recently set clang-5.0 as my default compiler.


Ken

Re: Restarting from scratch on Snow Leopard

[Franco Vaccari]

> On 27 Feb 2019, at 18:04, Ken Cunningham  
> wrote:
> 
>> So, just to be sure, you are suggesting to follow the path of 
>> 
>> <
>> https://trac.macports.org/wiki/LibcxxOnOlderSystems
>> > 
>> 
>> I can certainly retry that, now that I have a more standard Xcode 
>> installation.
>> 
>> Thanks 
>> 
>> Franco
>> 
> 
> That's what I use. It is a PITA to bootstrap, I won't deny it. But I 
> personally consider the occasional heartache of a long 
> llvm/clang/gcc/webkit2-gtk compile to be balanced off by the better usability 
> of the system. I've had this libc++ SL system  running for years now with 
> very little trouble. Most of the tickets posted against SnowLeopard in Trac I 
> never see on this system, because of the way this is set up.
> 
> Your other choice is to just try the current default libstdc++ setup using 
> the prebuilt binaries, and you might find it works for you. You can then 
> start over with libc++ if you run into troubles, or switch over when MacPorts 
> does, eventually.
> 
> K
> 

Ok, I'll go on with LibcxxOnOlderSystems. About the step:

5.  Disable the variants corresponding to the bootstrap versions of llvm in 
/opt/local/etc/macports/variants.conf. This ensures that future installs of 
cctools and ld64 will use a newer version of llvm:

-llvm34
+llvm39 # You may need to update this to +llvm40 and higher in the future

is llvm39 still the one to be used? Or we are already in the future and a 
higher version should be indicated, possibly also in other steps of that 
document?

Franco

Re: Restarting from scratch on Snow Leopard

[Ken Cunningham]

> So, just to be sure, you are suggesting to follow the path of 
> 
>  
> 
> I can certainly retry that, now that I have a more standard Xcode 
> installation.
> 
> Thanks 
> 
> Franco

That's what I use. It is a PITA to bootstrap, I won't deny it. But I personally 
consider the occasional heartache of a long llvm/clang/gcc/webkit2-gtk compile 
to be balanced off by the better usability of the system. I've had this libc++ 
SL system  running for years now with very little trouble. Most of the tickets 
posted against SnowLeopard in Trac I never see on this system, because of the 
way this is set up.

Your other choice is to just try the current default libstdc++ setup using the 
prebuilt binaries, and you might find it works for you. You can then start over 
with libc++ if you run into troubles, or switch over when MacPorts does, 
eventually.

K

Re: Restarting from scratch on Snow Leopard

[Franco Vaccari]

> On 27 Feb 2019, at 16:27, Ken Cunningham  
> wrote:
> 
> The best way of giving extra lifespan to SL is to make it work like newer 
> systems as much as possible. All current software for macOS is built and 
> tested against libc++ using clang.
> 
> The only reason to use libstdc++ is to get the prebuilt binaries. However 
> there are issues with the gcc headers and differences in the libraries often 
> enough to cause real headaches. As time passes, these issues are getting 
> worse, not better.
> 
> For this reason, MacPorts will have to force all 10.6 to 10.8 users to use 
> libc++ soon. IMHO, the sooner the better, as fixing libstdc++ issues is 
> really a waste of effort. When we run into troubles now, we just force libc++ 
> behind the scenes in the Portfile.
> 
> My $0.02.
> 
> K
> 

So, just to be sure, you are suggesting to follow the path of 

 

I can certainly retry that, now that I have a more standard Xcode installation.

Thanks 

Franco

Re: Restarting from scratch on Snow Leopard

[Ken Cunningham]

The best way of giving extra lifespan to SL is to make it work like newer 
systems as much as possible. All current software for macOS is built and tested 
against libc++ using clang.

The only reason to use libstdc++ is to get the prebuilt binaries. However there 
are issues with the gcc headers and differences in the libraries often enough 
to cause real headaches. As time passes, these issues are getting worse, not 
better.

For this reason, MacPorts will have to force all 10.6 to 10.8 users to use 
libc++ soon. IMHO, the sooner the better, as fixing libstdc++ issues is really 
a waste of effort. When we run into troubles now, we just force libc++ behind 
the scenes in the Portfile.

My $0.02.

K