Re: not seen the 404 before

2022-05-05 Thread Chris Jones




On 05/05/2022 4:51 pm, chilli.names...@gmail.com wrote:

I can't upgrade because of 404? Is this a problem on my end?


Most probably yes. Update built just fine here.

Check your local network / firewall.




--->  Computing dependencies for curl-ca-bundle.
--->  Fetching distfiles for curl-ca-bundle
--->  curl-7.83.0.tar.xz does not exist in 
/opt/local/var/macports/distfiles/curl
--->  Attempting to fetch curl-7.83.0.tar.xz from https://curl.se/download/
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from https://curl.askapache.com/
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://mse.uk.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://fra.de.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://ema.uk.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://cph.dk.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://nue.de.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://fco.it.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://kmq.jp.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://cjj.kr.distfiles.macports.org/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
--->  Attempting to fetch curl-7.83.0.tar.xz from 
http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/curl
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft 

Re: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?

2022-04-12 Thread Chris Jones

Hi,

Speaking only for myself, I generally suggest *not* using the 
restore_ports.tcl script. When I migrate to a new OS I generate the list 
of installed ports *and* requested ones, and follow the instructions as 
far as wi[ping out my old ports prior to the update.


However, when restoring the ports I prefer to just manually do this. If 
you just open up the list of requested ports, in whatever text reader 
you prefer, its usually a quite short list (much shorter than all 
installed) and its a short job to go through and reinstall by hand 
whatever you still want. When you do this it will not try and preserve 
the same variants as before, unless you actively request them, and I 
find this a good idea as default variant sometimes get updated so just 
using the same as before is not always the best idea.


This is not to say you still will not have issues with the new Arm arch, 
as for sure some ports will have issues with that. But at least you will 
not have issues because of old settings that should no longer be preserved.


Chris

On 12/04/2022 3:10 am, Jim DeLaHunt wrote:

Hello, MacPorts folks:

I am following the MacPorts wiki "Migration"[1] instructions as I move 
from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1 
Monterey machine with an arm64 CPU. I got stuck with a bug in the tiff 
port, which fails during destroot under the +universal variant. I opened 
a ticket[2] against tiff +universal on arm64, but that is not my 
question here.


I don't know why MacPorts was trying to install tiff with the +universal 
variant. I am following the Migration instructions. They have me make a 
list of installed ports using `port -qv installed`. None of these 
entries mention "requested_variants='+universal'". 91% have an empty 
string for requested variants. 9% request some other variant. However, 
two-thirds mention "archs='x86_64'", while the other one-third mention 
"archs='noarch'", and none have empty strings or some other value for 
"archs". I use the restore_ports.tcl script to install the ports on the 
new computer.


Here are four representative entries from my list of installed ports:

   aalib @1.4rc5_5 (active) requested_variants='' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:16:05-0700'
   abcde @2.9.3_1 (active) requested_variants='' platform='darwin 18' 
archs='noarch' date='2022-01-23T21:52:02-0800'
   apr-util @1.6.1_2+no_bdb (active) requested_variants='+no_bdb' 
platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:21-0700'
   aspell @0.60.8_1 (active) requested_variants='-nls' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:34:34-0700'

Might the presence of "archs='x86_64'" cause the restore_ports.tcl 
script to ask for +universal variants on the new computer?


Should I perhaps null out the value "x86_64" from the archs entries in 
my installed ports list?  i.e. turn them into "archs='' "? Or should I 
replace them with the value "arm64"?


I don't see any mention in the Migration instructions about modifying 
"archs" entries when migrating from one architecture to another.


[1] 
[2] , tiff@4.3.0_0+universal: 
Failed to destroot tiff, "libtiff-4.pc differs"


--
.--Jim DeLaHunt, Vancouver, Canada



Re: libusb-devel port

2022-04-05 Thread Chris Jones


> On 5 Apr 2022, at 3:08 pm, Christoph Kukulies  wrote:
> 
> Thanks. Assumed I have downloaded a binary release from libusb’s github 
> Releases and it looks like that in the tree:
> 
> $ find macos_11.6
> macos_11.6
> macos_11.6/.DS_Store
> macos_11.6/bin
> macos_11.6/bin/dpfp
> macos_11.6/bin/listdevs
> macos_11.6/bin/sam3u_benchmark
> macos_11.6/bin/fxload
> macos_11.6/bin/xusb
> macos_11.6/bin/testlibusb
> macos_11.6/bin/hotplugtest
> macos_11.6/bin/stress
> macos_11.6/include
> macos_11.6/include/.DS_Store
> macos_11.6/include/libusb-1.0
> macos_11.6/include/libusb-1.0/libusb.h
> macos_11.6/lib
> macos_11.6/lib/pkgconfig
> macos_11.6/lib/pkgconfig/libusb-1.0.pc
> macos_11.6/lib/libusb-1.0.dylib
> macos_11.6/lib/libusb-1.0.0.dylib
> macos_11.6/lib/libusb-1.0.a
> macos_11.6/lib/libusb-1.0.la
> 
> How can I make these active in libusb-devel or otherwise available?

You cannot. Macports strongly prefers to build ports from source itself, and 
only redistributes rebuilt binaries in extreme circumstances.

You need to update the port file to fetch and then build a newer github 
revision for the devel subport. See

https://github.com/macports/macports-ports/blob/584723a8c2a65990bd0566b226f8c31b7f30fce5/devel/libusb/Portfile

See line 60 onwards.

That said, the devel port currently builds a revision that appears to be from 
the 3rd of April this year, so is pretty recent. Is this not new enough ?

Chris


> 
> Do the pkgconfig .pc files play a role in the installation mechanism?
> 
> —
> Christoph
> 
>> Am 05.04.2022 um 15:36 schrieb Chris Jones :
>> 
>> 
>>> On 05/04/2022 1:54 pm, Christoph Kukulies wrote:
>>> Thanks. Nonetheless I don‘t get how I can aim at a specific version or 
>>> 1.0.26-rc1 „HEAD“
>> 
>> you cannot. You still get whatever version libusb-devel is current set to 
>> provide. The idea of a X-devel port though is these can be updated and 
>> tested without affecting the default X port.
>> 
>> If you want a different version than libusb-devel currently provides, then 
>> you need to update the port to provide this.
>> 
>>> Btw, what is the correspondent to
>>> ldd
>>> under macOS?
>> 
>> otool -L
>> 
>>> —
>>> Christoph
>>>> Am 05.04.2022 um 12:56 schrieb Chris Jones :
>>>> 
>>>> 
>>>> 
>>>>> On 05/04/2022 11:50 am, Christoph Kukulies wrote:
>>>>> $ sudo port deactivate libusb @1.0.25_0
>>>>> Password:
>>>>> Note: It is not recommended to uninstall/deactivate a port that has 
>>>>> dependents as it breaks the dependents.
>>>>> The following ports will break:
>>>>>  libusb-compat @0.1.7_0
>>>>>  openocd @0.11.0_0
>>>>>  usbutils @007_1
>>>>>  libftdi1 @1.5_1
>>>>>  qemu @6.2.0_0
>>>>>  stlink @1.7.0_1
>>>>> Continue? [y/N]:
>>>>> 
>>>>> OK to continue?
>>>> 
>>>> yes.
>>>> 
>>>> ports that depend on libusb should use a path style dependency, to allow 
>>>> libusb or libusb-devel to satisfy it
>>>> 
>>>> path:lib/pkgconfig/libusb-1.0.pc:libusb
>>>> 
>>>> so assuming you are about to install libusb-devel its fine.
> 


Re: libusb-devel port

2022-04-05 Thread Chris Jones



On 05/04/2022 1:54 pm, Christoph Kukulies wrote:

Thanks. Nonetheless I don‘t get how I can aim at a specific version or 
1.0.26-rc1 „HEAD“


you cannot. You still get whatever version libusb-devel is current set 
to provide. The idea of a X-devel port though is these can be updated 
and tested without affecting the default X port.


If you want a different version than libusb-devel currently provides, 
then you need to update the port to provide this.




Btw, what is the correspondent to

ldd

under macOS?


otool -L



—
Christoph


Am 05.04.2022 um 12:56 schrieb Chris Jones :




On 05/04/2022 11:50 am, Christoph Kukulies wrote:
$ sudo port deactivate libusb @1.0.25_0
Password:
Note: It is not recommended to uninstall/deactivate a port that has dependents 
as it breaks the dependents.
The following ports will break:
  libusb-compat @0.1.7_0
  openocd @0.11.0_0
  usbutils @007_1
  libftdi1 @1.5_1
  qemu @6.2.0_0
  stlink @1.7.0_1
Continue? [y/N]:

OK to continue?


yes.

ports that depend on libusb should use a path style dependency, to allow libusb 
or libusb-devel to satisfy it

path:lib/pkgconfig/libusb-1.0.pc:libusb

so assuming you are about to install libusb-devel its fine.




Re: libusb-devel port

2022-04-05 Thread Chris Jones




On 05/04/2022 11:50 am, Christoph Kukulies wrote:

$ sudo port deactivate libusb @1.0.25_0
Password:
Note: It is not recommended to uninstall/deactivate a port that has 
dependents as it breaks the dependents.

The following ports will break:
  libusb-compat @0.1.7_0
  openocd @0.11.0_0
  usbutils @007_1
  libftdi1 @1.5_1
  qemu @6.2.0_0
  stlink @1.7.0_1
Continue? [y/N]:

>
> OK to continue?

yes.

ports that depend on libusb should use a path style dependency, to allow 
libusb or libusb-devel to satisfy it


path:lib/pkgconfig/libusb-1.0.pc:libusb

so assuming you are about to install libusb-devel its fine.


Re: libusb-devel port

2022-04-05 Thread Chris Jones




On 05/04/2022 11:33 am, Christoph Kukulies wrote:
I’m in the need of testing a libusb issue with an intermediate build of 
libusb (1.0.26-rc1, that is)


Since I’m always reluctant of mixing brew and macports - is that 
actually „dangerous“ or impossible at all, should that be avoided or can 
it be done -


One of the developers of libusb told me that the libusb-devel port is 
broken. I’d prefer using macports. Trying it, I got:


$ sudo port install libusb-devel
Password:

Error: Can't install libusb-devel because conflicting ports are active: 
libusb
Error: Follow https://guide.macports.org/#project.tickets 
 if you believe there is a bug.

Error: Processing of port libusb-devel failed
$

Any advice?


you need to deacivate libusb first



Re: port diagnose and xcode

2022-03-11 Thread Chris Jones




On 11/03/2022 8:02 am, Michele Venturi wrote:

What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that by design...



MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
function, but first and foremost (and long before we even had binary 
tarballs to distribute as a 'package mnager') it is a system for 
building packages and their dependencies. To build something you require 
a compiler. Many ports will build fine with just the Apple CLT package, 
but some indeed require the full Xcode installation in order to be built 
(and Xcode also is not just an IDE, but is also a command line build 
system).


So yes, if you want to put it in those terms requiring Xcode/CLT is 'by 
design'.




Il ven 11 mar 2022, 01:40 James Secan > ha scritto:


In working my way through my recent “phantom ports” issue I ran the
command “port diagnose” and was more than a bit surprised by the
output line:

Error: currently installed version of Xcode, none, is not supported
by MacPorts.

followed by a list of the version supported under my version of
macOS (El Capitan, in this case).  Where is port getting this
information?  I have Xcode 8.2.0 installed, and none of my attempts
to install ports have run into any trouble related to Xcode not
being installed.  I ran "pkgutil -v
--pkg-info=com.apple.pkg.CLTools_Executables” which shows that I
have 8.2.0 installed, and the appropriate MacOSX.sdk files are in
/Library/Developer/CommandLineTools/SDKs.  I also tried this on my
test Catalina system, with the same result.

Is something wrong with my ports setup?

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

 > On Mar 10, 2022, at 12:34 AM, Ryan Schmidt
mailto:ryandes...@macports.org>> wrote:
 >
 > On Mar 9, 2022, at 17:13, James Secan wrote:
 >>
 >> when I run "port upgrade installed -u outdated”
 >
 > This command doesn't make a great deal of sense. You're asking
MacPorts to upgrade the "installed" ports (which includes those
those that are outdated and those that aren't) and also the
"outdated" ports (those that are outdated). It would be simpler and
more efficient to just run "sudo port -u upgrade outdated".
Single-dash/single-letter flags like "-u" go after "port" and before
the action (the action in this case being "upgrade").
 >
 > For completeness, "-u" means "uninstall inactive ports"; if you
want to keep inactive ports, for example as a safeguard so that you
could return to them in case something is wrong with the new
version, then don't use "-u". When you eventually run "sudo port
reclaim", that will get rid of the inactive versions.
 >
 > MacPorts reminds to run "sudo port reclaim" if you have not done
so in a few weeks, unless you have configured MacPorts not to remind
you.



Re: MacPorts XCode Installation

2022-03-07 Thread Chris Jones



whatever you think relevant, from the discussion here. If its not clear 
it can be added to later on so don't worry about including everything at 
first. But please lets have the discussion in trac rather than here...


On 07/03/2022 4:28 pm, Michele Venturi wrote:

What should I include in the bug report to make it clear?

Il lun 7 mar 2022, 17:25 Marius Schamschula <mailto:li...@schamschula.com>> ha scritto:


Michele,

Please submit a MacPorts ticket!

Other users may search trac if they encounter the same issue. We can
also link to any upstream tickets from there.


On Mar 7, 2022, at 10:22 AM, Michele Venturi mailto:dard...@gmail.com>> wrote:

Should I submit a bug report before we even know if it's a
MacPorts specific issue? Or how do we find that out?

Il lun 7 mar 2022, 16:47 Chris Jones mailto:jon...@hep.phy.cam.ac.uk>> ha scritto:



On 07/03/2022 3:31 pm, Michele Venturi wrote:
> I have the required libraries in /usr/lib/swift too,but MPV
is looking
> for them in /opt/local/lib,so it doesn't find them:
>
> otool -l $(which mpv)
> ...
> cmd LC_RPATH
> cmdsize 32
> path /opt/local/lib (offset 12)
>
> Should we change RPATH or add symbolic links?

No, those are not the solutions here. If there is an issue
with the
build on 10.13 we should fix that instead, rather than apply
after-the-fact bandaids.

The first thing to determine is if its a MacPorts specific
issue due to
how the build is performed, or an upstream issue. Either way
please
submit a bug report to macports trac so the discussion on this
can
continue there.

Chris

>
> Michele Venturi
> about.me/dardo82 <http://about.me/dardo82>
<http://about.me/dardo82 <http://about.me/dardo82>>
>
>

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb>>

>
> Michele Venturi
> about.me/dardo82 <http://about.me/dardo82>
>

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb

<https://about.me/dardo82?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api_content=thumb>>

>
>
>
>
> Il giorno lun 7 mar 2022 alle ore 15:46 Ryan Schmidt
> mailto:ryandes...@macports.org>
<mailto:ryandes...@macports.org
<mailto:ryandes...@macports.org>>> ha scritto:
>
>
>
>     On Mar 7, 2022, at 08:34, Michele Venturi wrote:
>
>      > If I install MPV without Xcode I get an error when I
launch it:
>      >
>      > dyld: Library not loaded:
@rpath/libswiftAVFoundation.dylib
>      >   Referenced from: /opt/local/bin/mpv
>      >   Reason: image not found
>      >
>      > It's missing something,have you tried to execute it
on 10.13?
>
>     I have not.
>
>     I guess you're right, in relation to the Swift language
usage I
>     mentioned earlier, this port does appear to need
>     libswiftAVFoundation.dylib at runtime. And maybe it is
expecting to
>     find it within Xcode on your system. (It depends on what
@rpath
>     expands to. I forget what the command is to interrogate
a binary
>     about its rpaths.)
>
>     Swift is still a new programming language and I don't
think we have
>     many ports in MacPorts that use Swift so I'm not sure if
this should
>     be considered normal or not.
>
>     I see that I have many copies of
libswiftAVFoundation.dylib on my
>     system, within various applications' bundles, so I guess
Apple
>     expects people to include copies of the Swift dylibs
with their
>     application.
>
>     On my 10.15 system, it does not link with
>     @rpath/libswiftAVFoundation.dylib. It links with various
Swift
>     dylibs in /usr/lib/swift. Maybe the port can be made to
do so on
>     10.13 as well.
>
>     You should file a bug report about this mpv problem.
>





Re: MacPorts XCode Installation

2022-03-07 Thread Chris Jones




On 07/03/2022 3:31 pm, Michele Venturi wrote:
I have the required libraries in /usr/lib/swift too,but MPV is looking 
for them in /opt/local/lib,so it doesn't find them:


otool -l $(which mpv)
...
cmd LC_RPATH
cmdsize 32
path /opt/local/lib (offset 12)

Should we change RPATH or add symbolic links?


No, those are not the solutions here. If there is an issue with the 
build on 10.13 we should fix that instead, rather than apply 
after-the-fact bandaids.


The first thing to determine is if its a MacPorts specific issue due to 
how the build is performed, or an upstream issue. Either way please 
submit a bug report to macports trac so the discussion on this can 
continue there.


Chris



Michele Venturi
about.me/dardo82 

 
	

Michele Venturi
about.me/dardo82 
 





Il giorno lun 7 mar 2022 alle ore 15:46 Ryan Schmidt 
mailto:ryandes...@macports.org>> ha scritto:




On Mar 7, 2022, at 08:34, Michele Venturi wrote:

 > If I install MPV without Xcode I get an error when I launch it:
 >
 > dyld: Library not loaded: @rpath/libswiftAVFoundation.dylib
 >   Referenced from: /opt/local/bin/mpv
 >   Reason: image not found
 >
 > It's missing something,have you tried to execute it on 10.13?

I have not.

I guess you're right, in relation to the Swift language usage I
mentioned earlier, this port does appear to need
libswiftAVFoundation.dylib at runtime. And maybe it is expecting to
find it within Xcode on your system. (It depends on what @rpath
expands to. I forget what the command is to interrogate a binary
about its rpaths.)

Swift is still a new programming language and I don't think we have
many ports in MacPorts that use Swift so I'm not sure if this should
be considered normal or not.

I see that I have many copies of libswiftAVFoundation.dylib on my
system, within various applications' bundles, so I guess Apple
expects people to include copies of the Swift dylibs with their
application.

On my 10.15 system, it does not link with
@rpath/libswiftAVFoundation.dylib. It links with various Swift
dylibs in /usr/lib/swift. Maybe the port can be made to do so on
10.13 as well.

You should file a bug report about this mpv problem.



Re: Is this git handling of a problem on my macports-ports fork OK?

2022-02-23 Thread Chris Jones



> git pull --rebase --autostash origin master

works pretty much just fine 99.9% of the time.

cheers Chris

* Its actually what 'port sync' does under the hood, if you have 
configured macports to work directly off a git checkout of the ports 
tree, instead of the dfault rsync tarball


** the autostash option is not available in older git versions. If the 
system git on your machine does not have it, just install MacPorts git. 
Its very useful as it automatically handles unstaged changes during a 
rebase.


On 23/02/2022 2:13 pm, Kirill A. Korinsky via macports-users wrote:

Hey,

I'd like to share with two git aliases which I've made special for 
MacPorts :)


cleanup = !git branch --merged origin/HEAD | grep -v ' -> ' | grep -v 
'^\\*' | xargs -n 1 git branch -d

rebaseall = !git branch --no-merged | xargs -n 1 git rebase origin/HEAD

The first one simple removed all branches which was merged into master.

The second one rebases all branches to master.

My usual workflow after I've opened a lot of PR to cleanup everything is:
git rebaseall
git checkout master
git cleanup

--
wbr, Kirill

On 23. Feb 2022, at 15:10, Joshua Root > wrote:


Gerben Wierda wrote:


But I have been advised a pull is not enough, I should first do a fetch.


If you're referring to my private reply, what I said was that a rebase 
was not enough to bring master up to date with upstream/master, you 
have to fetch as well.


As per the git-pull man page:

  git pull runs git fetch with the given parameters and
   then depending on configuration options or command line flags, 
will call

   either git rebase or git merge to reconcile diverging branches.

Our project policy is to avoid merge commits.

- Josh





Re: certificate update for old Macs

2022-01-04 Thread Chris Jones


In my opinion the best way to keep older hardware secure and useful past the 
point the max macOS version they can run is long since obsolete, is to stop 
using those OSes and install an alternative. There are, e.g. plenty of linux 
distros out there and offer a modern, maintained, OS and run just fine in these 
machines…

> On 4 Jan 2022, at 8:12 pm, Richard L. Hamilton  wrote:
> 
> 
> 
>> On Jan 4, 2022, at 14:37, Michael  wrote:
>> 
>> 
>>> On 2022-01-03, at 4:12 PM, Richard L. Hamilton  wrote:
>>> 
>>> The only problem with that or anything similar, is that unless you go to 
>>> quite a lot of work to just download rather than install the PEM file, and 
>>> convert it into something human readable WITHOUT installing it, and 
>>> investigate every certificate in there, you're trusting that the site you 
>>> got it from is not only legit, but is secure and hasn't been hacked to 
>>> alter the file to provide some very bogus certificates that could work 
>>> together with some sort DNS spoofing to get you to feed sensitive 
>>> information (ie bank passwords, etc) via an untrusted site that would 
>>> capture it.
>> 
>> Makes sense. Now, how do you go about turning a certificate into something 
>> human readable? Serious question, I have *never* seen this discussed 
>> anywhere.
> 
> 
> The file that the script downloads is a whole bunch of PEM files concatenated 
> together. The script shows splitting that into separate files at the start 
> lines. Once that's done,
> 
> for file in *.pem
> do
>openssl -x509 -in $file -text >$file.txt 
> done
> 
> will convert them to something you can look at. But that's the easy part. 
> Looking at them and making sense of them and investigating each of the 169 
> will take you a day or two, which is why I'm not going to say much more about 
> it. Probably IF one used a more trusted set of root certificates for 
> comparison, one could decide which were definitely ok and which needed 
> further investigation, but automating all that would NOT BE FUN.
> 
> Arguably the best solution is to get ahold of the certificates bundled in the 
> latest OS version and use those, but no doubt that's often easier said than 
> done, although you can (given enough space) download the update image on your 
> old hardware that cannot run it, and (given enough knowledge) dig those 
> certificates out of the update image and get them into a form that you can 
> then import into your old system.
> 
> Realistically a lot could be fixed by just using keychain access to look for 
> expired root certificates, and then look through one of those stashes for 
> their replacements. Again manually, unless you want to do some very creative 
> automating. I'm not volunteering to kill days or more doing that!
> 
>> Everyone just says "As long as the roots are good you can trust the chain", 
>> and that's never made sense to me. The whole "trust what strangers say" 
>> system seems more like "Find a way for companies to make money" than any 
>> good security system.
>> 
> 
> Everything has to start somewhere. Usually that's with an OS or browser 
> vendor that decides which root certificates to bundle. (Do you REALLY want 
> one planetary certificate at the tip-top provided by the UN, with all 
> subordinate certificate issuers (government OR commercial) rooted to that? 
> It'd be possible, but it's probably better trusting a bunch of different 
> folks than trusting one with absolute power to break everything.) -Site or 
> personal certificates chain back to the issuer's certificate. There are FREE 
> CERTIFICATE ISSUERS, but they have their own problems, chiefly no budget, so 
> jumping all the auditing hoops (or even keeping their infrastructure 
> reliable) needed to get OS and browser vendors to included them can be a 
> problem for them. And old OSs and the older browser versions supported on 
> them for browsers other than the one that comes with the OS, are not 
> supported forever because nobody is getting paid to do that, so they don't 
> get updates for expired certificates, new certificate issuers, etc.
> 
> Programmers and such gotta eat too, have a roof over their heads, etc. Some 
> even have little kiddies to feed, which is hardly greed, not that there's any 
> shortage of actual greed.
> 
> Probably that site with the bunch to download is fine, but I don't have 
> access to a list of baddies, so I'm at best ambivalent about trusting it 
> without more digging first than I'm likely to do. At most, I'd do it to make 
> stuff that didn't matter work on an old system, but never run anything that 
> could lose me $$ or compromise accounts on there - so I'd have root 
> certificates but NOT iCloud keychain access enabled nor any account 
> passwords, personal certificates, etc on it.
> 
> 


Re: ffmpeg unexpectedly uninstalled

2022-01-03 Thread Chris Jones



> On 3 Jan 2022, at 11:54 pm, Michael Newman via macports-users 
>  wrote:
> 
> When I periodically update MacPorts I also run:
> 
> sudo port -f uninstall inactive

Why are you using the -f option here. That could force something to happen that 
might not be a good idea. Generally speaking you should not use it as a matter 
of course, and only when you really need to, for some specific reason.

> 
> This seemed to work fine until last month when ffmpeg was uninstalled. I 
> reinstalled and forgot about it.
> 
> But, it happened again yesterday:
> 
> --->  Deactivating ffmpeg @4.4.1_1+gpl2
> --->  Cleaning ffmpeg
> --->  Uninstalling ffmpeg @4.4.1_1+gpl2
> --->  Cleaning ffmpeg
> 
> So, I reinstalled and tried:
> 
> MrMuscle:~ mnewman$ sudo port -f uninstall inactive
> Password:
> Error: No ports matched the given expression
> 
> I checked the "requested" ports here from a file I created for the Big Sur 
> migration:
> 
> MrMuscle:~ mnewman$ ls -la /Users/mnewman/Desktop/requested.txt
> -rwxrwxrwx@ 1 mnewman  staff  359 Jun  8  2021 
> /Users/mnewman/Desktop/requested.txt*
> MrMuscle:~ mnewman$ grep ffmpeg /Users/mnewman/Desktop/requested.txt
> ffmpeg
> 
> So, ffmpeg is definitely a requested port.
> 
> I'm baffled. What's going on here?

Are you sure you don’t still have a version of ffmpeg installed ? The above 
only temoved inactive ports, it did not uninstall any active ports.

> 
> Mike Newman
> Korat, Thailand
> 


Re: [numpy @ bigsur: multithreading]

2022-01-03 Thread Chris Jones


> On 3 Jan 2022, at 5:18 pm, Maxim Abalenkov  wrote:
> 
> Dear all,
> 
> Thank you for all of your replies and suggestions! I have written my own 
> matrix multiplication script in order to test NumPy’s performance. Please 
> find it attached. I’m using the MKL variant of NumPy. Strangely enough the 
> `port variants py39-numpy` still returns:
> 
> port variants py39-numpy
> py39-numpy has the variants:
>   atlas: Use MacPorts ATLAS Libraries
> * conflicts with mkl openblas
>   gcc10: Build using the MacPorts gcc 10 compiler
> * conflicts with gcc11 gcc8 gcc9 gccdevel gfortran gfortran
>   gcc11: Build using the MacPorts gcc 11 compiler
> * conflicts with gcc10 gcc8 gcc9 gccdevel gfortran gfortran
>   gcc8: Build using the MacPorts gcc 8 compiler
> * conflicts with gcc10 gcc11 gcc9 gccdevel gfortran gfortran
>   gcc9: Build using the MacPorts gcc 9 compiler
> * conflicts with gcc10 gcc11 gcc8 gccdevel gfortran gfortran
>   gccdevel: Build using the MacPorts gcc devel compiler
> * conflicts with gcc10 gcc11 gcc8 gcc9 gfortran gfortran
> [+]gfortran: Build using the MacPorts gcc 11 Fortran compiler
> * conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel
>   mkl: Use MacPorts MKL Libraries
> * conflicts with atlas openblas
> [+]openblas: Use MacPorts OpenBLAS Libraries
> * conflicts with atlas mkl
>   universal: Build for multiple architectures
> 
> Either I don’t understand the expected behaviour or my `port variants` 
> command returns something else. I would expect it to show [+]gfortran and 
> [+]mkl, not the [+]openblas.

No. The + sign indicates which variants are enabled by default, not what you 
happened to be using yourself. For that the command you use below correctly 
shows this.

> On the other hand, command `port installed py39-numpy` shows:
> 
> port installed py39-numpy
> The following ports are currently installed:
>  py39-numpy @1.21.5_1+gfortran+mkl
>  py39-numpy @1.22.0_0+gfortran+mkl (active)
> 
> Finally, I wasn’t able to specify 8 execution threads with `export 
> MKL_NUM_THREADS=8`. NumPy was still using 4, but the `htop` reported 350–380% 
> CPU load for the `/usr/bin/env python3 ./dgemm_numpy.py` process. I think 
> this is good news!
> 
> The `otool` command executed under 
> `/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/core`
>  shows that MKL backend is being used.
> 
> otool -L _multiarray_umath.cpy
> _multiarray_umath.cpython-39-darwin.so:
>
> /opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/libmkl_rt.2.dylib
>  (compatibility version 0.0.0, current version 0.0.0)
>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 1311.0.0)
> 
> I think I still need to experiment with OpenBLAS and compare the performance 
> numbers. Thank you for your help!
> 
> —
> Best wishes,
> Maxim
> 
#!/usr/bin/env python3

import numpy as np
import time

print(np.__version__)
print(np.show_config())

m = 2
k = 2
n = 2

t0 = time.time()
alpha = np.random.rand()
beta  = np.random.rand()

A  = np.random.rand(m, k)
B  = np.random.rand(k, n)
C  = np.random.rand(m, n)
t1 = time.time()

t = t1-t0
print('Generation time: {0:f}'.format(t))
print('  alpha: {0:f},  beta: {1:f}'.format(alpha, beta))

t0 = time.time()
C  = alpha*np.matmul(A, B) + beta*C
t1 = time.time()
t  = t1-t0
print('Multiplication time: {0:f}'.format(t))

## @eof dgemm_numpy.py
> 
> 
>>> On 29 Dec 2021, at 13:33, Joshua Root  wrote:
>>> 
>>> Maxim Abalenkov wrote:
>>> 
>>> 
>>> Dear all,
>>> 
>>> I’m looking for guidance please. I would like to make sure, that I use all 
>>> eight of my CPU cores, when I run Python’s 3.9.9 NumPy on my macOS BigSur 
>>> 12.1. When I run my NumPy code, I see in ‘htop’, that only one ‘python’ 
>>> process is running and the core utilisation is 20–25%. I remember in the 
>>> past, stock MacPorts NumPy installation would use Apple’s Accelerate 
>>> library including the multithreaded BLAS and LAPACK (
>>> https://developer.apple.com/documentation/accelerate
>>> ). As I understand this is no longer the case.
>>> 
>>> I run Python code using a virtual environment located under
>>> 
>>> /opt/venv/zipfstime/lib/python3.9/site-packages/numpy/core
>>> 
>>> When I change there and issue
>>> 
>>> otool -L _multiarray_umath.cpython-39-darwin.so
>>> 
>>> _multiarray_umath.cpython-39-darwin.so:
>>>@loader_path/../.dylibs/libopenblas.0.dylib (compatibility version 
>>> 0.0.0, current version 0.0.0)
>>>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
>>> 1281.100.1)
>>> 
>>> In other words, NumPy relies on openBLAS. Command `port variants openblas` 
>>> returns
>>> 
>>> OpenBLAS has the variants:
>>>  g95: Build using the g95 Fortran compiler
>>>* conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel
>>>  gcc10: Build using the MacPorts gcc 10 compiler
>>>* conflicts with g95 g95 gcc11 gcc8 gcc9 gccdevel
>>> [+]gcc11: Build using the MacPorts gcc 11 compiler

Re: Can some ports install config files inside '/usr/local/etc'?

2021-12-11 Thread Chris Jones


Nothing in macports will be installing to /usr/local. If you have anything in 
that area it has been put there by some other means. Maybe homebrew?, but also 
a number of third party installers sometimes use this directory as well (which 
are the reasons why MacPorts specifically ignores this area).

> On 11 Dec 2021, at 5:11 am, fgyamauti2 fgyamauti2  
> wrote:
> 
> 
>   Hi,
> 
>  Apparently some ports that I've installed are making directories inside 
> '/usr/local/etc' with example configuration files. Still the installed ports 
> themselves seem to only listen to stuff inside '/opt/local/etc'.
> 
>   For instance, I have an 'unbound' folder inside both. In the former, it 
> contains 'unbound.config', while in the latter it contains 'root.key' and 
> 'unsound.config-dist' (a file with contents identical to 'unbound.config'). 
> That seems to happen to particular ports only, though. Anyone experiencing 
> that? Are these folders really unnecessary?
> 
>   Thanks in advance,
> FY
> 


Re: python ports depend on openssl not in index

2021-12-10 Thread Chris Jones



> On 10 Dec 2021, at 8:07 pm, SeaQuench  wrote:
> 
> Output of selfupdate as requested:
> 
> $ sudo port selfupdate
> --->  Updating MacPorts base sources using rsync
> Error: Error synchronizing MacPorts sources: command execution failed
> Please run `port -v selfupdate' for details.
> Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
> MacPorts sources: command execution failed
> 
> [To be clear, I consider my problem to be resolved, thanks.]

Yes, the above is clear, and I guess the reason behind this thread is you did 
not pay enough attention to it in the first case ;)

Chris
> 
> ‐‐‐ Original Message ‐‐‐
> 
>> On Friday, December 10th, 2021 at 2:21 PM, Chris Jones 
>>  wrote:
>> 
>> Hi,
>> 
>> Yes, the error is expected. What i am asking is if you get any indication or 
>> not that there was an issue when you run without the verbose flag. If not, 
>> then i think thats a bug we should address.
>> 
>> Chris
>> 
>>>> On 10 Dec 2021, at 7:18 pm, SeaQuench seaque...@protonmail.com wrote:
>>> 
>>> I am behind a firewall, so this is the following is predictable:
>>> 
>>> $ sudo port -v selfupdate
>>> 
>>> ---> Updating MacPorts base sources using rsync
>>> 
>>> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
>>> 
>>> rsync error: error in socket IO (code 10) at 
>>> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
>>>  [receiver=2.6.9]
>>> 
>>> Command failed: /usr/bin/rsync -rtzvl --delete-after 
>>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>> 
>>> Exit code: 10
>>> 
>>> Error: Error synchronizing MacPorts sources: command execution failed
>>> 
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
>>>> jon...@hep.phy.cam.ac.uk wrote:
>>>> 
>>>> Just to be clear, are you saying running
>>>> 
>>>>> sudo port selfupdate
>>>> 
>>>> ran without warnings or error, but did not actually update ? If thats the 
>>>> case we should file a bug against base as if the rsync fails it should 
>>>> indicate this to the user ?
>>>> 
>>>> cheers Chris
>>>> 
>>>>>> On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
>>>>> 
>>>>> Ryan is correct; I had been sync'ing my port index successfully, but 
>>>>> MacPorts itself grew stale due to my being unable to run selfupdate. The 
>>>>> MacPorts Migration Guide suggested a manual update (i.e. reinstall) which 
>>>>> I believe got me going again. Thanks guys! ~SeaQuench
>>>>> 
>>>>> ‐‐‐ Original Message ‐‐‐
>>>>> 
>>>>>> On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
>>>>>> ryandes...@macports.org wrote:
>>>>> 
>>>>>> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>>>>>> 
>>>>>>> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>>>>>>> 
>>>>>>>> After downloading and installing the latest MacPorts for Catalina, I 
>>>>>>>> followed the instructions to migrate MacPorts: 
>>>>>>>> https://trac.macports.org/wiki/Migration
>>>>>>>> 
>>>>>>>> Reinstalling the ports went without issue until Step 3e: `sudo 
>>>>>>>> ./restore_ports.tcl myports.txt`
>>>>>>>> 
>>>>>>>> Executing that command resulted in the error I presented initially:
>>>>>>>> 
>>>>>>>> ---> Computing dependencies for python38
>>>>>>>> 
>>>>>>>> Error: Dependency 'openssl3' not found.
>>>>>>>> 
>>>>>>>> ---> Computing dependencies for python39
>>>>>>>> 
>>>>>>>> Error: Dependency 'openssl3' not found.
>>>>>>>> 
>>>>>>>> Is that to be expected on a fresh install (before performing a sync)? 
>>>>>>>> I acknowledge that this outcome may result from the use of git versus 
>>>>>>>> rsync in 

Re: python ports depend on openssl not in index

2021-12-10 Thread Chris Jones
Hi,

Yes, the error is expected. What i am asking is if you get any indication or 
not that there was an issue when you run without the verbose flag. If not, then 
i think thats a bug we should address.

Chris

> On 10 Dec 2021, at 7:18 pm, SeaQuench  wrote:
> 
> I am behind a firewall, so this is the following is predictable:
> 
> $ sudo port -v selfupdate
> --->  Updating MacPorts base sources using rsync
> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
> rsync error: error in socket IO (code 10) at 
> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54.120.1/rsync/clientserver.c(106)
>  [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzvl --delete-after 
> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
> Exit code: 10
> Error: Error synchronizing MacPorts sources: command execution failed
> 
> ‐‐‐ Original Message ‐‐‐
> 
>> On Friday, December 10th, 2021 at 10:24 AM, Christopher Jones 
>>  wrote:
>> 
>> Just to be clear, are you saying running
>> 
>>> sudo port selfupdate
>> 
>> ran without warnings or error, but did not actually update ? If thats the 
>> case we should file a bug against base as if the rsync fails it should 
>> indicate this to the user ?
>> 
>> cheers Chris
>> 
>>>> On 10 Dec 2021, at 3:13 pm, SeaQuench seaque...@protonmail.com wrote:
>>> 
>>> Ryan is correct; I had been sync'ing my port index successfully, but 
>>> MacPorts itself grew stale due to my being unable to run selfupdate. The 
>>> MacPorts Migration Guide suggested a manual update (i.e. reinstall) which I 
>>> believe got me going again. Thanks guys! ~SeaQuench
>>> 
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On Friday, December 10th, 2021 at 3:35 AM, Ryan Schmidt 
>>>> ryandes...@macports.org wrote:
>>> 
>>>> On Dec 10, 2021, at 02:29, Chris Jones wrote:
>>>> 
>>>>> On 9 Dec 2021, at 10:49 pm, SeaQuench wrote:
>>>>> 
>>>>>> After downloading and installing the latest MacPorts for Catalina, I 
>>>>>> followed the instructions to migrate MacPorts: 
>>>>>> https://trac.macports.org/wiki/Migration
>>>>>> 
>>>>>> Reinstalling the ports went without issue until Step 3e: `sudo 
>>>>>> ./restore_ports.tcl myports.txt`
>>>>>> 
>>>>>> Executing that command resulted in the error I presented initially:
>>>>>> 
>>>>>> ---> Computing dependencies for python38
>>>>>> 
>>>>>> Error: Dependency 'openssl3' not found.
>>>>>> 
>>>>>> ---> Computing dependencies for python39
>>>>>> 
>>>>>> Error: Dependency 'openssl3' not found.
>>>>>> 
>>>>>> Is that to be expected on a fresh install (before performing a sync)? I 
>>>>>> acknowledge that this outcome may result from the use of git versus 
>>>>>> rsync in keeping MacPorts up to date. I am behind a firewall, so i must 
>>>>>> use git to sync rather than use rsync.
>>>>>> 
>>>>>> https://trac.macports.org/wiki/howto/SyncingWithGit
>>>>>> 
>>>>>> If i substitute the command `sudo port -v sync` for the command `sudo 
>>>>>> port selfupdate` - as usual - I can now install openssl without error, 
>>>>>> and all dependencies are found after re-executing: `sudo 
>>>>>> ./restore_ports.tcl myports.txt`
>>>>> 
>>>>> We need to see why you are not finding the openssl3 port, as that has 
>>>>> been available for some time.
>>>>> 
>>>>> Please run
>>>>> 
>>>>> sudo port -d sync
>>>>> 
>>>>> And post what you get back to the list
>>>> 
>>>> They already said that after running "sudo port sync", everything is 
>>>> working.
>>>> 
>>>> "sudo port selfupdate" should selfupdate (update MacPorts base) and sync 
>>>> (update ports tree). If updating base failed for some reason, then it 
>>>> might not update the ports tree either. You mentioned being behind a 
>>>> firewall that prevents you from syncing with rsync. selfupdate has no 
>>>> option but to use rsync, so that would be a likely explanation for why 
>>>> selfupdate doesn't work for you, and why you should not use selfupdate and 
>>>> should instead (i) update MacPorts base manually when a new version is 
>>>> available, using an installer from our web site and (ii) sync to update 
>>>> ports.


Re: python ports depend on openssl not in index

2021-12-10 Thread Chris Jones

Hi,

Please always remember to reply to the list.

We need to see why you are not finding the openssl3 port, as that has been 
available for some time.

Please run

sudo port -d sync

And post what you get back to the list

Chris

> On 9 Dec 2021, at 10:49 pm, SeaQuench  wrote:
> 
> 
> After downloading and installing the latest MacPorts for Catalina, I followed 
> the instructions to migrate MacPorts: https://trac.macports.org/wiki/Migration
> Reinstalling the ports went without issue until Step 3e: `sudo 
> ./restore_ports.tcl myports.txt`
> Executing that command resulted in the error I presented initially:
> --->  Computing dependencies for python38
> Error: Dependency 'openssl3' not found.
> --->  Computing dependencies for python39
> Error: Dependency 'openssl3' not found.
> 
> Is that to be expected on a fresh install (before performing a sync)? I 
> acknowledge that this outcome may result from the use of git versus rsync in 
> keeping MacPorts up to date. I am behind a firewall, so i must use git to 
> sync rather than use rsync.
> https://trac.macports.org/wiki/howto/SyncingWithGit
> If i substitute the command `sudo port -v sync` for the command `sudo port 
> selfupdate` - as usual - I can now install openssl without error, and all 
> dependencies are found after re-executing: `sudo ./restore_ports.tcl 
> myports.txt`
> 
> Any additional advice welcome. Thanks for the tip on migration, Chris!
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
>> On Thursday, December 9th, 2021 at 2:47 PM, Chris Jones 
>>  wrote:
>> 
>> 
>> 
>> Did you follow the migration guide when moving to a new major os version ?
>> 
>> https://trac.macports.org/wiki/Migration
>> 
>> If not, follow it now, to wipe out your ports and reinstall them correctly 
>> for the new os.
>> 
>> If you did, your ports tree seems to be very out of date. Then try,
>> 
>> > sudo port selfupdate
>> > sudo port sync
>> > sudo port upgrade outdated
>> 
>> Chris
>> 
>>>> On 9 Dec 2021, at 6:53 pm, SeaQuench via macports-users 
>>>>  wrote:
>>> 
>>> 
>>> 
>>> After applying an update to MacOS last August, the python ports are 
>>> reporting a dependency on either openssl11 or openssl3, neither of which 
>>> are to be found in the (local?) index for MacPorts, according to the error 
>>> I have received, copied below. While I am prompted to report a bug, I 
>>> presume I am not in a novel situation. Could someone advise me as to how to 
>>> proceed? I am running MacPorts 2.6.2 on MacOS 10.15.7 with XCode 12.4 
>>> installed.
>>> $ sudo port install python39 
>>> 
>>> 
>>> 
>>> 
>>> Warning: No port openssl3 found in the index. 
>>> ---> Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found. 
>>> Error: Unable to execute port: upgrade openssl failed 
>>> 
>>> 
>>> 
>>> 
>>> $ sudo port install openssl 
>>> 
>>> 
>>> 
>>> 
>>> ---> Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found. 
>>> Error: Follow https://guide.macports.org/#project.tickets to report a bug. 
>>> Error: Processing of port openssl failed
>>> 
>>> 
>>> $ sudo port -n upgrade --force python38
>>> --->  Computing dependencies for python38
>>> --->  Fetching archive for python38
>>> --->  Attempting to fetch 
>>> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2 from 
>>> https://packages.macports.org/python38
>>> --->  Attempting to fetch 
>>> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2.rmd160 from 
>>> https://packages.macports.org/python38
>>> --->  Installing python38 @3.8.12_4+optimizations
>>> --->  Cleaning python38
>>> --->  Computing dependencies for python38
>>> --->  Deactivating python38 @3.8.11_0
>>> --->  Cleaning python38
>>> --->  Activating python38 @3.8.12_4+optimizations
>>> --->  Cleaning python38
>>> --->  Updating database of binaries
>>> --->  Scanning binaries for linking errors
>>> --->  Found 18 broken files, matching files to ports 
>>> --->  Found 4 broken ports, determining rebuild order
>>> You can always run 'port rev-upgrade' again to fix errors.
>>> The following ports will be rebuilt:
>>>  python38 @3.8.12+optimizations
>>>  python39 @3.9.6
>>>  glib2 @2.58.3+x11
>>>  gobject-introspection @1.60.2
>>> Continue? [Y/n]: y
>>> Warning: No port openssl3 found in the index.
>>> --->  Computing dependencies for openssl
>>> Error: Dependency 'openssl3' not found.
>>> Error: rev-upgrade failed: Error rebuilding python38
>>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>>> 
>>> 
> 
> 


Re: python ports depend on openssl not in index

2021-12-09 Thread Chris Jones

Did you follow the migration guide when moving to a new major os version ?

https://trac.macports.org/wiki/Migration

If not, follow it now, to wipe out your ports and reinstall them correctly for 
the new os.

If you did, your ports tree seems to be very out of date. Then try,

> sudo port selfupdate
> sudo port sync
> sudo port upgrade outdated

Chris

> On 9 Dec 2021, at 6:53 pm, SeaQuench via macports-users 
>  wrote:
> 
> 
> After applying an update to MacOS last August, the python ports are reporting 
> a dependency on either openssl11 or openssl3, neither of which are to be 
> found in the (local?) index for MacPorts, according to the error I have 
> received, copied below. While I am prompted to report a bug, I presume I am 
> not in a novel situation. Could someone advise me as to how to proceed? I am 
> running MacPorts 2.6.2 on MacOS 10.15.7 with XCode 12.4 installed.
> 
> $ sudo port install python39 
> Warning: No port openssl3 found in the index. 
> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found. 
> Error: Unable to execute port: upgrade openssl failed 
> $ sudo port install openssl 
> ---> Computing dependencies for openssl
> Error: Dependency 'openssl3' not found. 
> Error: Follow https://guide.macports.org/#project.tickets to report a bug. 
> Error: Processing of port openssl failed
> $ sudo port -n upgrade --force python38
> --->  Computing dependencies for python38
> --->  Fetching archive for python38
> --->  Attempting to fetch 
> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2 from 
> https://packages.macports.org/python38
> --->  Attempting to fetch 
> python38-3.8.12_4+optimizations.darwin_19.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/python38
> --->  Installing python38 @3.8.12_4+optimizations
> --->  Cleaning python38
> --->  Computing dependencies for python38
> --->  Deactivating python38 @3.8.11_0
> --->  Cleaning python38
> --->  Activating python38 @3.8.12_4+optimizations
> --->  Cleaning python38
> --->  Updating database of binaries
> --->  Scanning binaries for linking errors
> --->  Found 18 broken files, matching files to ports 
> --->  Found 4 broken ports, determining rebuild order
> You can always run 'port rev-upgrade' again to fix errors.
> The following ports will be rebuilt:
>  python38 @3.8.12+optimizations
>  python39 @3.9.6
>  glib2 @2.58.3+x11
>  gobject-introspection @1.60.2
> Continue? [Y/n]: y
> Warning: No port openssl3 found in the index.
> --->  Computing dependencies for openssl
> Error: Dependency 'openssl3' not found.
> Error: rev-upgrade failed: Error rebuilding python38
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> 


Re: is macports getting rusty?

2021-11-29 Thread Chris Jones



To first order builds are done on a first-committed-first-built basis. 
The time a build takes is not something known up front so prioritizing 
basis on this would anyway not really be feasible.


Yes, the builders must install the dependencies of a port before a given 
port can be built. If one of those deps also has an update in the queue, 
later on than the current build, but needed for the build then it will 
be done 'early'. so in a sense it is correct that commonly used 
dependencies will tend to get built a bit faster than they might 
otherwise get done.


'Normally' though the builders keep up with the pace of commits, so the 
build queue is reasonable short. It can happen that some commit might 
happen that requires a lot of ports to get built, or a big build (like 
gcc, clang or rust) comes along that causes a small backlog to build up. 
These are usually cleared quite quickly (by which I mean a few days).


Another cause of a backlog is when a new builder is added, like was done 
recently for macOS12. The builders in this case have to work their way 
through all the various deps, so a backlog can build up that takes a 
while to clear.


Chris

On 29/11/2021 2:32 pm, Richard L. Hamilton wrote:
I would expect that the buildbots also need to satisfy dependencies, and 
thus, heavily-depended on builds would tend to be done earlier, 
regardless of whether or not they were large and slow; and if they are 
large and slow, they're arguably delaying the building of even more 
smaller ports that don't depend on them, which is not necessarily a gain.


If I'm right about ports being built also by the buildbots in dependency 
order, any further tweak to build order would likely have minimal benefits.


The real improvement would be more buildbots, but that would take either 
a way of trusting volunteer buildbots (and that they were managed 
properly to produce fully correct results, and quite possibly dedicated 
to the purpose to avoid anything that would conflict or interfere), or 
an actual budget, or donated servers and server farm space, power, 
cooling, etc. Another improvement might be more people qualified, 
trusted, and authorized to babysit the buildbots, and/or automatic 
tickets on failed builds, since if a build on a buildbot fails, it's 
either a problem with the buildbot or with the port itself; and in the 
latter case, those building themselves will also have the problem.


On Nov 29, 2021, at 09:15, Bill Cole 
<mailto:macportsusers-20171...@billmail.scconsult.com>> wrote:


On 2021-11-29 at 08:32:46 UTC-0500 (Mon, 29 Nov 2021 13:32:46 +0000)
Chris Jones mailto:jon...@hep.phy.cam.ac.uk>>
is rumored to have said:

If you find yourself during an port update building rust from source, 
either just let it finish, or if you don't want your machine tied up 
building rust for some period, just cancel the build and try again 
later on, as as others have pointed out eventually the buildbots will 
provide the binary tarball for it and thus you will just pick that 
once its available.


This raises a question that I cannot find a clear answer to:

How are builds prioritized on the buildbots?

I would hope that in an ideal world, some priority is given to large, 
slow, and heavily-depended-upon builds. It's also easier to say that 
than to actually implement it, but it would help address a real pain 
point in using MacPorts.



--
Bill Cole
b...@scconsult.com <mailto:b...@scconsult.com> or billc...@apache.org 
<mailto:billc...@apache.org>

(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire



--
eMail:mailto:rlha...@smart.net <mailto:rlha...@smart.net>






Re: is macports getting rusty?

2021-11-29 Thread Chris Jones



Give the developers of rust itself a piece of your mind if you like, 
over how slow it is to compile. Good luck with that - I suspect to be 
THAT slow (although really? compiling a C compiler suite plus library 
isn't exactly fast either) they might be doing some things by brute 
force that they haven't got any other good way to do - like running a 
serious test suite, as just one example. And of course they're the ones 
that suffer most over how slow it is to compile, since they have to 
rebuild rust every time they want to test some seemingly minor change. 
So I suspect they're already doing what can to speed it up that they 
don't think sacrifices any other concern.


Actually building rust does NOT take that much longer than any other 
compiler tool kit, such as gcc or LLVM(clang) . This is in part because 
rust itself is based on LLVM and internally the build compiles its own 
LLVM instance before going on to build the rust specific parts on top of 
that. This accounts from probably something like 60-70% of the total 
build time.


If you find yourself during an port update building rust from source, 
either just let it finish, or if you don't want your machine tied up 
building rust for some period, just cancel the build and try again later 
on, as as others have pointed out eventually the buildbots will provide 
the binary tarball for it and thus you will just pick that once its 
available.


Chris


Re: Does MacPorts depend on Spotlight?

2021-11-17 Thread Chris Jones



Some users might find it useful, and the exact volume to exclude depends 
on the details of the users installation, which would be difficult to 
automate. So I think its fine to just leave it to be done by hand by 
those that wish to.


On 17/11/2021 3:09 pm, André-John Mas wrote:
Just wondering whether it would make sense for MacPorts to auto exclude 
that folder? Does spotlight even provide an API or command that would 
allow MacPorts to do that?


André-John

Sent from my phone. Envoyé depuis mon téléphone.


On 16 Nov 2021, at 21:03, Richard L. Hamilton  wrote:

Good, thanks. Perhaps I wouldn't exclude the whole /opt/local (or 
whatever install prefix) unless performance is a major issue, but 
/opt/local/var/macports, which is less likely to be interesting in 
terms of commands or configuration files or documentation, and both 
large (mine is 24GiB when the entire /opt/local is only 35GiB - and I 
frequently remove most inactive ports and run a port clean installed) 
and active in terms of changes.


On Nov 16, 2021, at 16:06, Chris Jones <mailto:jon...@hep.phy.cam.ac.uk>> wrote:



I am not aware of any use macports itself makes of spotlight, so for 
sure if you don’t plan on using it yourself to search the install 
prefix, you can disable it.


On 16 Nov 2021, at 6:26 am, Richard L. Hamilton <mailto:rlha...@smart.net>> wrote:


Seems it'd thrash Spotlight a lot less during "port selfupdate" or 
"port upgrade outdated" to exclude /opt/local, as long as that 
wouldn't break anything (obviously one couldn't then use Spotlight 
to search /opt/local, but that's ok with me).





--
eMail:mailto:rlha...@smart.net <mailto:rlha...@smart.net>






Re: Does MacPorts depend on Spotlight?

2021-11-16 Thread Chris Jones

I am not aware of any use macports itself makes of spotlight, so for sure if 
you don’t plan on using it yourself to search the install prefix, you can 
disable it.

> On 16 Nov 2021, at 6:26 am, Richard L. Hamilton  wrote:
> 
> Seems it'd thrash Spotlight a lot less during "port selfupdate" or "port 
> upgrade outdated" to exclude /opt/local, as long as that wouldn't break 
> anything (obviously one couldn't then use Spotlight to search /opt/local, but 
> that's ok with me).
> 
> 


Re: xorg-server

2021-11-12 Thread Chris Jones



> On 12 Nov 2021, at 6:59 pm, Tom  wrote:
> 
> 
>> 
>>> Hi, 
>>> 
>>> when trying to run an X11 program, I get the following error message:
>>> 
>>> (putty:8198): Gtk-WARNING **: 00:06:49.190: cannot open display: :0
>>> 
>>> How can I fix that?
>> 
>> Assuming you are running Mac OS X 10.5 or later:
>> 
>> Check your .zprofile or .profile or .bash_profile for a line like:
>> 
>> DISPLAY=:0
>> 
>> Delete it.
>> 
>> The MacPorts 2.6.4 installer for macOS 11 erroneously added this line. This 
>> problem has been fixed in newer versions of the MacPorts installer but any 
>> erroneous DISPLAY line added by the 2.6.4 installer needs to be removed 
>> manually.
> 
> Now xorg-server is starting and quiting. The app does not appear.
> What could be the problem?

Impossible to say without more data.

Do you have any crash logs in Console ? Any other messages ?

What application are you running ? Try install a simple one like xclock and see 
if that works ?

Have you tired removing then reinstalling the xorg-server port ?

Are you actually using the xorg-server X11 server or do you perhaps have 
another one installed instead ?

Have you logged out and back in again, as required by the xorg-server 
instalation ?

Chris





Re: provide latest OS root certificates via port?

2021-10-31 Thread Chris Jones

I have always favoured VMWare over parallels myself, and they now offer a free 
license for non-commerical usages.

https://customerconnect.vmware.com/web/vmware/evalcenter?p=fusion-player-personal

> On 31 Oct 2021, at 12:07 pm, Richard L. Hamilton  wrote:
> 
> Years ago, creating a (then OS X, now macOS) VM under free VirtualBox was a 
> horrid pain (which is why I'm running the relatively expensive but nicer 
> Parallels for that and VMs other than Solaris).
> 
> But apparently now it's relatively easy. You do need plenty of extra disk 
> space and I'd say 8GB more ram than you'd otherwise need. See 
> https://www.soupbowl.io/2020/04/macos-in-virtualbox/
> (I haven't tried it, but it looks believable)
> 
> 
>> On Oct 31, 2021, at 06:46, Henning Hraban Ramm  wrote:
>> 
>> I’m working on a 2013 Mac mini and can’t upgrade further than 10.14 (don’t 
>> want to loose my 32 bit software, and I seem too stupid for VMs).
> 
> 


Re: Does MacPorts need ALL of Xcode?

2021-09-27 Thread Chris Jones


> On 27 Sep 2021, at 10:36 pm, Ian Wadham  wrote:
> 
> Hello Chris,
> 
>> On 27 Sep 2021, at 8:42 am, Chris Jones  wrote:
>> The majority of ports will indeed build fine with just the CLT installed.
> 
> So what is the “recipe” to install just the CLT with no version of Xcode 
> present? And can that recipe be included in the MacPorts Guide?

I’ve no idea on the ‘best’ way as personally i want Xcode anyway, but you could 
try navigating to 

https://developer.apple.com/download/more/?=command%20line%20tools 

and install the correct version from there. If your next question is whats the 
correct version see

https://trac.macports.org/wiki/XcodeVersionInfo

> 
>> There are a number though where the build does indeed require a complete 
>> Xcode installation, which is why the baseline recommendation is to install 
>> Xcode. However if you are ok with perhaps running into the occasional port 
>> failure (the likelihood for which depends on which ports you use) you likely 
>> can get by just fine with just the CLT.
> 
> Couldn’t those ports list Xcode as a build dependency?

Not just like a regular port dep., so it gets installed as required.

There is an Xcode PG which handles this and I think errors out if Xcode is not 
installed, so its fairly obvious what is wrong.
> 
> If a dependency has to be another MacPorts package, then perhaps there could 
> be a dummy Xcode in MacPorts, maybe just a Portfile, that checks the presence 
> and version of the Xcode.app.

See above. A PG to handle this already exists.
> 
> Otherwise, new MacPorts users may be paying a 20Gb disk storage penalty 
> forever more. And the time to download and install Xcode could become a 
> disincentive for new MacPorts users in any case…
> 
> Cheers, Ian Wadham.
> 
>> Chris
>> 
>>>> On 26 Sep 2021, at 10:07 am, Mircea Trandafir  wrote:
>>> 
>>>  I’ve been using only the command line tools for more than a year with 
>>> absolutely no issues (other than the occasional “version not detected” 
>>> error, but I think that happens with Xcode too).
>>> 
>>> -- 
>>> Mircea Trandafir
>>> Associate professor
>>> Department of Economics
>>> University of Southern Denmark
>>> Campusvej 55, 5230 Odense M
>>> Denmark
>>> Email: mircea.tranda...@sam.sdu.dk
>>> Web: http://www.mirceatrandafir.com
>>> 
>>>> On Sep 26, 2021, at 5:52 AM, Ian Wadham  wrote:
>>>> 
>>>> Hi guys,
>>>> 
>>>> I have recently upgraded my MacOS from High Sierra 10.13 to Catalina 
>>>> 10.15, mainly because I would like to start playing with a package called 
>>>> Flutter, which has a dependency on Xcode 12+ in its MacBook version.
>>>> 
>>>> It appears that Xcode is following some variant of Grosch’s Law, or maybe 
>>>> Parkinson’s Law (software expands to fill the hardware space available to 
>>>> it). So I am wondering, if all a user needs are some MacPorts packages, 
>>>> whether it is necessary to install all (or even any) of Xcode just to get 
>>>> the command-line tools.
>>>> 
>>>> I have been using MacPorts to get access to FOSS for more than 10 years 
>>>> and have watched the Xcode requirement grow from around 1 Gb of disk to 
>>>> around 20 Gb in Catalina. In Xcode 9, on High Sierra, the requirement was 
>>>> around 10 Gb. So it has roughly doubled in two version steps of MacOS.
>>>> 
>>>> At first I used to regard the Xcode overhead as being like some sort of 
>>>> tax on the pleasure of using FOSS, but now it is taking up an unhealthy 
>>>> portion of the 250 Gb in my MacBook Pro’s 250 Gb internal SSD drive.
>>>> 
>>>> I have to put up with this if I wish to use Macports and Flutter, even 
>>>> though, like Dave Horsfall, I am unlikely to use Xcode as an IDE. So is it 
>>>> possible to have MacPorts depend on some minimal subset of Xcode?
>>>> 
>>>> Cheers,
>>>> Ian Wadham.
>>>> 
> 


Re: Does MacPorts need ALL of Xcode?

2021-09-26 Thread Chris Jones

The majority of ports will indeed build fine with just the CLT installed. There 
are a number though where the build does indeed require a complete Xcode 
installation, which is why the baseline recommendation is to install Xcode. 
However if you are ok with perhaps running into the occasional port failure 
(the likelihood for which depends on which ports you use) you likely can get by 
just fine with just the CLT.

Chris

> On 26 Sep 2021, at 10:07 am, Mircea Trandafir  wrote:
> 
>  I’ve been using only the command line tools for more than a year with 
> absolutely no issues (other than the occasional “version not detected” error, 
> but I think that happens with Xcode too).
> 
> -- 
> Mircea Trandafir
> Associate professor
> Department of Economics
> University of Southern Denmark
> Campusvej 55, 5230 Odense M
> Denmark
> Email: mircea.tranda...@sam.sdu.dk
> Web: http://www.mirceatrandafir.com
> 
>>> On Sep 26, 2021, at 5:52 AM, Ian Wadham  wrote:
>>> 
>> Hi guys,
>> 
>> I have recently upgraded my MacOS from High Sierra 10.13 to Catalina 10.15, 
>> mainly because I would like to start playing with a package called Flutter, 
>> which has a dependency on Xcode 12+ in its MacBook version.
>> 
>> It appears that Xcode is following some variant of Grosch’s Law, or maybe 
>> Parkinson’s Law (software expands to fill the hardware space available to 
>> it). So I am wondering, if all a user needs are some MacPorts packages, 
>> whether it is necessary to install all (or even any) of Xcode just to get 
>> the command-line tools.
>> 
>> I have been using MacPorts to get access to FOSS for more than 10 years and 
>> have watched the Xcode requirement grow from around 1 Gb of disk to around 
>> 20 Gb in Catalina. In Xcode 9, on High Sierra, the requirement was around 10 
>> Gb. So it has roughly doubled in two version steps of MacOS.
>> 
>> At first I used to regard the Xcode overhead as being like some sort of tax 
>> on the pleasure of using FOSS, but now it is taking up an unhealthy portion 
>> of the 250 Gb in my MacBook Pro’s 250 Gb internal SSD drive.
>> 
>> I have to put up with this if I wish to use Macports and Flutter, even 
>> though, like Dave Horsfall, I am unlikely to use Xcode as an IDE. So is it 
>> possible to have MacPorts depend on some minimal subset of Xcode?
>> 
>> Cheers,
>> Ian Wadham.
>> 


Re: code::blocks and X11 via MacPorts: is this as it is supposed to be?

2021-09-12 Thread Chris Jones

sudo port install xorg-server

Logout and back in again

> On 12 Sep 2021, at 11:17 am, Gerben Wierda via macports-users 
>  wrote:
> 
> I’ve been trying out code::blocks and X11 installed via MacPorts and I’m 
> under the impression something is missing.
> 
> I installed using
> 
> sudo port install org
> sudo port install codeblocks
> 
> Logging out and in again made sure the correct environment variables are set. 
>  When I then open codeblocks, I see a lot of error messages like this:
> 
> (codeblocks:75317): Gtk-CRITICAL **: 12:02:13.796: gtk_box_gadget_distribute: 
> assertion 'size >= 0' failed in GtkScrollbar
> 
> But the system does seem to launch.
> 
> Trying to launch xeyes as a test, gets me a huge entire-screen sized xeyes 
> and no way to turn that into a small window somewhere.
> 
> Is that as it is supposed to be?
> 
> Gerben Wierda (LinkedIn)
> R Enterprise Architecture (main site)
> Book: Chess and the Art of Enterprise Architecture
> Book: Mastering ArchiMate
> 


Re: cdrtools streamripper

2021-06-10 Thread Chris Jones


> On 10 Jun 2021, at 9:05 am, Giuseppe Di Matteo  
> wrote:
> 
> I opened ticket #63062.
> What about streamripper. Configure failed for libmad. (Big Sur arm64)

Same. Check for and if need be open tickets against failing ports.

> 
> Pino Di Matteo
> pinodimat...@me.com
> 
> 
> 
>> Le 9 juin 2021 à 11:04, Christopher Jones  a écrit 
>> :
>> 
>> 
>> Please check for an open trac ticket, and if one does not exist open one.
>> 
>>> On 9 Jun 2021, at 9:47 am, Giuseppe Di Matteo  
>>> wrote:
>>> 
>>> I made the change in the Portfile, but it still won’t install. It seems 
>>> that the problem is now with the arch arm64 (Mac mini M1).
>>> Giuseppe Di Matteo
>>> pinodimat...@me.com
>>> 
>>> 
>>> 
>>> 
>>> 
 Le 8 juin 2021 à 20:48, Christopher Jones  a 
 écrit :
 
 
 For the smake issue see
 
 https://github.com/macports/macports-ports/commit/9040f7195e114173a42c71ee57e74c248ef7ebb1
 
> On 7 Jun 2021, at 5:15 pm, Andrew Udvare  wrote:
> 
> 
>> On 2021-06-07, at 09:34, Giuseppe Di Matteo via macports-users 
>>  wrote:
>> 
>> I can’t install cdrtools and streamripper on macOS 11 (Big Sur).
>> 
>> Giuseppe Di Matteo
>> pinodimat...@me.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> I can reproduce the issue with cdrtools. `smake` does not accept -j.
> 
> I cannot reproduce the issue with streamripper. streamripper builds for 
> me. However, I am on x86-64.
 
>>> 
>> 
> 


Re: MacPorts 2.7.0 has been released

2021-05-19 Thread Chris Jones
See `config.log' for more details

We need to see what is in this file… (from the messages you posted below).

Chris

> On 19 May 2021, at 3:06 pm, Bjarne D Mathiesen  
> wrote:
> 
> OK -
> 
> on 10.6.8 I get :
> 
> #=> ls -l /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  32  4 Jan 14:50 /usr/bin/cc ->
> ../llvm-gcc-4.2/bin/llvm-gcc-4.2
> #=> ls -l /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
> -rwxrwxr-x  1 root  admin  116992 12 Feb  2011
> /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
> 
> 
> on 10.15.7 I get :
> 
> #=> ls -l /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  5  1 Mar 13:06 /usr/bin/cc -> clang
> #=> ll /usr/bin/clang
> -rwxr-xr-x  1 root  wheel  31488 21 Sep  2020 /usr/bin/clang
> 
> 
> So the (temporary) fix for me on 10.6.8 is :
> 
> #=> which clang
> /opt/local/bin/clang
> #=> mv /usr/bin/cc /usr/bin/cc.apple
> #=> ln -s $( which clang ) /usr/bin/cc
> #=> ll /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  20 19 Maj 15:53 /usr/bin/cc ->
> /opt/local/bin/clang
> 
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ---
> denne besked er skrevet i et totalt M$-frit miljø
> OpenCore + macOS 10.15.7 Catalina
> MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
> ATI Radeon RX 590 8 GB


Re: port update outdated 'Failed to archivefetch aom: version @3.1.0_0'

2021-05-12 Thread Chris Jones

Error: Follow https://guide.macports.org/#project.tickets to report a bug.

Please follow the instructions you were given above to either open a ticket or 
see if one for this issue already exists.

> On 12 May 2021, at 8:25 pm, tom eee  wrote:
> 
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.


Re: OpenMPI Users - Is Anyone Using openmpi-clang33 or openmpi-clang34?

2021-05-07 Thread Chris Jones



> On 7 May 2021, at 8:33 pm, Ken Cunningham  
> wrote:
> 
> There is one issue with that.
> 
> qt5-qtcreator needs clang-10 on arm for it’s libraries (that is actually the 
> only reason why I initially fixed clang-10 to work on arm64 in the first 
> place).
> 
> qt5-qtcreator cannot (could not) use any newer clang when I checked six 
> months ago.
> 
> So — we still need clang-10 on arm64 even if we don’t use it as a compiler 
> there.

We can at least though not bother building the openmpi versions for these 
clangs, even if we have to keep clang10 around for arm until we can migrate the 
above to clang11.

Cheers Chris
> 
> K
> 
> 
> 
>> On May 7, 2021, at 12:22 PM, Chris Jones  wrote:
>> 
>> Hi,
>> 
>> Another clean up suggestion is to remove all clangs apart from 11+ for 
>> macOS11(arm). I just noticed the buildbots building the clang-9.0 version 
>> for arm, but its worth noting that clang 9.0 and 10 are not reliable for 
>> arm, I have seen them generate bad code, fail with ICEs, so really there is 
>> little point in providing all but the clang11(and newer) version which is 
>> the first version with reliable arm support.
>> 
>> Chris
>> 
>>>> On 7 May 2021, at 8:11 pm, Ken Cunningham 
>>>>  wrote:
>>> 
>>> Yes, gcc7 works down to 10.4, both PPC and Intel and is the primary 
>>> compiler there.  I can see no need for openMPI to support any older gcc.
>>> 
>>> clang-3.3, clang-3.4, and clang-3.7 should not be used for anything other 
>>> than bootstrapping to newer clangs now.
>>> 
>>> 
>>> Ken
>>> 
>>> 
>> 
> 



Re: OpenMPI Users - Is Anyone Using openmpi-clang33 or openmpi-clang34?

2021-05-07 Thread Chris Jones
Hi,

Another clean up suggestion is to remove all clangs apart from 11+ for 
macOS11(arm). I just noticed the buildbots building the clang-9.0 version for 
arm, but its worth noting that clang 9.0 and 10 are not reliable for arm, I 
have seen them generate bad code, fail with ICEs, so really there is little 
point in providing all but the clang11(and newer) version which is the first 
version with reliable arm support.

Chris

> On 7 May 2021, at 8:11 pm, Ken Cunningham  
> wrote:
> 
> Yes, gcc7 works down to 10.4, both PPC and Intel and is the primary compiler 
> there.  I can see no need for openMPI to support any older gcc.
> 
> clang-3.3, clang-3.4, and clang-3.7 should not be used for anything other 
> than bootstrapping to newer clangs now.
> 
> 
> Ken
> 
> 



Re: OpenMPI Users - Is Anyone Using openmpi-clang33 or openmpi-clang34?

2021-05-07 Thread Chris Jones
Hi,

I would suggest maybe its worth pruning the gcc list a bit as well ? I believe 
e.g. gcc7 at least works all the way down to 10.5, perhaps even older ? Do we 
still need gcc 5, 6?

Chris

> On 7 May 2021, at 1:35 pm, Christopher Nielsen  
> wrote:
> 
> Folks,
> 
> We’re considering retirement of ports openmpi-clang33 and openmpi-clang34, to 
> reduce the number of openmpi-* ports we support. At the moment, the list is 
> quite large, and it’s becoming a challenge to thoroughly test and maintain 
> all of these:
> 
> openmpi-clang  @4.1.1  science/openmpi
> openmpi-clang10@4.1.1  science/openmpi
> openmpi-clang11@4.1.1  science/openmpi
> openmpi-clang33@4.1.1  science/openmpi
> openmpi-clang34@4.1.1  science/openmpi
> openmpi-clang37@4.1.1  science/openmpi
> openmpi-clang50@4.1.1  science/openmpi
> openmpi-clang60@4.1.1  science/openmpi
> openmpi-clang70@4.1.1  science/openmpi
> openmpi-clang80@4.1.1  science/openmpi
> openmpi-clang90@4.1.1  science/openmpi
> openmpi-default@4.1.1  science/openmpi
> openmpi-gcc5   @4.1.1  science/openmpi
> openmpi-gcc6   @4.1.1  science/openmpi
> openmpi-gcc7   @4.1.1  science/openmpi
> openmpi-gcc8   @4.1.1  science/openmpi
> openmpi-gcc9   @4.1.1  science/openmpi
> openmpi-gcc10  @4.1.1  science/openmpi
> openmpi-gcc49  @4.1.1  science/openmpi
> 
> While we hope to continue supporting as many of these as possible for the 
> foreseeable future, removing two of the oldest Clang versions would allow us 
> to provide more focus on the rest.
> 
> Please let us know if you use the clang33 or clang34 variations, or know 
> anyone who does.
> 
> Thanks,
> -Chris


Re: Is it possible to install Julia on M1 Mac?

2021-05-07 Thread Chris Jones
Hi,

Whilst the statement that the devel version of gcc was correct at the time it 
was made, gcc10 now has had support back ported. So I suggest you force 
uninstall libgcc-devel and let libgcc10 get installed in its place.

Chris

> On 7 May 2021, at 12:37 pm, Andrew Rohl  wrote:
> 
> I have installed gcc-devel as I was told that it is the only version that 
> can be compiled on the M1.
> 
> Then tried to install Julia:
> 
>> sudo port install julia  
>>   
>> 
>> --->  Computing dependencies for julia
>> Error: Can't install libgcc10 because conflicting ports are active: 
>> libgcc-devel
>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
>> Error: Processing of port Julia failed
> 
> Is there any way to install Julia?
> 
> Many thanks
> 
>  Andrew



Re: Installing universal binaries on Apple M1 using macports

2021-03-30 Thread Chris Jones
Hi,

Llvm/clang 10 does not work reliably on apple silicon. use llvm/clang 11 
instead.

Chris

> On 30 Mar 2021, at 7:19 am, Sandeep Thakkar 
>  wrote:
> 
> 
> Hi,
> 
> I'm installing llvm-10 on Apple M1 (macOS BigSur) with these changes in 
> macports.conf:
> 
> # custom changes
> buildfromsourcealways
> macosx_deployment_target10.14
> macosx_sdk_version11.1
> 
> and the command I used is:
> % sudo port install llvm-10 +universal
> 
> But, what I see is:
> % otool -l /opt/local/libexec/llvm-10/lib/libLLVM.dylib| grep "minos\|sdk"
> minos 11.0
>   sdk 11.1
> 
> The sdk version looks fine, but why the minos is 11.0? shouldn't it be 10.14 
> as expected? What am I missing?
> 
> -- 
> Sandeep Thakkar
> 
> 


Re: gfortran for M1?

2021-03-20 Thread Chris Jones
Hi,

Gcc-devel provides gfortran for M1 machines by default.

Chris

> On 20 Mar 2021, at 1:01 pm, petr.2...@centrum.cz wrote:
> 
> Is it already possible to install gfortran on M1?
> It seems that gcc-devel does not have +gfortran variant and and other gcc 
> versions are not compatible. 
> Thank you, 
> Petr



Re: OS Platform mismatch - while installing stm32flash

2021-03-11 Thread Chris Jones
Hi,

> On 11 Mar 2021, at 6:16 pm, James Secan  wrote:
> 
> Not sure I understand this.  Do we now need to “migrate” when we update from 
> x.x.y to x.x.y+1?  Has Apple fouled things up that badly?  I thought 
> migration was only needed in a major OS upgrade, which I would consider to be 
> from macOS x to maxOS x+1.

You are correct, for a minor update it is not required.

The issue is the OP must not have followed the migration instructions correctly 
when updating from Darwin19 to Darwin20 (macOS 10.15 to 11.0), as I don’t see 
any other way he could have got those errors messages.

Chris

> 
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
> 
>> On Mar 11, 2021, at 6:44 AM, Chris Jones  wrote:
>> 
>> Hi,
>> 
>> Looks like at some point you did not follow the migration instructions 
>> correctly. You should do so now.
>> 
>> Chris
>> 
>>>> On 11 Mar 2021, at 2:41 pm, Christoph P.U. Kukulies  
>>>> wrote:
>>> 
>>> Of course the error (OS platform mismatch) occurs on every command I'm
>>> running on port,
>>> 
>>> like
>>> 
>>> port info
>>> 
>>>> Am 11.03.2021 um 14:20 schrieb Christoph Kukulies:
>>>> Tried to do
>>>> 
>>>> 
>>>> $ sudo port install stm32flash
>>>> Password:
>>>> Error: Current platform "darwin 20" does not match expected platform 
>>>> "darwin 19"
>>>> Error: If you upgraded your OS, please follow the migration instructions: 
>>>> https://trac.macports.org/wiki/Migration
>>>> OS platform mismatch
>>>>  while executing
>>>> "mportinit ui_options global_options global_variations"
>>>> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform 
>>>> mismatch
>>>> 
>>>> 
>>>> Did an os update from macOS 12.2.2 to 12.2.3 right before.
>>>> 
>>>> 
>>>> —
>>>> Christoph
>>>> 
>>>> 
>>> 
>> 
> 



Re: OS Platform mismatch - while installing stm32flash

2021-03-11 Thread Chris Jones
Hi,

Looks like at some point you did not follow the migration instructions 
correctly. You should do so now.

Chris

> On 11 Mar 2021, at 2:41 pm, Christoph P.U. Kukulies  wrote:
> 
> Of course the error (OS platform mismatch) occurs on every command I'm
> running on port,
> 
> like
> 
> port info
> 
>> Am 11.03.2021 um 14:20 schrieb Christoph Kukulies:
>> Tried to do
>> 
>> 
>> $ sudo port install stm32flash
>> Password:
>> Error: Current platform "darwin 20" does not match expected platform "darwin 
>> 19"
>> Error: If you upgraded your OS, please follow the migration instructions: 
>> https://trac.macports.org/wiki/Migration
>> OS platform mismatch
>>while executing
>> "mportinit ui_options global_options global_variations"
>> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform 
>> mismatch
>> 
>> 
>> Did an os update from macOS 12.2.2 to 12.2.3 right before.
>> 
>> 
>> —
>> Christoph
>> 
>> 
> 



Re: Warning: cltversion again

2021-03-07 Thread Chris Jones
Hi,

> On 7 Mar 2021, at 6:18 pm, Fielding, Eric J (US 329A) via macports-users 
>  wrote:
> 
> 
> I am getting this warning again from running ‘port upgrade outdated’:
>  
> Warning: cltversion: The Command Line Tools are installed, but MacPorts 
> cannot determine the version.
> Warning: cltversion: For a possible fix, please see: 
> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
>  
> I recently opened Xcode and it said it needed to update some tools, so I 
> guess it installed a different version of the Command Line Tools (CLT) in a 
> way that MacPorts can’t determine the version. Is it worth doing the CLT 
> reinstallation described on the Hotlist page or should I just ignore it? It 
> seems that everything is building well despite the warning. I went through 
> the reinstallation procedure a month or two ago.

You should rerun the fixes. The issues sadly reappears on macOS/Xcode updates.

Chris

>  
> I am on Catalina (10.15.7), in case that makes a difference.
>  
> ++Eric


Re: stdlib.h compilation error for macports gcc9.

2021-02-07 Thread Chris Jones
per/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
>>> Thread model: posix
>>> gcc version 9.3.0 (MacPorts gcc9 9.3.0_5) 
>>> COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-c' '-o' 'E2.5.2.o' 
>>> '-mmacosx-version-min=10.15.0' '-asm_macosx_version_min=10.15' 
>>> '-shared-libgcc' '-mtune=core2'
>>>  /opt/local/libexec/gcc/x86_64-apple-darwin19/9.3.0/cc1plus -quiet -v 
>>> -D__DYNAMIC__ E2.5.2.cpp -fPIC -quiet -dumpbase E2.5.2.cpp 
>>> -mmacosx-version-min=10.15.0 -mtune=core2 -auxbase-strip E2.5.2.o 
>>> -std=c++11 -version -o 
>>> /var/folders/yh/ywbbh6_w8xl9_6006s6dywd8gr/T//cc1Ruczn.s
>>> GNU C++11 (MacPorts gcc9 9.3.0_5) version 9.3.0 (x86_64-apple-darwin19)
>>> compiled by GNU C version 9.3.0, GMP version 6.2.1, MPFR version 4.1.0, 
>>> MPC version 1.2.1, isl version isl-0.22.1-GMP
>>> 
>>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/opt/local/include"
>>> ignoring nonexistent directory 
>>> "/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.3.0/../../../../../x86_64-apple-darwin19/include"
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include"
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks"
>>> ignoring nonexistent directory 
>>> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/Library/Frameworks"
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>>  
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
>>>  /usr/local/include
>>>  /opt/local/include
>>>  /usr/local/dart-sdk/include
>>>  /Library/Frameworks/R.framework/Resources/include
>>>  /opt/local/include/gcc9/c++/
>>>  /opt/local/include/gcc9/c++//x86_64-apple-darwin19
>>>  /opt/local/include/gcc9/c++//backward
>>>  /opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.3.0/include
>>>  /opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.3.0/include-fixed
>>> End of search list.
>>> GNU C++11 (MacPorts gcc9 9.3.0_5) version 9.3.0 (x86_64-apple-darwin19)
>>> compiled by GNU C version 9.3.0, GMP version 6.2.1, MPFR version 4.1.0, 
>>> MPC version 1.2.1, isl version isl-0.22.1-GMP
>>> 
>>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>>> Compiler executable checksum: 45101e0fe9cd9377caa0fee122dd387a
>>> In file included from 
>>> /opt/local/include/gcc9/c++/ext/string_conversions.h:41,
>>>  from /opt/local/include/gcc9/c++/bits/basic_string.h:6493,
>>>  from /opt/local/include/gcc9/c++/string:55,
>>>  from /opt/local/include/gcc9/c++/bits/locale_classes.h:40,
>>>  from /opt/local/include/gcc9/c++/bits/ios_base.h:41,
>>>  from /opt/local/include/gcc9/c++/ios:42,
>>>  from /opt/local/include/gcc9/c++/ostream:38,
>>>  from /opt/local/include/gcc9/c++/iostream:39,
>>>  from ../../standard_includes.h:1,
>>>  from E2.5.2.cpp:1:
>>> /opt/local/include/gcc9/c++/cstdlib:75:15: fatal error: stdlib.h: No such 
>>> file or directory
>>>75 | #include_next 
>>>   |   ^~
>>> compilation terminated.
>>> make: *** [../../Makefile-Template:10: E2.5.2.o] Error 1
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>>> On 7 Feb 2021, at 10:24 pm, Carlo Tambuatco  wrote:
>>>>> 
>>>>> Well what's odd is I'm only getting this error after upgrading to the 
>>>>> latest macports gcc9. Indeed when I use the XCode provided clang version 
>>>>> of gcc, it finds all the required libraries. My CPATH environment 
>>>>> variable was sufficient to specify the locations of the libraries before 
>>>>> the upgrade, so the question is, what changed post-upgrade?
>>>>> 
>>>>> On Sun, Feb 7, 2021, 5:03 PM Chris Jones  wrote:
>>>>

Re: stdlib.h compilation error for macports gcc9.

2021-02-07 Thread Chris Jones


It sounds like your builds are not correctly specifying the SDK gcc is to use. 
There are a number of ways you can do this, either by pass it via a compiler 
flag, by running the complication through xcrun, or by setting the SDKROOT 
variables to the required path.

Cheers Chris

> On 7 Feb 2021, at 9:25 pm, Carlo Tambuatco  wrote:
> 
> I don’t know if this is a result of updating to the latest macports gcc9, or 
> the update of XCode, but 
> all of a sudden when I try to build my C++ program which includes  I 
> get this strange 
> chain reaction of errors.
> 
> In file included from /opt/local/include/gcc9/c++/ext/string_conversions.h:41,
> from /opt/local/include/gcc9/c++/bits/basic_string.h:6493,
> from /opt/local/include/gcc9/c++/string:55,
> from /opt/local/include/gcc9/c++/bits/locale_classes.h:40,
> from /opt/local/include/gcc9/c++/bits/ios_base.h:41,
> from /opt/local/include/gcc9/c++/ios:42,
> from /opt/local/include/gcc9/c++/ostream:38,
> from /opt/local/include/gcc9/c++/iostream:39,
> from ../../standard_includes.h:1,
> from E2.5.2.cpp:1:
> /opt/local/include/gcc9/c++/cstdlib:75:15: fatal error: stdlib.h: No such 
> file or directory
>   75 | #include_next 
> 
> 
> From my makefile this seems to be the offending includes statement:
> 
> #include 
> #include 
> 
> 
> I’ve googled and it seems that it can’t find stdlib.h, even though it is on 
> my CPATH environment variable:
> 
> export 
> CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/usr/local/include:/opt/local/include:/usr/local/dart-sdk/include:/Library/Frameworks/R.framework/Resources/include
> 



Re: restore_ports.tcl failure

2020-12-18 Thread Chris Jones

Have you checked to see if the ports you are trying to restore are available 
for arm64 ? Its highly likely that either some are just not available at this 
time, or if they are they might require different variants to that you 
previously used. I am not surprised just blindly running the restore script, in 
this case, might be problematic.

Did you save the list of requested ports, as per the migration instructions ? 
If so I strongly suggest you try looking at this list, and then manually 
installing the ports you still want installed. If you run into problems, check 
trac for specific tickets for whatever issue you run into, and if there are 
none open one for it.

Chris

> On 18 Dec 2020, at 4:26 pm, Murray Eisenberg  
> wrote:
> 
> I’m trying to migrate my ports, originally installed under Catalina 
> (actually, migrated from my iMac running Catalina), to Big Sur 11.1 on an M1 
> MacBook Air. When I got to the step
> 
> sudo ./restore_ports.tcl myports.txt
> 
> I get the following error message:
> 
>   list element in braces followed by "#!/bin/sh" instead of space
>   while executing
>   "foreach op $operationList {
>   set name [string trim [lindex $op 0]]
>  set variations [lindex $op 1]
>   set active [lindex $op 2]
> 
>  ..."
>   (procedure "install_ports" line 2)
>   invoked from within
>   "install_ports $operationList#!/bin/sh”
> (file "./restore_ports.tcl" line 287)
> 
> This is using the default (zsh) shell in Terminal.
> 
> The offending line in the script is:
> 
>   install_ports $operationList#!bin/sh
> 
> What’s wrong?
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> 503 King Farm Blvd #101   
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 


AnRe: latest update to BigSur 11.1 broke gcc

2020-12-16 Thread Chris Jones

I tried it myself, and switching to --with-build-sysroot with gcc10 on big sur 
does seem to build. I haven't had time to run any tests to see exactly what 
this means w.r.t. the default sdk search paths. But in any case I think the 
best advice is anyway to explicitly set it yourself, using one of the numerous 
methods (command line flag, SDKROOT, or use xcrun) in which case whatever the 
default search paths  are does not really make much difference. If we do decide 
to switching to the above then what this means in practise I think is just it 
enforces that users will have to do this, rather than it sometimes working for 
them.

Out of interest what happens with the macports clang ports ? If no default path 
to an sdk is set there, presumably users are also required with these compilers 
to always explicitly give the sdk they wish to use, via similar methods ?

Chris 

> On 16 Dec 2020, at 3:42 pm, Ken Cunningham  
> wrote:
> 
> 
> I'll try it. Things have changed in gcc -- after all, we don't bake any such 
> path into our clang installs, and they don't exhibit this issue.
> 
> K
> 
>> On Dec 16, 2020, at 02:38, Christopher Jones  
>> wrote:
>> 
>> From a combination of my memory, and reading the tickets referenced in the 
>> gcc port file, if we don’t use 
>> —with-sysroot we would need to use --with-build-sysroot in order for the 
>> build to work, and last time that was tried it didn’t work correctly.
>> 
>>> On 16 Dec 2020, at 3:37 am, Ken Cunningham 
>>>  wrote:
>>> 
>>> we might just delete this line from the portfile, perhaps:
>>> 
>>> 
>>>  configure.args-append --with-sysroot="${configure.sdkroot}"
>> 


Re: CLI Tool Problem

2020-12-10 Thread Chris Jones

Have you tried doing what it asks ?

> On 9 Dec 2020, at 11:32 pm, Tom  wrote:
> 
> 
> Hi,
> 
> I get the following Error Message, although Xcode 12 and the CLI Tools are 
> installed:
> 
>>> Warning: The macOS 11.0 SDK does not appear to be installed. Ports may not 
>>> build correctly.
>>> Warning: You can install it as part of the Xcode Command Line Tools package 
>>> by running `xcode-select --install’.
> 
> What could be the Problem?


Re: Command Line Tools for Xcode 11.6

2020-08-01 Thread Chris Jones
Hi,

Either install the newest available, 11.5, or just remove the CLT (its not 
really needed).

https://developer.apple.com/library/archive/technotes/tn2339/_index.html#//apple_ref/doc/uid/DTS40014588-CH1-HOW_CAN_I_UNINSTALL_THE_COMMAND_LINE_TOOLS_

Chris

> On 1 Aug 2020, at 5:59 pm, Murray Eisenberg  wrote:
> 
> When doing MacPorts 2.6.3 upgrades of ports, I’m seeing message:
> 
> Warning: cltversion: The Command Line Tools are installed, but MacPorts 
> cannot determine the version.
> Warning: cltversion: For a possible fix, please see: 
> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
> 
> My Xcode is version 11.6. 
> 
> The fix presented in the link above is to reinstall the Xcode command-line 
> tools.
> 
> However, developer.apple.com lists NO command-line tools for Xcode 11.6!
> 
> What to do?
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 


Re: Building emacs-27 from source with AppKit, X windows, Gtk+ toolkit support...?

2020-06-03 Thread Chris Jones



> On 3 Jun 2020, at 9:10 pm, Ryan Schmidt  wrote:
> 
> 
> 
>> On Jun 3, 2020, at 05:38, Carlo Tambuatco wrote:
>> 
>> I’m attempting to build emacs-27 from source and I would like to have AppKit 
>> support for running natively on macOS and Gtk3 support.
>> 
>> These are the gtk3 libraries I’ve got installed:
>> 
>> gtk-osx-application-common-gtk3 @2.0.8_0 (active)
>> gtk-osx-application-gtk3 @2.0.8_0 (active)
>> gtk3 @3.24.20_0+quartz (active)
>> gwenhywfar4-gtk3 @4.20.2_0 (active)
>> 
>> This is the warning I got during the configure step of compilation: 
>> 
>> checking for X... no
>> checking AppKit/AppKit.h usability... no
>> checking AppKit/AppKit.h presence... yes
>> configure: WARNING: AppKit/AppKit.h: present but cannot be compiled
>> configure: WARNING: AppKit/AppKit.h: check for missing prerequisite 
>> headers?
>> configure: WARNING: AppKit/AppKit.h: see the Autoconf documentation
>> configure: WARNING: AppKit/AppKit.h: section "Present But Cannot Be 
>> Compiled"
>> configure: WARNING: AppKit/AppKit.h: proceeding with the compiler's result
>> configure: WARNING: ##  ##
>> configure: WARNING: ## Report this to bug-gnu-em...@gnu.org ##
>> configure: WARNING: ##  ##
>> checking for AppKit/AppKit.h... no
>> configure: error: The include files (AppKit/AppKit.h etc) that
>> are required for a Nextstep build are missing or cannot be compiled.
>> Either fix this, or re-configure with the option '--without-ns’.
> 
> The config.log file is where I would look to understand why this is happening.
> 
> 
>> And configure says I do not have X installed:
>> 
>> checking for X… no
>> 
>> I also have ImageMagick installed, so I would like to link to that during 
>> the build also.
> 
> Any reason why you don't want to use the emacs or emacs-devel ports that are 
> already in MacPorts? They do have an +imagemagick variant you can use.

Also note there is the emacs-app port that builds a native gui version. Sounds 
like exactly what is being asked for...

Chris

> 
> 
>> So, I would like to know if there are extra devel libraries I need from 
>> macports and if I already have the relevant 
>> libraries, how do I link to them when building emacs-27…?
> 
> Just to make sure we're on the same page about terminology, if you're 
> referring to the -devel packages offered in some Linux package management 
> systems, which provide headers and other files needed to build something 
> against a library whereas the actual library files would be in a non-devel 
> package, MacPorts doesn't do it that way. In MacPorts, the headers, libraries 
> and binaries will all be together in a single port.
> 
> We do have some -devel ports, as I mentioned emacs-devel above, but they have 
> a different purpose in MacPorts: The -devel port will offer a (usually more 
> recent) development version of the software while the non-devel port will 
> offer a stable version of the software.
> 
> AppKit, being a part of macOS, won't be in a port; it'll just be there in the 
> OS.
> 



Re: Python 3.8.2 - Macports configuration problem

2020-04-28 Thread Chris Jones


> On 29 Apr 2020, at 1:45 am, Max Anglad  wrote:
> 
> I forgot to say that after Macports python38 installation, following the 
> notes, I made :
> 
>> sudo port select --set python3 python38
> Selecting 'python38' for 'python3' succeeded. 'python38' is now active.
> 
> But however I think the PATH must be changed...

Remove

/Library/Frameworks/Python.framework/Versions/3.8/bin

From your PATH. That is not a version of python installed by macports, but is 
something else you must have installed at some point.

Chris

> 
> 


Re: ncurses 6.2 failing with reinplace warnings

2020-03-15 Thread Chris Jones


> On 15 Mar 2020, at 11:26 pm, Richard DeLaurell  
> wrote:
> 
> 
> Hello,
> 
> I am trying to update from ncurses 6.1 to 6.2, but am getting the warnings 
> noted in ticket #60152; however, unlike the ticket report there my 
> installation does not complete.
> 
> The failure log reports: install error CHILDSTATUS 43121 2
> 
> What could be the problem?

The ticket above is unlikely to be related to your problem. Its hard to tell 
and Without more information no one is going to be able to help. Please open a 
new ticket in trac, and be sure to attach a complete log file showing the 
failure.

Chris

> 
> Thanks for any wisdom.
> 


Re: When os10 versions are skipped

2020-03-03 Thread Chris Jones


> On 3 Mar 2020, at 6:20 pm, dan d.  wrote:
> 
> 
> Hello,
> 
> I may in the near future install a newer os10 which skips some versions.
> 
> How short of uninstalling the current macports can this be done?

You cannot. With Any major OS upgrade you must follow the migration 
instructions, otherwise you are likely to run into problems later on.

https://trac.macports.org/wiki/Migration

Chris


> -- 
> Thanks for any help.
> XB


Re: Why does llvm depend on python 2.7?

2020-02-05 Thread Chris Jones

Hi,

Seeing as I already have the changes...

https://github.com/macports/macports-ports/pull/6309

Ken - Use as you see fit. Please note though, as I have tried to 
explain, this does not actually in practice change how the build is 
done. On all systems clang-X is configured just as it was before, with 
or without MacPorts python being used. The MR really just removes the 
python27 dep. when it is not actually used.


Chris

On 05/02/2020 2:40 pm, Chris Jones wrote:

Hi,

Just to try and be clear. The current inconsistency in the port files is 
the fact the clang-X builds are configured to *always* depend on python27


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L54> 



whereas the clang-X builds is only figured to use this python version 
for darwin < 11


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L367> 



what needs to change is for the port dependency to only be applied when 
it is actually needed (i.e. used by the build)


Whether that is only for darwin < 11, as seems to be the current 
intention, or for all OSes, is really a separate question.


Chris

On 05/02/2020 2:33 pm, Chris Jones wrote:

Hi,

On 05/02/2020 2:18 pm, Ken Cunningham wrote:

doing that doesn't really take us in the right directiion, though chris.

reproducible builds and all that.

we go from a fully spec'd proper python 


Actually no. That is not what happens at the moment. Check the 
clang-9.0 config on darwin 11+ for yourself. The macports python 
version is currently *not* used at all. The lines


    configure.args-append \
 -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/python${py_ver}

which configure the clang-X build to use the macports python (2.7) are 
*only* used on darwin < 11. On everything else the defaults are used, 
which means the cmake build finds and uses /usr/bin/python.


to a randomly-found one, in a setting where afaik python 3 is known 
not to work.


We are already, for the clang-X builds (note I am specifically *not* 
talking about llvm-X or lldb-X here) relying on whatever the build 
systems decides to used based on its default configuration, for darwin 
 >= 11.


Now, if you want to *always* spec. the clang-X builds to use *always* 
use macports provided python 2.7, that is indeed an option. But that 
also requires some fixes in the port file w.r.t. what is currently 
done. i.e. remove the darwin  < 11 check at


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L367> 



so the configuration above is applied to *all* OSes, not just darwin < 
11.




and I am not sure at present how to even test all the lldb etc 
integration they mention.


the changes I am proposing do not touch the lldb-X builds. They 
already fully spec. the builds to use macports python, on all OSes.


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L317> 



Chris



stripping the python spec is trivial, I could do it in 5 minutes, but 
it doesn't sound like what we should do here...


?

K



Re: Why does llvm depend on python 2.7?

2020-02-05 Thread Chris Jones

Hi,

Just to try and be clear. The current inconsistency in the port files is 
the fact the clang-X builds are configured to *always* depend on python27


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L54>

whereas the clang-X builds is only figured to use this python version 
for darwin < 11


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L367>

what needs to change is for the port dependency to only be applied when 
it is actually needed (i.e. used by the build)


Whether that is only for darwin < 11, as seems to be the current 
intention, or for all OSes, is really a separate question.


Chris

On 05/02/2020 2:33 pm, Chris Jones wrote:

Hi,

On 05/02/2020 2:18 pm, Ken Cunningham wrote:

doing that doesn't really take us in the right directiion, though chris.

reproducible builds and all that.

we go from a fully spec'd proper python 


Actually no. That is not what happens at the moment. Check the clang-9.0 
config on darwin 11+ for yourself. The macports python version is 
currently *not* used at all. The lines


    configure.args-append \
     -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/python${py_ver}

which configure the clang-X build to use the macports python (2.7) are 
*only* used on darwin < 11. On everything else the defaults are used, 
which means the cmake build finds and uses /usr/bin/python.


to a randomly-found one, in a setting where afaik python 3 is known not 
to work.


We are already, for the clang-X builds (note I am specifically *not* 
talking about llvm-X or lldb-X here) relying on whatever the build 
systems decides to used based on its default configuration, for darwin 
 >= 11.


Now, if you want to *always* spec. the clang-X builds to use *always* 
use macports provided python 2.7, that is indeed an option. But that 
also requires some fixes in the port file w.r.t. what is currently done. 
i.e. remove the darwin  < 11 check at


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L367> 



so the configuration above is applied to *all* OSes, not just darwin < 11.



and I am not sure at present how to even test all the lldb etc 
integration they mention.


the changes I am proposing do not touch the lldb-X builds. They already 
fully spec. the builds to use macports python, on all OSes.


<https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/Portfile#L317> 



Chris



stripping the python spec is trivial, I could do it in 5 minutes, but 
it doesn't sound like what we should do here...


?

K



Re: Why does llvm depend on python 2.7?

2020-02-05 Thread Chris Jones

Hi,

On 05/02/2020 2:18 pm, Ken Cunningham wrote:

doing that doesn't really take us in the right directiion, though chris.

reproducible builds and all that.

we go from a fully spec'd proper python 


Actually no. That is not what happens at the moment. Check the clang-9.0 
config on darwin 11+ for yourself. The macports python version is 
currently *not* used at all. The lines


   configure.args-append \
-DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/python${py_ver}

which configure the clang-X build to use the macports python (2.7) are 
*only* used on darwin < 11. On everything else the defaults are used, 
which means the cmake build finds and uses /usr/bin/python.


to a randomly-found one, in a setting where afaik python 3 is known not 
to work.


We are already, for the clang-X builds (note I am specifically *not* 
talking about llvm-X or lldb-X here) relying on whatever the build 
systems decides to used based on its default configuration, for darwin 
>= 11.


Now, if you want to *always* spec. the clang-X builds to use *always* 
use macports provided python 2.7, that is indeed an option. But that 
also requires some fixes in the port file w.r.t. what is currently done. 
i.e. remove the darwin  < 11 check at




so the configuration above is applied to *all* OSes, not just darwin < 11.



and I am not sure at present how to even test all the lldb etc integration they 
mention.


the changes I am proposing do not touch the lldb-X builds. They already 
fully spec. the builds to use macports python, on all OSes.




Chris



stripping the python spec is trivial, I could do it in 5 minutes, but it 
doesn't sound like what we should do here...

?

K



Re: Why does llvm depend on python 2.7?

2020-02-05 Thread Chris Jones

Hi,

Indeed thanks, I had found my way to that link already ;)

I think has far as Macports goes, we can fix this by just removing the 
python dep. entirely for darwin >= 11. Its only needed on the older OSes 
where the system python is not new enough. I have the changes to do this 
almost ready, just running a few tests, so PRs will follow shortly.


Chris

On 05/02/2020 1:43 pm, Ken Cunningham wrote:

Re llvm using python3 instead of python2.7, please see the following chain:

http://lists.llvm.org/pipermail/llvm-dev/2018-January/120826.html

Looks like it has to stay python2.7 until they wholesale switch the 
project at some point.


Best,

Ken


Re: Why does qt5-qttools depends on clang 9?

2020-02-05 Thread Chris Jones

Hi,

Quickly looking into things it looks like the python dep clang has is 
largely redundant. Its needed only on OSes where the system version is 
'too old' which means darwin < 11. Most systems can (and in fact if you 
check the build config, do) use the system python anyway.


So I think the python dep. can be removed for the majority of (not 
ancient) systems.


cheers Chris

On 05/02/2020 11:07 am, Chris Jones wrote:


Another question is why does clang depend explicitly on python 2.7, can 
it not be updated to a newer 3.x version ?


On 05/02/2020 7:34 am, Vincent Habchi wrote:

Hi there,

everything is in the subject. Is there any reason for this dependency? 
I’m trying to get rid of python 2.7, and the only dependent port left 
so far is clang 9.0, which is needed by qt5-qttools, but I can’t 
figure out why.


Thanks a bunch,
Vincent



Re: Why does qt5-qttools depends on clang 9?

2020-02-05 Thread Chris Jones




On 05/02/2020 7:34 am, Vincent Habchi wrote:

Hi there,

everything is in the subject. Is there any reason for this dependency? I’m 
trying to get rid of python 2.7, and the only dependent port left so far is 
clang 9.0, which is needed by qt5-qttools, but I can’t figure out why.


Isn't the answer to this on line 1491 in the Portfile ?




Re: Why does qt5-qttools depends on clang 9?

2020-02-05 Thread Chris Jones



Another question is why does clang depend explicitly on python 2.7, can 
it not be updated to a newer 3.x version ?


On 05/02/2020 7:34 am, Vincent Habchi wrote:

Hi there,

everything is in the subject. Is there any reason for this dependency? I’m 
trying to get rid of python 2.7, and the only dependent port left so far is 
clang 9.0, which is needed by qt5-qttools, but I can’t figure out why.

Thanks a bunch,
Vincent



Re: ports directory (from git fork) up to date, still a warning

2020-01-29 Thread Chris Jones



OK. Done that. What does the error mean? I am in a local git branch at 
the moment (not in master), is that the problem?


Yes. Just do what it says, define the remote branch to use. e.g.

git branch --set-upstream-to=origin/master minio-20200128



bash-3.2# port -v sync
--->  Updating the ports tree
Synchronizing local ports tree from 
file:///Users/sysbh/MacPortsDev/macports-ports

There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-pull(1) for details.

     git pull  

If you wish to set tracking information for this branch you can do so with:

     git branch --set-upstream-to=/ minio-20200128

Command failed: /usr/bin/git pull --rebase --autostash
Exit code: 1
Syncing local Git ports tree failed
Synchronizing local ports tree from 
rsync://rsync.macports.org/macports/release/tarballs/ports.tar


Willkommen auf dem RSYNC-server auf ftp.fau.de .
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de .
Not all of our mirrors are available through rsync.


receiving file list ... done
./

sent 68 bytes  received 99 bytes  334.00 bytes/sec
total size is 70808576  speedup is 424003.45
Creating port index in 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports 



Total number of ports parsed:0
Ports successfully parsed:0
Ports failed:0
Up-to-date ports skipped:22892

port sync failed: Synchronization of 1 source failed



Re: Migrating from Sierra on one box to High Sierra on another

2020-01-21 Thread Chris Jones



As with any OS upgrade, follow the instructions at

https://trac.macports.org/wiki/Migration

On 21/01/2020 1:28 am, Dave Horsfall wrote:

I don't have web access right now, hence the list...

My ancient Sierra MacBook failed (graphics board which is no longer 
available) but I have been offered a more recent second-hand one for a 
reasonable price, and it will run High Sierra (I don't want Mojave just 
yet).


What's the procedure to update all the existing ports i.e. is there such 
a thing as "port upgrade all" to do "the right thing"?  I have the old 
system drive available (external USB - long story) and can slurp the 
appropriate files over (I don't like restoring using Time Machine, and 
the Capsule may not be up to date anyway, as I was working when the 
video disappeared).


I know that I have to recompile my own stuff.

Anything else that I should know about?  I like to be forewarned, and 
remember that I don't have web access right now.


Thanks.

-- Dave


Re: upgrade to osx 10.15 catalina

2020-01-09 Thread Chris Jones

Hi,

I would say the situation with 10.15 is now similar to other OSes. Some 
things work, some things do not. There are also some clear cases of 
things not working, and cannot/willnot be fixed, such as 32 bit support.


At the end of the day though only you know which ports you really care 
about, and cannot live without, so you need to do your homework 
yourself. Identified those ports and then check their status at


https://ports.macports.org/

Finally, as with any major OS update, I strongly recommend making a full 
bootable clone of your current system, before doing anything. Then, if 
worst comes to work, reverting back is trivial. I recommend this for any 
OS update, not at all specific to MacPorts...


Chris

On 09/01/2020 1:50 pm, joerg van den hoff wrote:
I had to upgrade to 10.15 (wanted to postpone this further but ...) and 
recall that there were many reports over the last months of problems 
with subsequent macports upgrade, recommendations to use previous xcode 
releases with catalina and assorted package specific problems simply not 
being solvable right now.


I have looked at the mail archive and macports webpage but have not 
found a clear recommendation or statement what the current situation (as 
of jan 2020) is.


so simple question: is it save/recommended to use current xcode (11.3) 
when doing the usual macports migration routine? are there guaranteed 
problems in certain packages/areas? or is everything back

to normal (most things will work, some might not...)?

thank you


Re: problem migrating to catalina

2019-11-28 Thread Chris Jones



> On 28 Nov 2019, at 3:39 pm, Comer Duncan  wrote:
> 
> I've migrated to catalina and  am having problem with building pango.
> I've attached an edited version of the main.log, as the whole file was
> deemed too big.  Please take a look and let me know what you think.
> Thanks very much!

You could have just compressed the log with bzip2 etc...

> 
> Comer Duncan
> 



Re: help with installing xorg-server from MacPorts and installing Inkscape

2019-11-27 Thread Chris Jones


> On 27 Nov 2019, at 5:02 pm, yiming roberts-lo  wrote:
> 
> 
> Okay, I ran sudo port install xorg-server in a terminal. Now it's telling me: 
> To use MacPorts' X11 as the default server, install xorg-server, log out,
> and log back in.
> 
> 
> I'm assuming I should setup X11 as the default server?

Yes, just do exactly what it says...

> 
> Thanks!
> 
>> On Wed, Nov 27, 2019 at 4:55 AM Chris Jones  wrote:
>> Hi,
>> 
>> So what exactly have you run ?
>> 
>> Please run
>> 
>> sudo port install xorg-server
>> 
>> in a terminal, and if you still have problems post *exactly* what the 
>> above gives.
>> 
>> Chris
>> 
>> On 27/11/2019 4:09 am, yiming roberts-lo wrote:
>> > Hello,
>> > I'm trying to figure out how to install Inkscape. I tried to follow the 
>> > instructions, but I am really confused. I think that I installed XCode, 
>> > agreed to the  Xcode license in Terminal, and Install MacPorts for my 
>> > version of the Mac OS (macOS Mojave v10.14). On this page 
>> > <https://www.macports.org/install.php#requirements> it says that there's 
>> > an optional step: "The X11 windowing environment for ports that depend 
>> > on the functionality it provides to run. You have multiple choices for 
>> > an X11 server". I tried to install the xorg-server port from MacPorts 
>> > (recommended), however I couldn't figure out how to do this? I got to 
>> > this page <https://ports.macports.org/port/xorg-server/summary> but 
>> > there's no Download or Install button?
>> > 
>> > How do I install X11 and then ultimately install Inkscape? I just want 
>> > to edit a vector and this is all very confusing.
>> > 
>> > Thanks in advance for your help.
>> > 
>> > yiming
>> > 
>> > 


Re: help with installing xorg-server from MacPorts and installing Inkscape

2019-11-27 Thread Chris Jones

Hi,

So what exactly have you run ?

Please run

sudo port install xorg-server

in a terminal, and if you still have problems post *exactly* what the 
above gives.


Chris

On 27/11/2019 4:09 am, yiming roberts-lo wrote:

Hello,
I'm trying to figure out how to install Inkscape. I tried to follow the 
instructions, but I am really confused. I think that I installed XCode, 
agreed to the  Xcode license in Terminal, and Install MacPorts for my 
version of the Mac OS (macOS Mojave v10.14). On this page 
 it says that there's 
an optional step: "The X11 windowing environment for ports that depend 
on the functionality it provides to run. You have multiple choices for 
an X11 server". I tried to install the xorg-server port from MacPorts 
(recommended), however I couldn't figure out how to do this? I got to 
this page  but 
there's no Download or Install button?


How do I install X11 and then ultimately install Inkscape? I just want 
to edit a vector and this is all very confusing.


Thanks in advance for your help.

yiming




Re: XCode 11 on Mojave problem, again

2019-11-09 Thread Chris Jones



> On 9 Nov 2019, at 1:50 pm, Henning Hraban Ramm  wrote:
> 
> Hi,
> I also had problems on Mojave, since at least cctools was expecting a 
> MacOSX10.14.sdk in 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs;
>  on Mojave there’s only the 10.15 SDK.
> I had XCode 10.something and updated yesterday to 11.latest; that needed some 
> hours...
> 
> Since I didn’t find a way to install a 10.14 SDK, I just made a symlink to 
> the 10.15 SDK under the name of MacOSX10.14.sdk, and it works so far!

That is a bad idea, pretending a 10.15 SDK is a 10.14 one could lead to 
unforeseen side effects. So this is not something we recommend anyone does.

Have you tried installing the CLT ? That should provide a 10.14 SDK that the 
latest MacPorts release will use. 

> All the ports that didn’t compile previously, like cctools, ImageMagick, 
> Inkscape (maybe unrelated) and MariaDB10.* ran through.
> 
> Greetlings, Hraban
> 
> BTW: Hello Mojca! ;)
> 
>> Am 2019-11-09 um 10:39 schrieb Ruben Di Battista :
>> 
>> Ehi Mojca,
>> 
>> Thanks for the message. :)
>> 
>> I managed to fix it. I got confused because recently I updated Xcode, but in 
>> facts the problem was completely unrelated: I had a project header file 
>> named “math.h”. :) Very noob mistake! Interestingly enough, this bug does 
>> not pop-out on Linux (using GCC).
>> 
>> So I just renamed “math.h” to a custom name, and now everything is back as 
>> before (Ah, pay attention! Most of macOS systems have a case-insensitive 
>> filesystem… I firstly renamed the file from “math.h” -> “Math.h”, but it 
>> didn’t work either and it took a while to realize that on macOS “math.h” and 
>> “Math.h” are the same if the FS is case-insensitive.
> 



Re: mysql57, boost and postgresql84

2019-11-08 Thread Chris Jones



> On 9 Nov 2019, at 1:39 am, Ryan Schmidt  wrote:
> 
> 
> 
>> On Nov 8, 2019, at 16:06, Michael Newman wrote:
>> 
>>> On Nov 7, 2019, at 06:34, Ryan Schmidt wrote:
>>> 
>>> If `port installed requested` shows things that you don't actually want, 
>>> tell MacPorts by marking them as not requested:
>>> 
>>> sudo port unsetrequested portname1 portname2 ...
>>> 
>>> Then `sudo port reclaim` will be able to uninstall them, if they're not 
>>> needed for anything else you've installed. Reclaim won't uninstall things 
>>> it thinks you want.
>> 
>> This set a little trap for me. For some reason, clamav, which I did request, 
>> was not shown as requested. So, when I ran reclaim, it was removed. I was 
>> puzzled at first when freshclam started to fail. I’ve reinstalled clamav now 
>> and all is well. Is there some reason why clamav would not be flagged as 
>> requested?
> 
> MacPorts' ability to automatically uninstall ports you don't want and keep 
> the ports you do want is only as good as the metadata recorded in the 
> registry. If it's wrong, you have to fix it.
> 
> If you ran `sudo port install clamav`, and it was not already installed, 
> MacPorts should have marked it as requested. If clamav was automatically 
> installed as a dependency of something else, then it would not have been 
> marked requested.

That sounds like something we should fix to me. Is it not reasonable to expect 
the port in this case, even if it was previously installed as a dependency, to 
still be marked as requested in this case, as that is what the user did by 
asking for it to be installed. The fact it already was shouldn’t matter in 
terms of marking it as requested ?

Chris 

> 
> You can also look through the list of allegedly unrequested ports:
> 
> port installed unrequested
> 
> If you actually do want any of the ports listed, mark them as requested:
> 
> sudo port setrequested portname1 portname2 ...
> 
> 



Re: mysql57, boost and postgresql84

2019-11-06 Thread Chris Jones

Hi,

On 06/11/2019 8:34 am, Michael Newman via macports-users wrote:

I have no idea why I have postgreSQL:

MrMuscle:~ mnewman$ sudo port dependents postgresql84
postgresql84-server depends on postgresql84
MrMuscle:~ mnewman$ sudo port dependents postgresql84-server
postgresql84-server has no dependents.

I didn’t request it. I don’t use it.

When I list requested ports, there are always several that I don’t 
recognize, such as:


boost, gcc7, mysql57-server,  and nss.

But, there they are.


Then try and uninstall them, if you don't think you need them. If there 
are there because something else depends on them, port will let you 
know. Its worth doing a bit of spring cleaning every now and then, as 
keeping stuff installed you do not need just wastes your time upgrading it.


You could also try rerunning

> sudo port reclaim

which does a number of tasks aimed at removing stuff you do not need.

Chris


Re: failure to get gcc9 running

2019-11-05 Thread Chris Jones



On 05/11/2019 12:28 pm, Hans Goedbloed wrote:


Hi Peter, Ryan and Chris

Thanks for your help.

Reply to Chris Jones:
-- I am not sure that I removed all ports, how can I find out?
-- How do I create an empty vanilla MacPorts installation?
By 'port -u uninstall'?


To Ryan Schmidt:
-- (1) Attached is "1a. output of upgrade" and "1b. plist". I can not make 
anything of it.


You mis-typed the command... Its

> sudo port -d rev-upgrade

not

> sudo port -d rev -upgrade

i.e. rev-upgrade is one word.

I have no idea what the plist file you sent is for ?


-- (2) I see some perl file dating from 2010 in /opt/local/bin (see attached "2. old perl 
files").How to update "libpreludedb's +perl variant"?


> sudo port sync
> sudo port upgrade outdated


-- (3) Attached is the list of the "3. old local portfiles". In fact, they date from 
2014, but they also have a copy labeled ".default". Should I just delete all of them?


That is not what Ryan asked for. He asked if you had configured your 
local installation to use a custom local Portfiles. i.e. have you 
*changed* /opt/local/etc/macports/sources.conf ??



( At this point though, given all the problems you have its going to be 
very hard I would say for anyway to understand what you have, and have 
not done to your system, as part of the upgrade process, so probably the 
simplest approach is to wipe out the macports installation and start 
afresh. Just my view, others might disagree. )


Chris


Re: failure to get gcc9 running

2019-11-05 Thread Chris Jones

Hi,

On 05/11/2019 12:28 pm, Hans Goedbloed wrote:


Hi Peter, Ryan and Chris

Thanks for your help.

Reply to Chris Jones:
-- I am not sure that I removed all ports, how can I find out?
-- How do I create an empty vanilla MacPorts installation?
By 'port -u uninstall'?


Follow

<https://guide.macports.org/chunked/installing.macports.uninstalling.html>

Once you have done that, just follow the usual instructions to install 
MacPorts from scratch.



I am inclined to just start afresh, but I am very interested in all of your 
suggestions, since I have another iMac to go (from 2014), that has been 
upgraded to macOS 10.14 with the old port files on it (I never upgraded ports 
since all was working fine, until the recent upgrde to 10.14).


Whenever you upgrade your OS it is *mandatory* that you follow the 
migration guide


<https://trac.macports.org/wiki/Migration>

Not following that, precisely (which yes means uninstalling all ports 
and reinstalling them once upgraded), is a very good way to end up with 
the troubles you are having here.


Another bit of advice - *never* updating your ports after you install 
them is also not at all recommended, as it is also a good way to end up 
with troubles as when you do the updates are a lot bigger and more 
problematic the longer the time period since the last update. I 
recommend periodically running


> sudo port sync
> sudo port upgrade outdated

and

> sudo port selfupdate

to keep your ports in good health.

Chris



Thanks in advance,
Hans





From: Ryan Schmidt 
Sent: Monday, November 4, 2019 7:49 PM
To: Hans Goedbloed
Cc: MacPorts Users
Subject: Re: failure to get gcc9 running

On Nov 4, 2019, at 10:12, Hans Goedbloed wrote:
​

[/Users/hansgoedbloed]$sudo port install gcc9
Password:
---> Computing dependencies for gcc9
---> Cleaning gcc9


First things first: this shows that gcc9 was already successfully installed 
before you ran this command.



---> Updating database of binaries
---> Scanning binaries for linking errors
---> Found 9 broken files, matching files to ports
---> Found 4 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
  cmake @3.15.5
  readline @8.0.000
  gdbm @1.18.1
  llvm-8.0 @8.0.1
Continue? [Y/n]: y



After any port install or upgrade, MacPorts checks all installed ports for linking 
errors. It found some on your system. We would need to see the output of "sudo port 
-d rev-upgrade" to know specifically what problems were found with those ports.



Warning: No port perl5.8 found in the index.


perl5.8 was removed a long time ago. The current version is perl5.30. Nothing 
in MacPorts should be referencing perl5.8 anymore. (I found one port that was; 
I filed a ticket: https://trac.macports.org/ticket/59600)

Do you perhaps have any local Portfiles (check your 
/opt/local/etc/macports/sources.conf file) that might be very old and out of 
date?



Warning: The macOS 10.14 SDK does not appear to be installed. Ports may not 
build correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by 
running `xcode-select --install'.


I see below that you did run this command. Good.



---> Computing dependencies for cmake
---> Fetching distfiles for cmake
---> Attempting to fetch cmake-3.15.5.tar.gz from 
https://distfiles.macports.org/cmake
---> Verifying checksums for cmake
---> Extracting cmake
---> Applying patches to cmake
---> Configuring cmake
---> Building cmake
---> Staging cmake into destroot
---> Deactivating cmake @3.15.5_0
---> Cleaning cmake
---> Uninstalling cmake @3.15.5_0
---> Cleaning cmake
Warning: The macOS 10.14 SDK does not appear to be installed. Ports may not 
build correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by 
running `xcode-select --install'.
---> Computing dependencies for cmake
---> Installing cmake @3.15.5_0
---> Activating cmake @3.15.5_0
---> Cleaning cmake
Warning: The macOS 10.14 SDK does not appear to be installed. Ports may not 
build correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by 
running `xcode-select --install'.
---> Computing dependencies for readline
---> Fetching distfiles for readline
---> Attempting to fetch readline-8.0.tar.gz from 
https://distfiles.macports.org/readline
---> Verifying checksums for readline
---> Extracting readline
---> Applying patches to readline
---> Configuring readline
---> Building readline
---> Staging readline into destroot
---> Unable to uninstall readline @8.0.000_0, the following ports depend on it:
--->   gdbm @1.18.1_1
Warning: Uninstall forced.  Proceeding despite dependencies.
---> Deactivating readline @8.0.000_0
---> Cleaning readline
---> Uninstalling readline @8.0.000_0
---> Cl

Re: Freecad ports ends in error

2019-10-28 Thread Chris Jones

Hi,

Please follow the procedure at

 https://guide.macports.org/#project.tickets

first see if there is an open bug report, and if there is contribute to 
that. Otherwise, open a new one.


cheers Chris

On 28/10/2019 10:51 am, Christoph Kukulies wrote:
I was trying to build FreeCAD under macports and at the end I’m getting 
this:


--->  Verifying checksums for freecad
--->  Extracting freecad
--->  Applying patches to freecad
--->  Configuring freecad
Error: Failed to configure freecad: configure failure: command execution 
failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_cad_freecad/freecad/main.log 
for details.

Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port freecad failed
--->  Some of the ports you installed have notes:
   OpenBLAS has the following notes:
     This version is built based on a base architecture for convenience,
     which may not be optimized for your system. To build a version
     customized for your machine, use the +native variant
   eigen3 has the following notes:
     This product includes software developed by the University of 
Chicago, as

     Operator of Argonne National Laboratory.
   py27-cython has the following notes:
     To make the Python 2.7 version of Cython the one that is run when you
     execute the commands without a version suffix, e.g. 'cython', run:


     port select --set cython cython27
   py27-matplotlib has the following notes:
     The default backend is the interactive Mac OS X backend. Different 
backends
     can be specified using the ~/.matplotlib/matplotlibrc file. More 
details

     regarding backends can be found in the matplotlib FAQ:




The main.log contains:

:info:configure -- Looking for pthread.h
:info:configure -- Looking for pthread.h - found
:info:configure -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
:info:configure -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
:info:configure -- Found Threads: TRUE
:info:configure CMake Error at 
/opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
(message):
:info:configure   Could NOT find Boost (missing: signals) (found version 
"1.71.0")

:info:configure Call Stack (most recent call first):
:info:configure   
/opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
:info:configure   
/opt/local/share/cmake-3.15/Modules/FindBoost.cmake:2161 
(find_package_handle_standard_args)

:info:configure   CMakeLists.txt:596 (find_package)
:info:configure -- Configuring incomplete, errors occurred!
:info:configure See also 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_cad_freecad/freecad/work/build/CMakeFiles/CMakeOutput.log".
:info:configure See also "/opt/local/var/macports/bui:info:configure -- 
Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success

:info:configure -- Found Threads: TRUE
:info:configure CMake Error at 
/opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
(message):
:info:configure   Could NOT find Boost (missing: signals) (found version 
"1.71.0")

:info:configure Call Stack (most recent call first):
:info:configure   
/opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
:info:configure   
/opt/local/share/cmake-3.15/Modules/FindBoost.cmake:2161 
(find_package_handle_standard_args)

:info:configure   CMakeLists.txt:596 (find_package)
:info:configure -- Configuring incomplete, 
errold/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_cad_freecad/freecad/work/build/CMakeFiles/CMakeError.log".



Is there a way to fix this or ny comments?

—
Christoph



Re: executing gcc9 on macOS 10.14

2019-10-23 Thread Chris Jones



No problem, always glad to help someone use MacPorts !

On 23/10/2019 10:38 am, Hans Goedbloed wrote:

Thanks!, I now know what to expect and how to fix it.
Hans

From: macports-users  on behalf of Chris 
Jones 
Sent: Wednesday, October 23, 2019 11:30 AM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

On 23/10/2019 10:23 am, Hans Goedbloed wrote:

The xcrun did work, I do have turn around now!
Thanks for the help, Chris.

I do have macOs 10.14.4 with Xcode 11.0 installed though, Should I change Xcode 
right now or can I wait for the next SDK issue to turn up?


That is up to you. It is just it is known that using Xcode 11 on macOS
10.14 does lead to these sort of SDK issues. They are being ironed out,
slowly, but if you want to just avoid them its best to still to Xcode 10
on 10.14..



Hans


From: macports-users  on behalf of Chris 
Jones 
Sent: Wednesday, October 23, 2019 10:46 AM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

Another idea.

What Xcode version are you running on mac OS 10.14 ?

If Xcode 11, this is not recommended as it does lead to a lot of SDK
related issues, due to the fact Xcode 11 only has the 10.15 SDK (yes,
even on macOS 10.14).

It is recommended to use Xcode 10 on macOS 10.14.

Chris

On 23/10/2019 9:37 am, Hans Goedbloed wrote:

I updated the ports. looked allright (reply was "nothing to upgrade"), but the 
same problem:
"ld: library not found for -lSystem"

I also checked for the ld64 port and the reply was:
"The following ports are currently installed:
ld64 @3_1+ld64_xcode (active)"

Any other suggestions?

Hans

From: macports-users  on behalf of Chris 
Jones 
Sent: Wednesday, October 23, 2019 10:27 AM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

Hi,

One other comment. What version of the ld64 port do you have installed ?
If it is not using the xcode variant, then please reinstall in using that

 > port installed ld64
The following ports are currently installed:
  ld64 @3_1+ld64_xcode (active)

if you do not get the above, run

> sudo port -f uninstall ld64
> sudo port install ld64

Chris

On 23/10/2019 9:21 am, Chris Jones wrote:

Hi,

( Please always reply to the list )

The error below looks like one we addressed recently. Have you updated
your ports ? Please run

> sudo port sync
> sudo port upgrade outdated

then try again.

Chris


On 23/10/2019 9:17 am, Hans Goedbloed wrote:

Thanks Chris,

Looks like what I hoped for: no other tools than gcc9 needed.
However, when I do precisely what you said, I still get

hanss-imac:resabs hansgoedbloed$ gfortran-mp-9 -o test.exe ./test.f
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

All the libraries listed from your otool command are there, except
/usr/lib/libSystem.B.dylib.
Could that be the problem?

Hans

________
From: macports-users  on
behalf of Chris Jones 
Sent: Tuesday, October 22, 2019 7:09 PM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

Hi,

Your ld command is incomplete. You aren't passing any of the runtime
libraries needed to link the .o file into an executable.

The simplest approach is to let gcc do the full job.

Titan ~/Documents/Code > cat test.f
   program hello
   print *, "Hello World!"
   end program hello
Titan ~/Documents/Code > gfortran-mp-9 -o test.exe ./test.f
Titan ~/Documents/Code > ./test.exe
  Hello World!

Titan ~/Documents/Code > otool -L ./test.exe
./test.exe:
/opt/local/lib/libgcc/libgfortran.5.dylib (compatibility
version 6.0.0,
current version 6.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.200.5)
/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version
1.0.0,
current version 1.0.0)
/opt/local/lib/libgcc/libquadmath.0.dylib (compatibility
version 1.0.0,
current version 1.0.0)

Chris

On 22/10/2019 5:41 pm, Hans Goedbloed wrote:

I have been using g95 for my fortran codes for many years, but it did
not work anymore after upgrading to macOS 10.14 Mojave. I was advised to
install gccc9 from MacPorts instead. This I did through "sudo port
selfupdate" and "sudo port install gcc9".

This appeared to give all the required tools. When I then tried to
compile and execute the simplest fortran  program test.f (the usual just
writing of the message "Hello") by first compiling

/opt/local/bin/gfortran-mp-9 -v -c test.f

giving the required object file test.o, and then loading:

/opt/local/bin/ld -v test.o

this resulted in the messages

@(#)PROGRAM:ld PROJECT:ld64-512.4

BUILD 05:06:53 Aug 16 2019

configured to support archs: armv6 ar

Re: executing gcc9 on macOS 10.14

2019-10-23 Thread Chris Jones

Another idea.

What Xcode version are you running on mac OS 10.14 ?

If Xcode 11, this is not recommended as it does lead to a lot of SDK 
related issues, due to the fact Xcode 11 only has the 10.15 SDK (yes, 
even on macOS 10.14).


It is recommended to use Xcode 10 on macOS 10.14.

Chris

On 23/10/2019 9:37 am, Hans Goedbloed wrote:

I updated the ports. looked allright (reply was "nothing to upgrade"), but the 
same problem:
"ld: library not found for -lSystem"

I also checked for the ld64 port and the reply was:
"The following ports are currently installed:
ld64 @3_1+ld64_xcode (active)"

Any other suggestions?

Hans

From: macports-users  on behalf of Chris 
Jones 
Sent: Wednesday, October 23, 2019 10:27 AM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

Hi,

One other comment. What version of the ld64 port do you have installed ?
If it is not using the xcode variant, then please reinstall in using that

   > port installed ld64
The following ports are currently installed:
ld64 @3_1+ld64_xcode (active)

if you do not get the above, run

  > sudo port -f uninstall ld64
  > sudo port install ld64

Chris

On 23/10/2019 9:21 am, Chris Jones wrote:

Hi,

( Please always reply to the list )

The error below looks like one we addressed recently. Have you updated
your ports ? Please run

  > sudo port sync
  > sudo port upgrade outdated

then try again.

Chris


On 23/10/2019 9:17 am, Hans Goedbloed wrote:

Thanks Chris,

Looks like what I hoped for: no other tools than gcc9 needed.
However, when I do precisely what you said, I still get

hanss-imac:resabs hansgoedbloed$ gfortran-mp-9 -o test.exe ./test.f
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

All the libraries listed from your otool command are there, except
/usr/lib/libSystem.B.dylib.
Could that be the problem?

Hans

________
From: macports-users  on
behalf of Chris Jones 
Sent: Tuesday, October 22, 2019 7:09 PM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

Hi,

Your ld command is incomplete. You aren't passing any of the runtime
libraries needed to link the .o file into an executable.

The simplest approach is to let gcc do the full job.

Titan ~/Documents/Code > cat test.f
 program hello
 print *, "Hello World!"
 end program hello
Titan ~/Documents/Code > gfortran-mp-9 -o test.exe ./test.f
Titan ~/Documents/Code > ./test.exe
Hello World!

Titan ~/Documents/Code > otool -L ./test.exe
./test.exe:
  /opt/local/lib/libgcc/libgfortran.5.dylib (compatibility
version 6.0.0,
current version 6.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.200.5)
  /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version
1.0.0,
current version 1.0.0)
  /opt/local/lib/libgcc/libquadmath.0.dylib (compatibility
version 1.0.0,
current version 1.0.0)

Chris

On 22/10/2019 5:41 pm, Hans Goedbloed wrote:

I have been using g95 for my fortran codes for many years, but it did
not work anymore after upgrading to macOS 10.14 Mojave. I was advised to
install gccc9 from MacPorts instead. This I did through "sudo port
selfupdate" and "sudo port install gcc9".

This appeared to give all the required tools. When I then tried to
compile and execute the simplest fortran  program test.f (the usual just
writing of the message "Hello") by first compiling

/opt/local/bin/gfortran-mp-9 -v -c test.f

giving the required object file test.o, and then loading:

/opt/local/bin/ld -v test.o

this resulted in the messages

@(#)PROGRAM:ld PROJECT:ld64-512.4

BUILD 05:06:53 Aug 16 2019

configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:

 /usr/lib

Framework search paths:

 /Library/Frameworks/

 /System/Library/Frameworks/

Undefined symbols for architecture x86_64:

"__gfortran_set_args", referenced from:

 _main in test.o

"__gfortran_set_options", referenced from:

 _main in test.o

"__gfortran_st_write", referenced from:

 _MAIN__ in test.o

"__gfortran_st_write_done", referenced from:

 _MAIN__ in test.o

ld: symbol(s) not found for architecture x86_64

I thought installation of gcc9 would include everything. How should I
fix this?​


Hans


>


Re: executing gcc9 on macOS 10.14

2019-10-23 Thread Chris Jones

Hi,

I forgot one detail from the recent fix to gcc to enable it to find 
system libraries.


What the fix did was add a patch to allow gcc9 to find the SDK in the 
same way as clang. This means either you use xcrun to run the command, 
or set the XDKROOT variable. See


<https://github.com/macports/macports-ports/commit/1850136d289019f3b29a5b24d3ec8ef9b23913ee#diff-bf5951877cf7f70968394fcc87aa5721>

https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00251.html

for more info.

So. You need to either run gcc through xcrun, i.e.

 > xcrun gfortran-mp-9 -o test.exe ./test.f

or (as I use) set

export SDKROOT=`xcrun --show-sdk-path`

I actually had set the above in my shell profile, so I always have it, 
which is why gfortran worked for me 'out the box' (and thus I forgot it 
was there, which was my original intention)


Chris

On 22/10/2019 6:09 pm, Chris Jones wrote:

Hi,

Your ld command is incomplete. You aren't passing any of the runtime 
libraries needed to link the .o file into an executable.


The simplest approach is to let gcc do the full job.

Titan ~/Documents/Code > cat test.f
   program hello
   print *, "Hello World!"
   end program hello
Titan ~/Documents/Code > gfortran-mp-9 -o test.exe ./test.f
Titan ~/Documents/Code > ./test.exe
  Hello World!

Titan ~/Documents/Code > otool -L ./test.exe
./test.exe:
 /opt/local/lib/libgcc/libgfortran.5.dylib (compatibility version 
6.0.0, current version 6.0.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1252.200.5)
 /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 
1.0.0, current version 1.0.0)
 /opt/local/lib/libgcc/libquadmath.0.dylib (compatibility version 
1.0.0, current version 1.0.0)


Chris

On 22/10/2019 5:41 pm, Hans Goedbloed wrote:
I have been using g95 for my fortran codes for many years, but it did 
not work anymore after upgrading to macOS 10.14 Mojave. I was advised 
to install gccc9 from MacPorts instead. This I did through "sudo port 
selfupdate" and "sudo port install gcc9".


This appeared to give all the required tools. When I then tried to 
compile and execute the simplest fortran  program test.f (the usual 
just writing of the message "Hello") by first compiling


/opt/local/bin/gfortran-mp-9 -v -c test.f

giving the required object file test.o, and then loading:

/opt/local/bin/ld -v test.o

this resulted in the messages

@(#)PROGRAM:ld PROJECT:ld64-512.4

BUILD 05:06:53 Aug 16 2019

configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em


Library search paths:

   /usr/lib

Framework search paths:

   /Library/Frameworks/

   /System/Library/Frameworks/

Undefined symbols for architecture x86_64:

  "__gfortran_set_args", referenced from:

   _main in test.o

  "__gfortran_set_options", referenced from:

   _main in test.o

  "__gfortran_st_write", referenced from:

   _MAIN__ in test.o

  "__gfortran_st_write_done", referenced from:

   _MAIN__ in test.o

ld: symbol(s) not found for architecture x86_64

I thought installation of gcc9 would include everything. How should I 
fix this?​



Hans




Re: executing gcc9 on macOS 10.14

2019-10-23 Thread Chris Jones

Hi,

One other comment. What version of the ld64 port do you have installed ? 
If it is not using the xcode variant, then please reinstall in using that


 > port installed ld64
The following ports are currently installed:
  ld64 @3_1+ld64_xcode (active)

if you do not get the above, run

> sudo port -f uninstall ld64
> sudo port install ld64

Chris

On 23/10/2019 9:21 am, Chris Jones wrote:

Hi,

( Please always reply to the list )

The error below looks like one we addressed recently. Have you updated 
your ports ? Please run


 > sudo port sync
 > sudo port upgrade outdated

then try again.

Chris


On 23/10/2019 9:17 am, Hans Goedbloed wrote:

Thanks Chris,

Looks like what I hoped for: no other tools than gcc9 needed.
However, when I do precisely what you said, I still get

hanss-imac:resabs hansgoedbloed$ gfortran-mp-9 -o test.exe ./test.f
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

All the libraries listed from your otool command are there, except 
/usr/lib/libSystem.B.dylib.

Could that be the problem?

Hans


From: macports-users  on 
behalf of Chris Jones 

Sent: Tuesday, October 22, 2019 7:09 PM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

Hi,

Your ld command is incomplete. You aren't passing any of the runtime
libraries needed to link the .o file into an executable.

The simplest approach is to let gcc do the full job.

Titan ~/Documents/Code > cat test.f
    program hello
    print *, "Hello World!"
    end program hello
Titan ~/Documents/Code > gfortran-mp-9 -o test.exe ./test.f
Titan ~/Documents/Code > ./test.exe
   Hello World!

Titan ~/Documents/Code > otool -L ./test.exe
./test.exe:
 /opt/local/lib/libgcc/libgfortran.5.dylib (compatibility 
version 6.0.0,

current version 6.0.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.200.5)
 /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 
1.0.0,

current version 1.0.0)
 /opt/local/lib/libgcc/libquadmath.0.dylib (compatibility 
version 1.0.0,

current version 1.0.0)

Chris

On 22/10/2019 5:41 pm, Hans Goedbloed wrote:

I have been using g95 for my fortran codes for many years, but it did
not work anymore after upgrading to macOS 10.14 Mojave. I was advised to
install gccc9 from MacPorts instead. This I did through "sudo port
selfupdate" and "sudo port install gcc9".

This appeared to give all the required tools. When I then tried to
compile and execute the simplest fortran  program test.f (the usual just
writing of the message "Hello") by first compiling

/opt/local/bin/gfortran-mp-9 -v -c test.f

giving the required object file test.o, and then loading:

/opt/local/bin/ld -v test.o

this resulted in the messages

@(#)PROGRAM:ld PROJECT:ld64-512.4

BUILD 05:06:53 Aug 16 2019

configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:

    /usr/lib

Framework search paths:

    /Library/Frameworks/

    /System/Library/Frameworks/

Undefined symbols for architecture x86_64:

   "__gfortran_set_args", referenced from:

    _main in test.o

   "__gfortran_set_options", referenced from:

    _main in test.o

   "__gfortran_st_write", referenced from:

    _MAIN__ in test.o

   "__gfortran_st_write_done", referenced from:

    _MAIN__ in test.o

ld: symbol(s) not found for architecture x86_64

I thought installation of gcc9 would include everything. How should I
fix this?​


Hans




Re: executing gcc9 on macOS 10.14

2019-10-23 Thread Chris Jones

Hi,

( Please always reply to the list )

The error below looks like one we addressed recently. Have you updated 
your ports ? Please run


> sudo port sync
> sudo port upgrade outdated

then try again.

Chris


On 23/10/2019 9:17 am, Hans Goedbloed wrote:

Thanks Chris,

Looks like what I hoped for: no other tools than gcc9 needed.
However, when I do precisely what you said, I still get

hanss-imac:resabs hansgoedbloed$ gfortran-mp-9 -o test.exe ./test.f
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

All the libraries listed from your otool command are there, except 
/usr/lib/libSystem.B.dylib.
Could that be the problem?

Hans


From: macports-users  on behalf of Chris 
Jones 
Sent: Tuesday, October 22, 2019 7:09 PM
To: macports-users@lists.macports.org
Subject: Re: executing gcc9 on macOS 10.14

Hi,

Your ld command is incomplete. You aren't passing any of the runtime
libraries needed to link the .o file into an executable.

The simplest approach is to let gcc do the full job.

Titan ~/Documents/Code > cat test.f
program hello
print *, "Hello World!"
end program hello
Titan ~/Documents/Code > gfortran-mp-9 -o test.exe ./test.f
Titan ~/Documents/Code > ./test.exe
   Hello World!

Titan ~/Documents/Code > otool -L ./test.exe
./test.exe:
 /opt/local/lib/libgcc/libgfortran.5.dylib (compatibility version 6.0.0,
current version 6.0.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.200.5)
 /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
 /opt/local/lib/libgcc/libquadmath.0.dylib (compatibility version 1.0.0,
current version 1.0.0)

Chris

On 22/10/2019 5:41 pm, Hans Goedbloed wrote:

I have been using g95 for my fortran codes for many years, but it did
not work anymore after upgrading to macOS 10.14 Mojave. I was advised to
install gccc9 from MacPorts instead. This I did through "sudo port
selfupdate" and "sudo port install gcc9".

This appeared to give all the required tools. When I then tried to
compile and execute the simplest fortran  program test.f (the usual just
writing of the message "Hello") by first compiling

/opt/local/bin/gfortran-mp-9 -v -c test.f

giving the required object file test.o, and then loading:

/opt/local/bin/ld -v test.o

this resulted in the messages

@(#)PROGRAM:ld PROJECT:ld64-512.4

BUILD 05:06:53 Aug 16 2019

configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:

/usr/lib

Framework search paths:

/Library/Frameworks/

/System/Library/Frameworks/

Undefined symbols for architecture x86_64:

   "__gfortran_set_args", referenced from:

_main in test.o

   "__gfortran_set_options", referenced from:

_main in test.o

   "__gfortran_st_write", referenced from:

_MAIN__ in test.o

   "__gfortran_st_write_done", referenced from:

_MAIN__ in test.o

ld: symbol(s) not found for architecture x86_64

I thought installation of gcc9 would include everything. How should I
fix this?​


Hans




Re: executing gcc9 on macOS 10.14

2019-10-22 Thread Chris Jones

Hi,

Your ld command is incomplete. You aren't passing any of the runtime 
libraries needed to link the .o file into an executable.


The simplest approach is to let gcc do the full job.

Titan ~/Documents/Code > cat test.f
  program hello
  print *, "Hello World!"
  end program hello
Titan ~/Documents/Code > gfortran-mp-9 -o test.exe ./test.f
Titan ~/Documents/Code > ./test.exe
 Hello World!

Titan ~/Documents/Code > otool -L ./test.exe
./test.exe:
	/opt/local/lib/libgcc/libgfortran.5.dylib (compatibility version 6.0.0, 
current version 6.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1252.200.5)
	/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)
	/opt/local/lib/libgcc/libquadmath.0.dylib (compatibility version 1.0.0, 
current version 1.0.0)


Chris

On 22/10/2019 5:41 pm, Hans Goedbloed wrote:
I have been using g95 for my fortran codes for many years, but it did 
not work anymore after upgrading to macOS 10.14 Mojave. I was advised to 
install gccc9 from MacPorts instead. This I did through "sudo port 
selfupdate" and "sudo port install gcc9".


This appeared to give all the required tools. When I then tried to 
compile and execute the simplest fortran  program test.f (the usual just 
writing of the message "Hello") by first compiling


/opt/local/bin/gfortran-mp-9 -v -c test.f

giving the required object file test.o, and then loading:

/opt/local/bin/ld -v test.o

this resulted in the messages

@(#)PROGRAM:ld PROJECT:ld64-512.4

BUILD 05:06:53 Aug 16 2019

configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em


Library search paths:

   /usr/lib

Framework search paths:

   /Library/Frameworks/

   /System/Library/Frameworks/

Undefined symbols for architecture x86_64:

  "__gfortran_set_args", referenced from:

   _main in test.o

  "__gfortran_set_options", referenced from:

   _main in test.o

  "__gfortran_st_write", referenced from:

   _MAIN__ in test.o

  "__gfortran_st_write_done", referenced from:

   _MAIN__ in test.o

ld: symbol(s) not found for architecture x86_64

I thought installation of gcc9 would include everything. How should I 
fix this?​



Hans




Re: mpv, ffmpeg seg fault in macOS catalina

2019-10-18 Thread Chris Jones


> On 18 Oct 2019, at 11:30 pm, Michael Newman via macports-users 
>  wrote:
> 
> I’m sorry, but I don’t understand most of what was written in this thread, 
> but I do have a simple question:
> 
> If I upgrade to Catalina (I already have Xcode 11.1) and install MacPorts for 
> Catalina will ffmpeg stop working?

As long as you follow the migration guide correctly, no.

https://trac.macports.org/wiki/Migration

> 
>> On Oct 18, 2019, at 19:00, Gill Bates  wrote:
>> 
>> I recently updated to catalina (10.15) and Xcode (11.1), installed MacPorts 
>> from source (2.6.1) and had it build mpv and its dependencies. However, mpv 
>> (and ffmpeg for example) do not run
> 


Re: mpv, ffmpeg seg fault in macOS catalina

2019-10-18 Thread Chris Jones

Hi,

Workaround is to either blacklist the compiler which has this option 
turned on by default (which is what Chris replied) or in fact use a flag 
to disable this. But disabling this flag is not needed for non-broken 
compilers, so it's probably better to just blacklist the compiler, and 
the latest compiler with be automatically used again when the bug gets 
fixed.


Currently I black list {clang > 1099}, so anything in current and future 
Xcode 11 versions. The (insider) claim was Xcode 11.2 'should' address 
this, but last I heard 11.2 beta 2 still had the problem, so time will tell.


Once the fixed clang version is known, the above blacklists can then be 
adjusted to make them non-open ended, but we need to know the fixed 
version first...


Chris



Re: llvm versions on 10.5 3.9->8.0

2019-10-18 Thread Chris Jones

Hi,

On 18/10/2019 7:00 am, Riccardo Mottola via macports-users wrote:

Hi,

when running upgrade of llvm 3.9, I get this message:

$ sudo port -v upgrade llvm-3.9
--->  llvm-3.9 is replaced by llvm-8.0

is this correct? I think that for now the different clang versions would 
"stay" and so corresponging also llvm.


Yes, that is correct. See last commit at



llvm and clang 3.9 are obsolete and replaced.

I have clang and llvm 5.0 on 10.5 on Leopard which is I think the latest 
I can get.



another port (cfitsio) pulls in llvm 9.0 and I tried to compile that and 
it fails. I did not try 8.0 to be honest.


build failures, with complete logs, should be reported at

https://trac.macports.org/wiki/Tickets

Chris


Re: libSystem not found using gfortran

2019-10-16 Thread Chris Jones




--->  Building libgcc9
Error: Failed to build libgcc9: command execution failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/libgcc9/main.log 
for details.

Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port gcc9 failed

5. The log file is 170Mb large, so I did "cat main.log | grep -i error > 
error.log" and attach the error.log


Sorry, but I cannot tell much from that truncated log file.

Please follow the instructions to create a ticket at

ttps://guide.macports.org/#project.tickets

please also always upload complete log files from clean build attempts. 
Note, if the log is large it invariably compresses nicely with bzip2 etc. ;)


Chris


Re: Xorg-server problems

2019-10-15 Thread Chris Jones
Hi,

So, first things first.

Have you followed the instructions to log out then in again ? This is required 
to get xorg-server working.

Then, please remove your custom xinitrc etc. and confirm a default 
configuration works as expected. I usually use something like xclock for this, 
to check the server auto starts as it should

> sudo port install xclock
> xclock&

Does that work ok ?

Chris

P.s. in future please do not hijack threads to start a new discussion on a 
different issue.

> On 16 Oct 2019, at 1:04 am, Andrew Hartung via macports-users 
>  wrote:
> 
> I can not get X11 to work correctly. 
> 
> Mac OS 10.14.6
> 
> Clicking X11.app causes it to loop in a cycle of starting for a few seconds, 
> quitting and repeat. I have to restart to get it to stop.
> 
> startx :
> 
> ~ $ startx
> font_cache: Scanning user font directories to generate X11 font caches
> font_cache: Updating FC cache
> font_cache: Done
> 
> xinit: XFree86_VT property unexpectedly has 0 items instead of 1
> xinit: connection to X server lost
> 
> waiting for X server to shut down
> 
> 
> If I try and launch a program for the command line it just hangs and X11 
> appears to never launch. I’m running two monitors if that matters at all.
> 
> my .xinitrc:
> # make the freedesktop menu entries work
> export XDG_DATA_DIRS=/opt/local/share
> export XDG_DATA_HOME=/opt/local/share
> export XDG_CONFIG_DIRS=/opt/local/etc/xdg
> 
> # enable sound
> export ESPEAKER=localhost
> 
> # use Apple's window manager
> exec quartz-wm &
> 
> ~ $ echo $PATH
> /opt/local/libexec/gnubin/:/opt/local/bin:/opt/local/sbin:/opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/opt/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands



Re: libSystem not found using gfortran

2019-10-15 Thread Chris Jones


> On 15 Oct 2019, at 8:43 am, Guillaume Houzeaux @ BSC 
>  wrote:
> 
> 
> Chris,
> 
> there is no way I can update to xcode11.1 (I always get an error from apple 
> store at the end: could not be installed).

Thats very fishy definitely you should be able to update to 11.1, and its 
very much recommended as I know of a few issues present in 11.0 fixed in 
11.1 If i where you I would investigate this further.

> Anyway, I repeated the whole process from the macports migration page and now 
> compiler works well. For sure I missed
> something during the first installation.

Ok, glad it now works ok. But still, sounds like something is not quite right 
given the Xcode problems  you have...

Chris
> 
> Thanks again,
> 
> Guillaume
>> 
>> yes, as it only has the 10.15 SDK, different to the 10.14 one Xcode 10 has, 
>> which the buildbots use. 
>> 
>>> On 11/10/2019 2:56 pm, Richard L. Hamilton wrote: 
>>> Is Xcode 11.1 still a bad idea on Mojave? 
>>> 
>>>> On Oct 11, 2019, at 09:40, Chris Jones  wrote: 
>>>> 
>>>> 
>>>>> This is what I did supposingly but with xcode11.0... but anyway, I will 
>>>>> try again with the new xcode. 
>>>>> I will maintain you informed... it happened to other people in the office 
>>>>> so if I solve this many people will be happy ;o) 
>>>> 
>>>> Once Xcode is updated to 11.1 please also run 
>>>> 
>>>> xcode-select --install 
>>>> 
>>>> to make sure the CLT's are updated as well. 
>>>> 
>>>> Then, you should check that 
>>>> 
>>>> xcrun --show-sdk-path 
>>>> 
>>>> gives a valid 10.15 SDK path. 
>>>> 
>>>> Chris 
>>>> 
>>> 
> 
> -- 
> Guillaume Houzeaux
> Team Leader
> Dpt. Computer Applications in Science and Engineering
> Barcelona Supercomputing Center (BSC-CNS)
> Edificio NEXUS II - Office 3A, c) Jordi Girona 29
> 08034 Barcelona, Spain
> 
> Location:
> 
> 
> Tel: +34 93 413 7781
> Skype user: guillaume_houzeaux_bsc
> WWW: BSC profile 
> ResearcherID: D-4950-2012 
> Scientific Profile:
> 
> 
> 
> 
> 
> 
> 


Re: alternative for g95 on macOS Mojave

2019-10-14 Thread Chris Jones




On 14/10/2019 4:02 pm, Chris Jones wrote:



On 14/10/2019 3:54 pm, Hans Goedbloed wrote:
I have been using g95 for many years on my iMac to perform fortran 77 
calculations, but upgrading to macOS10.14 (Mojave) I found that


“building g95 is not supported with Xcode 9 or greater”.

Which package should I use instead?​


gfotran, as provided by one of the gcc ports. gcc9 is the most recent 
release.


gfotran -> gfortran


Re: alternative for g95 on macOS Mojave

2019-10-14 Thread Chris Jones




On 14/10/2019 3:54 pm, Hans Goedbloed wrote:
I have been using g95 for many years on my iMac to perform fortran 77 
calculations, but upgrading to macOS10.14 (Mojave) I found that


“building g95 is not supported with Xcode 9 or greater”.

Which package should I use instead?​


gfotran, as provided by one of the gcc ports. gcc9 is the most recent 
release.


Re: Xfce4 Won't Launch in macOS Catalina

2019-10-12 Thread Chris Jones
Hi,

I am not sure you have provided enough information for anyone to really be able 
to help.

Most likely some command that previously worked is now failing to run, and you 
need to first figure out what that is. Are there any crash reports, in Console, 
that might help ? Have you checked to see if its any of the specific possible 
causes mentioned in those pop ups ?

Cheers Chris

>> On 13 Oct 2019, at 1:39 am, Emily Jackson  wrote:
> I recently upgraded from Mojave to Catalina and redid my MacPorts 
> installation. I used Xfce4 as a WM under Mojave, but now I can’t get it to 
> launch while running Catalina. I have attached screen shots of the errors I 
> get. I can use quartz-wm with X11, but I would like to get Xfce4 working.
> 
> Thanks,
> 
> Emily
> 
> 



Re: MacPorts activation relating to bsdtar

2019-10-12 Thread Chris Jones



> On 12 Oct 2019, at 3:26 am, Ryan Schmidt  wrote:
> 
> 
> 
>> On Oct 11, 2019, at 10:49, Steven Esser wrote:
>> 
>> On a fresh Catalina (10.15) install with Xcode 11.1 and the latest CLI tools 
>> I cannot seem to activate any ports. Most seem to configure and build 
>> correctly, but fail when they reach the activation step. Attached is the log 
>> for an attempted installation of ncurses that has this activation step 
>> failure and occurs no matter what the port. 
>> 
>> From the log itself, it looks like bsdtar is the culprit? Bsdtar fails with 
>> this command "Command failed: /usr/bin/bzip2 -d -c 
>> /Users/sesser/MacPorts/var/macports/software/ncurses/ncurses-6.1_0.darwin_19.x86_64.tbz2
>>  | ( bsdtar -xvp --hfsCompression -f - )”
>> 
>> This is the bsdtar found at /usr/bin/bsdtar.
>> 
>> Wanted to post this here to make sure there wasn’t a quick fix etc for this 
>> before I file a formal bug.
>> 
>> 
> 
> Does the bsdtar command seem to work when you do things with it manually on 
> the command line?
> 
> The log shows you have installed MacPorts into a custom prefix 
> /Users/sesser/MacPorts. Any particular reason? It's recommended to use the 
> standard /opt/local prefix so that you can benefit from our binaries, once 
> they become available.

Also, it appears like you are using an area in your own user home area. I am 
not sure this is a good idea either, as macports needs to be able to control 
permissions on this area, and we have seen cases before where directories 
directly in the user home area have issues in this regard. I personally would 
recommend placing the installation elsewhere, and agree with Ryan using the 
default location is by far the best option.

Chris
> 
> The log shows that hfsCompression is being used. Up to Mojave, Apple's bsdtar 
> didn't support hfsCompression. I haven't checked Catalina yet so it's 
> possible that they've finally added it. But is it perhaps possible that you 
> have a different bsdtar somewhere else on your system that MacPorts is using, 
> and that other bsdtar isn't working?
> 



Re: Xcode 11 on Mojave

2019-10-12 Thread Chris Jones



> On 12 Oct 2019, at 3:28 am, Ryan Schmidt  wrote:
> 
> On Oct 11, 2019, at 09:57, Joshua Root wrote:
> 
>> Xcode itself only contains a 10.15 SDK, but the Command Line Tools have
>> a 10.14 one. You should be mostly fine with them installed, though there
>> are some exceptions. Our installation instructions have always said to
>> install both Xcode and the CLTs.
> 
> But the CLT has the SDK in a different path than Xcode does, of course. And 
> if Xcode-based SDK paths got baked into various ports on our Xcode-10-using 
> Mojave build worker, then that will be a problem for any users that have 
> Xcode 11, whether or not they have the CLT.

Does the 10.14 buildbot have the CLT installed ? If not, maybe adding it would 
help ?
> 



Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones



yes, as it only has the 10.15 SDK, different to the 10.14 one Xcode 10 
has, which the buildbots use.


On 11/10/2019 2:56 pm, Richard L. Hamilton wrote:

Is Xcode 11.1 still a bad idea on Mojave?


On Oct 11, 2019, at 09:40, Chris Jones  wrote:



This is what I did supposingly but with xcode11.0... but anyway, I will try 
again with the new xcode.
I will maintain you informed... it happened to other people in the office so if 
I solve this many people will be happy ;o)


Once Xcode is updated to 11.1 please also run

xcode-select --install

to make sure the CLT's are updated as well.

Then, you should check that

xcrun --show-sdk-path

gives a valid 10.15 SDK path.

Chris





Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones





This is what I did supposingly but with xcode11.0... but anyway, I will 
try again with the new xcode.


I will maintain you informed... it happened to other people in the 
office so if I solve this many people will be happy ;o)


Once Xcode is updated to 11.1 please also run

xcode-select --install

to make sure the CLT's are updated as well.

Then, you should check that

xcrun --show-sdk-path

gives a valid 10.15 SDK path.

Chris


Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones




On 11/10/2019 2:30 pm, Guillaume Houzeaux @ BSC wrote:

Ok Chris,

I'm installing xcode 11.1 from the app store. Should I go through the 
migration steps again afterwards?


yes. See my previous mail I just sent. All your ports need to be 
uninstalled, then rebuilt from source natively for Darwin19.


Chris



Guillaume



On 11/10/2019 2:22 pm, Guillaume Houzeaux @ BSC wrote:

Chris,



On 11/10/2019 1:41 pm, Guillaume Houzeaux @ BSC wrote:

Chris, thanks a lot for your very quick answer!

1. I followed the path for migration and reinstalled all packages. 
I will try to do it once more to be sure.

2. Xcode version: 11.0


Please update to 11.1. 11.0 indeed has a number of issues since fixed.


I get no updates available :o(


I think I saw the same. try a search for Xcode in the App store and 
update from there




I will try from developer.apple.com



Reading specs from 
/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../libgfortran.spec

rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' 
'-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/ 

LIBRARY_PATH=/usr/lib/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../ 

COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' 
'-shared-libgcc' '-mtune=core2'
  /opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/collect2 
-syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 
-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o 
-lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc 
-lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v

collect2 version 9.2.0
/opt/local/bin/ld -syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 




This I think is your problem. You are using the 10.14 SDK, not the 
10.15 one. Does


/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk 



even exist on your system ? I guess not.

nope, it does not exist


Chris

-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o 
-lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc 
-lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v

@(#)PROGRAM:ld  PROJECT:ld64-512.4
BUILD 05:06:53 Aug 16 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e 
arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:
 /opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0
 /opt/local/lib/gcc9
Framework search paths:
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status




one more request.

please post the full output from compiling your test code with the 
-v option.


cheers Chris

On 11/10/2019 12:59 pm, Chris Jones wrote:


can you please direct us to the exact test application code you 
are using ?


Also, can you confirm the exact Xcode version you are using ?

Have you correctly followed the macports migration guide after 
updating your OS ?


https://trac.macports.org/wiki/Migration

cheers Chris

On 11/10/2019 12:55 pm, Guillaume Houzeaux @ BSC wrote:

Hello,

I'm compiling with gfortran9 on catalina and get this error:

gfortran test.f90
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

Seems that it does not find the library libSystem. I changed all 
the library paths in my bash_profile


to include /usr/lib but does not work. The only solution for the 
moment is to compile with


gfortran test.f90-L/usr/lib

but this is not a practical option... Any idea on how to fix this?

Thanks in advance

--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.1154135?hl=en> 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile <https://www.bsc.es/houzeaux-guillaume>
ResearcherID: D-4950-2012
Scientific Profile: 
<https://www.researchgate.net/profile/Guillaume_H

Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones
'-shared-libgcc' 
'-mtune=core2'

COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/
LIBRARY_PATH=/usr/lib/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' '-shared-libgcc' 
'-mtune=core2'
  /opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/collect2 
-syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 
-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o -lgfortran 
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm 
-lgcc_ext.10.5 -lgcc -lSystem -v

collect2 version 9.2.0
/opt/local/bin/ld -syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 
-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o -lgfortran 
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm 
-lgcc_ext.10.5 -lgcc -lSystem -v

@(#)PROGRAM:ld  PROJECT:ld64-512.4
BUILD 05:06:53 Aug 16 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:
     /opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0
     /opt/local/lib/gcc9
Framework search paths:
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status




one more request.

please post the full output from compiling your test code with the -v 
option.


cheers Chris

On 11/10/2019 12:59 pm, Chris Jones wrote:


can you please direct us to the exact test application code you are 
using ?


Also, can you confirm the exact Xcode version you are using ?

Have you correctly followed the macports migration guide after 
updating your OS ?


https://trac.macports.org/wiki/Migration

cheers Chris

On 11/10/2019 12:55 pm, Guillaume Houzeaux @ BSC wrote:

Hello,

I'm compiling with gfortran9 on catalina and get this error:

gfortran test.f90
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

Seems that it does not find the library libSystem. I changed all the 
library paths in my bash_profile


to include /usr/lib but does not work. The only solution for the 
moment is to compile with


gfortran test.f90-L/usr/lib

but this is not a practical option... Any idea on how to fix this?

Thanks in advance

--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.1154135?hl=en> 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile <https://www.bsc.es/houzeaux-guillaume>
ResearcherID: D-4950-2012
Scientific Profile: 
<https://www.researchgate.net/profile/Guillaume_Houzeaux> 
<http://scholar.google.es/citations?user=cL9khdYJ=en> 
<http://orcid.org/-0002-2592-1426> 
<http://www.researcherid.com/rid/D-4950-2012>




--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.1154135?hl=en> 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile <https://www.bsc.es/houzeaux-guillaume>
ResearcherID: D-4950-2012
Scientific Profile: 
<https://www.researchgate.net/profile/Guillaume_Houzeaux> 
<http://scholar.google.es/citations?user=cL9khdYJ=en> 
<http://orcid.org/-0002-2592-1426> 
<http://www.researcherid.com/rid/D-4950-2012>




Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones




On 11/10/2019 2:22 pm, Guillaume Houzeaux @ BSC wrote:

Chris,



On 11/10/2019 1:41 pm, Guillaume Houzeaux @ BSC wrote:

Chris, thanks a lot for your very quick answer!

1. I followed the path for migration and reinstalled all packages. I 
will try to do it once more to be sure.

2. Xcode version: 11.0


Please update to 11.1. 11.0 indeed has a number of issues since fixed.


I get no updates available :o(


I think I saw the same. try a search for Xcode in the App store and 
update from there




I will try from developer.apple.com



Reading specs from 
/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../libgfortran.spec

rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' 
'-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/ 

LIBRARY_PATH=/usr/lib/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../ 

COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' 
'-shared-libgcc' '-mtune=core2'
  /opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/collect2 
-syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 
-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o 
-lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc 
-lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v

collect2 version 9.2.0
/opt/local/bin/ld -syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 



This I think is your problem. You are using the 10.14 SDK, not the 
10.15 one. Does


/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk 



even exist on your system ? I guess not.

nope, it does not exist


Chris

-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o 
-lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc 
-lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v

@(#)PROGRAM:ld  PROJECT:ld64-512.4
BUILD 05:06:53 Aug 16 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:
 /opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0
 /opt/local/lib/gcc9
Framework search paths:
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status




one more request.

please post the full output from compiling your test code with the 
-v option.


cheers Chris

On 11/10/2019 12:59 pm, Chris Jones wrote:


can you please direct us to the exact test application code you are 
using ?


Also, can you confirm the exact Xcode version you are using ?

Have you correctly followed the macports migration guide after 
updating your OS ?


https://trac.macports.org/wiki/Migration

cheers Chris

On 11/10/2019 12:55 pm, Guillaume Houzeaux @ BSC wrote:

Hello,

I'm compiling with gfortran9 on catalina and get this error:

gfortran test.f90
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

Seems that it does not find the library libSystem. I changed all 
the library paths in my bash_profile


to include /usr/lib but does not work. The only solution for the 
moment is to compile with


gfortran test.f90-L/usr/lib

but this is not a practical option... Any idea on how to fix this?

Thanks in advance

--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.1154135?hl=en> 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile <https://www.bsc.es/houzeaux-guillaume>
ResearcherID: D-4950-2012
Scientific Profile: 
<https://www.researchgate.net/profile/Guillaume_Houzeaux> 
<http://scholar.google.es/citations?user=cL9khdYJ=en> 
<http://orcid.org/-0002-2592-1426> 
<http://www.researcherid.com/rid/D-4950-2012>




--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II -

Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones




On 11/10/2019 1:41 pm, Guillaume Houzeaux @ BSC wrote:

Chris, thanks a lot for your very quick answer!

1. I followed the path for migration and reinstalled all packages. I 
will try to do it once more to be sure.

2. Xcode version: 11.0


Please update to 11.1. 11.0 indeed has a number of issues since fixed.

Reading specs from 
/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../libgfortran.spec

rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' '-shared-libgcc' 
'-mtune=core2'

COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin18/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/
LIBRARY_PATH=/usr/lib/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/:/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.15.0' '-shared-libgcc' 
'-mtune=core2'
  /opt/local/libexec/gcc/x86_64-apple-darwin18/9.2.0/collect2 
-syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 
-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o -lgfortran 
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm 
-lgcc_ext.10.5 -lgcc -lSystem -v

collect2 version 9.2.0
/opt/local/bin/ld -syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/ 


This I think is your problem. You are using the 10.14 SDK, not the 10.15 
one. Does


/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

even exist on your system ? I guess not.

Chris

-dynamic -arch x86_64 -macosx_version_min 10.15.0 
-weak_reference_mismatches non-weak -o a.out 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0/../../.. 
/var/folders/1z/j0r1q88d2_95cj4fd50r39mrgr/T//cce0rRJI.o -lgfortran 
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm 
-lgcc_ext.10.5 -lgcc -lSystem -v

@(#)PROGRAM:ld  PROJECT:ld64-512.4
BUILD 05:06:53 Aug 16 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:
     /opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.2.0
     /opt/local/lib/gcc9
Framework search paths:
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status




one more request.

please post the full output from compiling your test code with the -v 
option.


cheers Chris

On 11/10/2019 12:59 pm, Chris Jones wrote:


can you please direct us to the exact test application code you are 
using ?


Also, can you confirm the exact Xcode version you are using ?

Have you correctly followed the macports migration guide after 
updating your OS ?


https://trac.macports.org/wiki/Migration

cheers Chris

On 11/10/2019 12:55 pm, Guillaume Houzeaux @ BSC wrote:

Hello,

I'm compiling with gfortran9 on catalina and get this error:

gfortran test.f90
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

Seems that it does not find the library libSystem. I changed all the 
library paths in my bash_profile


to include /usr/lib but does not work. The only solution for the 
moment is to compile with


gfortran test.f90-L/usr/lib

but this is not a practical option... Any idea on how to fix this?

Thanks in advance

--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.1154135?hl=en> 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile <https://www.bsc.es/houzeaux-guillaume>
ResearcherID: D-4950-2012
Scientific Profile: 
<https://www.researchgate.net/profile/Guillaume_Houzeaux> 
<http://scholar.google.es/citations?user=cL9khdYJ=en> 
<http://orcid.org/-0002-2592-1426> 
<http://www.researcherid.com/rid/D-4950-2012>




--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.11541

Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones
ple-darwin19/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.2.0/../../.. 
/var/folders/97/z7_b52957j36mhz075gflttrgn/T//ccC4YLDY.o -lgfortran 
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm 
-lgcc_ext.10.5 -lgcc -lSystem -v

collect2 version 9.2.0
/opt/local/bin/ld -syslibroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/ -dynamic -arch 
x86_64 -macosx_version_min 10.15.0 -weak_reference_mismatches non-weak 
-o a.out -L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.2.0 
-L/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.2.0/../../.. 
/var/folders/97/z7_b52957j36mhz075gflttrgn/T//ccC4YLDY.o -lgfortran 
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm 
-lgcc_ext.10.5 -lgcc -lSystem -v

@(#)PROGRAM:ld  PROJECT:ld64-512.4
BUILD 14:16:54 Aug 26 2019
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em

Library search paths:
/opt/local/lib/gcc9/gcc/x86_64-apple-darwin19/9.2.0
/opt/local/lib/gcc9
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib
Framework search paths:

/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/

Oberon ~/cernbox/MacPorts > ./a.out
   55.000

Oberon ~/cernbox/MacPorts > otool -L ./a.out
./a.out:
	/opt/local/lib/libgcc/libgfortran.5.dylib (compatibility version 6.0.0, 
current version 6.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1281.0.0)
	/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)
	/opt/local/lib/libgcc/libquadmath.0.dylib (compatibility version 1.0.0, 
current version 1.0.0)

Oberon ~/cernbox/MacPorts >


On 11/10/2019 1:02 pm, Chris Jones wrote:


one more request.

please post the full output from compiling your test code with the -v 
option.


cheers Chris

On 11/10/2019 12:59 pm, Chris Jones wrote:


can you please direct us to the exact test application code you are 
using ?


Also, can you confirm the exact Xcode version you are using ?

Have you correctly followed the macports migration guide after 
updating your OS ?


https://trac.macports.org/wiki/Migration

cheers Chris

On 11/10/2019 12:55 pm, Guillaume Houzeaux @ BSC wrote:

Hello,

I'm compiling with gfortran9 on catalina and get this error:

gfortran test.f90
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

Seems that it does not find the library libSystem. I changed all the 
library paths in my bash_profile


to include /usr/lib but does not work. The only solution for the 
moment is to compile with


gfortran test.f90-L/usr/lib

but this is not a practical option... Any idea on how to fix this?

Thanks in advance

--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.1154135?hl=en> 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile <https://www.bsc.es/houzeaux-guillaume>
ResearcherID: D-4950-2012
Scientific Profile: 
<https://www.researchgate.net/profile/Guillaume_Houzeaux> 
<http://scholar.google.es/citations?user=cL9khdYJ=en> 
<http://orcid.org/-0002-2592-1426> 
<http://www.researcherid.com/rid/D-4950-2012>




Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones



one more request.

please post the full output from compiling your test code with the -v 
option.


cheers Chris

On 11/10/2019 12:59 pm, Chris Jones wrote:


can you please direct us to the exact test application code you are using ?

Also, can you confirm the exact Xcode version you are using ?

Have you correctly followed the macports migration guide after updating 
your OS ?


https://trac.macports.org/wiki/Migration

cheers Chris

On 11/10/2019 12:55 pm, Guillaume Houzeaux @ BSC wrote:

Hello,

I'm compiling with gfortran9 on catalina and get this error:

gfortran test.f90
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

Seems that it does not find the library libSystem. I changed all the 
library paths in my bash_profile


to include /usr/lib but does not work. The only solution for the 
moment is to compile with


gfortran test.f90-L/usr/lib

but this is not a practical option... Any idea on how to fix this?

Thanks in advance

--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
<https://www.google.es/maps/place/Carrer+de+Jordi+Girona,+08034+Barcelona/@41.3881175,2.1132195,17z/data=!3m1!4b1!4m8!1m2!10m1!1e2!3m4!1s0x12a4985099390467:0xd9abcf1987739b3e!8m2!3d41.3881175!4d2.1154135?hl=en> 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile <https://www.bsc.es/houzeaux-guillaume>
ResearcherID: D-4950-2012
Scientific Profile: 
<https://www.researchgate.net/profile/Guillaume_Houzeaux> 
<http://scholar.google.es/citations?user=cL9khdYJ=en> 
<http://orcid.org/-0002-2592-1426> 
<http://www.researcherid.com/rid/D-4950-2012>




Re: libSystem not found using gfortran

2019-10-11 Thread Chris Jones



can you please direct us to the exact test application code you are using ?

Also, can you confirm the exact Xcode version you are using ?

Have you correctly followed the macports migration guide after updating 
your OS ?


https://trac.macports.org/wiki/Migration

cheers Chris

On 11/10/2019 12:55 pm, Guillaume Houzeaux @ BSC wrote:

Hello,

I'm compiling with gfortran9 on catalina and get this error:

gfortran test.f90
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status

Seems that it does not find the library libSystem. I changed all the 
library paths in my bash_profile


to include /usr/lib but does not work. The only solution for the moment 
is to compile with


gfortran test.f90-L/usr/lib

but this is not a practical option... Any idea on how to fix this?

Thanks in advance

--
Guillaume Houzeaux
Team Leader
Dpt. Computer Applications in Science and Engineering
Barcelona Supercomputing Center (BSC-CNS)
Edificio NEXUS II - Office 3A, c) Jordi Girona 29
08034 Barcelona, Spain

Location: 
 


Tel: +34 93 413 7781
Skype user: guillaume_houzeaux_bsc
WWW: BSC profile 
ResearcherID: D-4950-2012
Scientific Profile: 
 
 
 





Re: MacPorts compatible with macOS 10.15 Catalina

2019-10-08 Thread Chris Jones




On 08/10/2019 9:05 am, Peter Hohmann via macports-users wrote:

So just reinstall even though there is no 10.15 version and using the 10.14 
version instead?


No. Until a binary installer specific for 10.15 is available, you need 
to install macports from source.


Re: MacPorts compatible with macOS 10.15 Catalina

2019-10-08 Thread Chris Jones

The solution is in the error below...

Follow the guidelines at

https://trac.macports.org/wiki/Migration

When reinstalling macports, as there is currently no binary installer 
you will have to follow the install from source option.


https://www.macports.org/install.php

Chris

On 08/10/2019 8:45 am, Peter Hohmann via macports-users wrote:

Hello,

yesterday I updated my Mac Mini running macOS Mojave to macOS 10.15 Catalina. 
Macports might have been up to date before the migration from 10.14 to 10.15 
(Macports 2.6.1, regularly updated via sudo port selfupdate), but after 
updating to 10.15 I get the error message

Error: Current platform "darwin 19" does not match expected platform "darwin 18"
Error: If you upgraded your OS, please follow the migration instructions: 
https://trac.macports.org/wiki/Migration
OS platform mismatch
 while executing
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch

Is there a solution for the incompatibility? Unfortunately, I am not the expert 
for using the terminal and only use Macports for a few smaller applications. On 
the Macports website there are only installers up to macOS 10.14.


Re: snowleopardfixes is obsolete; please uninstall it.

2019-10-06 Thread Chris Jones
Hi,

You must have not upgraded that machine for a very very long time, as 
snowleopardfixes was replaced some time ago now. Not upgrading machines for 
extended periods can lead to problems when you do, and is not advised.

In this case do what it says below. Uninstall the port and try again.

Chris

> On 5 Oct 2019, at 11:34 pm, Jeffrey Walton  wrote:
> 
> Hi Everyone,
> 
> I'm trying to get an old PowerMac upgraded. I'm seeing the error
> message below. Cat'ing the log, I can't tell which package I should
> remove.
> 
> What package should be removed?
> 
> Thanks in advance.
> 
> = Terminal commands =
> 
> root# port selfupdate && port upgrade outdated && port clean inactive
> &&  port -f uninstall inactive
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.6.1 installed,
> MacPorts base version 2.6.1 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is already the latest version
> 
> = Terminal Output =
> 
> The ports tree has been updated. To upgrade your installed ports, you should 
> run
>  port upgrade outdated
> --->  Configuring snowleopardfixes
> Error: snowleopardfixes is obsolete; please uninstall it.
> Error: Failed to configure snowleopardfixes: obsolete port
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_snowleopardfixes/snowleopardfixes/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> = Log file =
> 
> root# cat 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_snowleopardfixes/snowleopardfixes/main.log
> version:1
> :debug:sysinfo Mac OS X 10.5 (darwin/9.8.0) arch powerpc
> :debug:sysinfo MacPorts 2.5.4
> :debug:sysinfo Xcode 3.1.4
> :debug:sysinfo SDK 10.5
> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.5
> :debug:clean snowleopardfixes has no conflicts
> :debug:main Executing org.macports.main (snowleopardfixes)
> :debug:main dropping privileges: euid changed to 507, egid changed to 500.
> :debug:archivefetch archivefetch phase started at Sat Aug 10 03:24:42 EDT 2019
> :debug:archivefetch Executing org.macports.archivefetch (snowleopardfixes)
> :debug:archivefetch Privilege de-escalation not attempted as not
> running as root.
> :debug:fetch fetch phase started at Sat Aug 10 03:24:42 EDT 2019
> :notice:fetch --->  Fetching distfiles for snowleopardfixes
> :debug:fetch elevating privileges for fetch: euid changed to 0, egid
> changed to 0.
> :debug:fetch dropping privileges: euid changed to 507, egid changed to 500.
> :debug:fetch Executing org.macports.fetch (snowleopardfixes)
> :debug:fetch Privilege de-escalation not attempted as not running as root.
> :debug:checksum checksum phase started at Sat Aug 10 03:24:42 EDT 2019
> :notice:checksum --->  Verifying checksums for snowleopardfixes
> :debug:checksum Executing org.macports.checksum (snowleopardfixes)
> :debug:checksum Privilege de-escalation not attempted as not running as root.
> :debug:extract extract phase started at Sat Aug 10 03:24:43 EDT 2019
> :notice:extract --->  Extracting snowleopardfixes
> :debug:extract Executing org.macports.extract (snowleopardfixes)
> :debug:extract Privilege de-escalation not attempted as not running as root.
> :debug:patch patch phase started at Sat Aug 10 03:24:43 EDT 2019
> :debug:patch Executing org.macports.patch (snowleopardfixes)
> :debug:patch Privilege de-escalation not attempted as not running as root.
> :debug:configure configure phase started at Sat Aug 10 03:24:43 EDT 2019
> :notice:configure --->  Configuring snowleopardfixes
> :debug:configure Preferred compilers: gcc-4.2 apple-gcc-4.2 gcc-4.0
> macports-clang-3.4 macports-clang-3.3
> :debug:configure Using compiler 'Xcode GCC 4.2'
> :debug:configure Executing proc-pre-org.macports.configure-configure-0
> :error:configure snowleopardfixes is obsolete; please uninstall it.
> :error:configure Failed to configure snowleopardfixes: obsolete port
> :debug:configure Error code: NONE
> :debug:configure Backtrace: obsolete port
> :debug:configure while executing
> :debug:configure "$pre $targetname"
> :error:configure See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_snowleopardfixes/snowleopardfixes/main.log
> for details.
> version:1
> :debug:sysinfo Mac OS X 10.5 (darwin/9.8.0) arch powerpc
> :debug:sysinfo MacPorts 2.6.1
> :debug:sysinfo Xcode 3.1.4
> :debug:sysinfo SDK 10.5
> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.5
> :debug:clean snowleopardfixes has no conflicts
> :debug:main Executing org.macports.main (snowleopardfixes)
> :debug:main dropping privileges: euid changed to 507, egid changed to 500.
> :debug:main Skipping completed org.macports.archivefetch (snowleopardfixes)
> :debug:main Privilege de-escalation not attempted as not running as root.
> :debug:main Skipping completed org.macports.fetch 

Re: Xcode and gcc conflict: resolved soon?

2019-10-04 Thread Chris Jones

Hi,

Please always provide the exact error messages when reporting problems, 
otherwise it is difficult to know exactly what you are referring. There 
are a number of different issues at the moment w.r.t. Xcode 11.


That said, its probably not possible at this point to give you a 
timescale when everything will be fixed with Xcode 11, partly because a 
number of the issues are beyond macPorts control, and require fixes from 
upstream (or perhaps even from Apple for Xcode itself).


So yes, at this point if you do not wish to have to deal with or help 
fix these issues, you should downgrade Xcode back to 10.x.


Chris

On 04/10/2019 4:19 pm, Thomas Ruedas wrote:

Hi,
I made the mistake of upgrading Xcode to the latest version (11.0), 
where Apple seems to have introduced stuff that breaks a lot of things. 
Among these, it seems, is gcc9. More specifically, when I tried to 
upgrade outdated ports, a number of them could not be compiled, such as 
poppler and openblas, and the discussions in the newsgroups indicate 
that it has to do with the new Xcode.
Is there reason to expect that this conflict, specifically the problems 
with gcc9 and with openblas, are resolved in the new future, or should I 
try to go back to the old Xcode?

Thomas
PS: I am on the latest Mojave.


Re: py36-pyqt5 Failed to determine details of Qt installation.

2019-10-02 Thread Chris Jones




We are discovering, due to the Xcode 11 upgrade, just how many places in 
MacPorts the path to the 10.14 SDK got baked into files where we didn't mean 
for it to be. There are many other mailing list threads and tickets being filed 
with us about this. Until this is all ironed out, your simplest course of 
action would be to uninstall Xcode 11 and reinstall Xcode 10.



Will there be a notification or something when this is all ironed out?


Unlikely, as its a distributed issue, that needs fixes in numerous ports 
etc. There probably will not be a single moment when 'everything gets 
fixed' just a gradual fixing of the various issues over time.


I suggest instead you add yourself to the cc list in whatever tickets 
are open for the ports in question you care about.


https://trac.macports.org/wiki/Tickets

Chris


Re: Failed to install libgcc9: no destroot found

2019-09-27 Thread Chris Jones

Reinstalling the os is probably not necessary. I would start with just wiping 
macports and reinstalling that from scratch.

https://guide.macports.org/chunked/installing.macports.uninstalling.html

> On 28 Sep 2019, at 1:03 am, Vahid Askarpour  wrote:
> 
> Perhaps my best course of action is to reinstall the OS, Xcode and then 
> MacPorts.
> 
> Thank you all for your suggestions.
> Vahid
> 
>> On Sep 27, 2019, at 6:28 PM, Bill Cole 
>>  wrote:
>> 
>> On 27 Sep 2019, at 16:51, Chris Jones wrote:
>> 
>>>>> On 27 Sep 2019, at 9:28 pm, Vahid Askarpour  wrote:
>>>>> 
>>>>> When I upgraded to Majove and installed Xcode 11.1, I ended up with 
>>>>> gcc-4.2.1 and libgcc in /usr/bin and /usr/lib. Before, when I had High 
>>>>> Sierra, I was running xcrysden with no issues.
>>> 
>>> That makes no sense at all. MacOS does not ship gcc,
>> 
>> What exactly does that sentence mean?
>> 
>> On my Mojave machine:
>> 
>> $ /usr/bin/gcc -v
>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
>> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
>> Apple clang version 11.0.0 (clang-1100.0.33.8)
>> Target: x86_64-apple-darwin18.7.0
>> Thread model: posix
>> InstalledDir: 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>> 
>> It's not technically The Real GCC, but it is an executable binary at 
>> /usr/bin/gcc why acts a lot like GCC 4.2.1.
>> 
>> Also:
>> 
>> $ ls -l /usr/lib/libgcc*
>> lrwxr-xr-x  1 root  wheel  15 Sep 25 08:41 /usr/lib/libgcc_s.1.dylib -> 
>> libSystem.dylib
>> 
>> Which is profoundly "Not Really LibGCC" but it is apparently close enough.
>> 
>> On High Sierra:
>> 
>> $ /usr/bin/gcc -v
>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
>> --with-gxx-include-dir=/usr/include/c++/4.2.1
>> Apple LLVM version 10.0.0 (clang-1000.11.45.5)
>> Target: x86_64-apple-darwin17.7.0
>> Thread model: posix
>> InstalledDir: 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>> 
>> $ ls -l /usr/lib/libgcc*
>> lrwxr-xr-x  1 root  wheel 17 Sep 19  2018 /usr/lib/libgcc_s.1.dylib -> 
>> libSystem.B.dylib
>> lrwxr-xr-x  1 root  wheel 19 Oct 15  2018 /usr/lib/libgcc_s.10.4.dylib 
>> -> libgcc_s.10.5.dylib
>> -rwxr-xr-x  1 root  wheel  30948 Oct  6  2017 /usr/lib/libgcc_s.10.5.dylib
>> 
>> THAT is interesting...
>> 
>> $ otool -L  /usr/lib/libgcc_s.10.5.dylib
>> /usr/lib/libgcc_s.10.5.dylib:
>>/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
>> 795.0.0)
>> 
>> Oh, OK, not really very interesting, just baroque...
>> 
>> (El Cap is very similar)
>> 
>> -- 
>> Bill Cole
>> b...@scconsult.com or billc...@apache.org
>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>> Not Currently Available For Hire
> 


  1   2   3   >