Re: MacPorts 2.7.0 has been released

2021-05-20 Thread Ryan Schmidt 
On May 20, 2021, at 17:22, raf wrote:
> 
> When I disable /usr/lib/libsqlite3.dylib by renaming it,
> the error changes to a symbol lookup failure:
> 
>> port help
>  dlopen(/opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib, 6): can't 
> resolve symbol _kDADiskDescriptionMediaBSDNameKey in 
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation because 
> dependent dylib #2 could not be loaded in 
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
>  while executing
>  "load /opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib"
>  ("package ifneeded macports 1.0" script)
>  invoked from within
>  "package require macports"
>  (file "/opt/local/bin/port" line 46)
> 
> Oops. And now PAM/su/sudo are now broken. I shouldn't have done that. :-)
> 

Correct. Don't modify things in /usr/lib or other locations reserved for use by 
Apple. OS X 10.11 and later will prevent you from doing so via System Integrity 
Protection. On earlier OS versions, you'll just have to remember not to touch 
those parts of the system.

Re: MacPorts 2.7.0 has been released

2021-05-20 Thread raf 
On Thu, May 20, 2021 at 01:15:05AM -0500, Ryan Schmidt 
 wrote:

> On May 19, 2021, at 18:43, raf wrote:
> 
> > I have the same problem on 10.14.6
> 
> Thanks for confirming. So far everyone affected has been on 10.14. I suspect 
> the difference between the 10.15 SDK SQLite version and the 10.14 runtime 
> SQLite version is the issue.
> 
> 
> >> sqlite3 --version
> >  3.35.5 2021-04-19 18:32:05 
> > 1b256d97b553a9611efca188a3d995a2fff712759044ba480f9a0c9e98fae886
> >> /usr/bin/sqlite3 --version
> >  3.24.0 2018-06-04 14:10:15 
> > 95fbac39baaab1c3a84fdfc82ccb7f42398b2e92f18a2a57bce1d4a713cbaapl
> > 
> > And every attempt to use the port command gives an error:
> > 
> >> port help
> >  sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER 
> > TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants
> >  while executing
> >  "registry::open $db_path"
> >  (procedure "mportinit" line 712)
> >  invoked from within
> >  "mportinit ui_options global_options global_variations"
> >  Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: 
> > near "COLUMN": syntax error (1) while executing query: ALTER TABLE 
> > registry.ports RENAME COLUMN negated_variants TO requested_variants
> > 
> > It won't even selfupdate. Do I need to disable SIP and fiddle with 
> > /usr/bin/sqlite3?
> 
> Nope. Visit the ticket, share what you've done there, help us find the 
> solution there.

Thanks. Will do.

cheers,
raf

Re: MacPorts 2.7.0 has been released

2021-05-20 Thread raf 
On Thu, May 20, 2021 at 01:13:51AM -0500, Ryan Schmidt 
 wrote:

> On May 19, 2021, at 18:31, Bjarne D Mathiesen wrote:
> 
> > Ryan Schmidt wrote:
> >> Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax
> >> first appeared in SQLite 3.25.0, and MacPorts base is coded only to
> >> use the "RENAME COLUMN" syntax with SQLite 3.25.0 and later; for
> >> earlier versions, a different method is used:
> >> 
> >> What version of SQLite does your version of macOS have? Run:
> >> 
> >> /usr/bin/sqlite3 --version
> >> 
> >> I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that 
> >> problem.
> > 
> > Qs:
> > 1) does MacPorts !explicitly! request /usr/bin/sqlite3
> 
> MacPorts uses /usr/lib/libsqlite3.dylib.
> 
> >   -or- does MacPorts use the one found in ${PATH}
> 
> > 2) is it advantagerous for MacPorts to use sqlite3 >= 3.25.0
> > 
> > eg for 10.6.8 I've got :
> > 
> > #=> /usr/bin/sqlite3 --version
> > 3.6.12
> > #=> which sqlite3
> > /opt/local/bin/sqlite3
> > #=> sqlite3 --version
> > 3.35.5 2021-04-19 18:32:05 1b256d97b ... e98fae886
> 
> MacPorts by default uses the version of SQLite included with macOS. MacPorts 
> 2.7.0 is compatible with every version of SQLite that comes with every 
> supported version of macOS (10.4 and later including 11).
> 
> The problem here may be that the version of SQLite whose headers were found 
> at build time is different from the version of SQLite whose library was found 
> at runtime. See the ticket.

When I disable /usr/lib/libsqlite3.dylib by renaming it,
the error changes to a symbol lookup failure:

  > port help
  dlopen(/opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib, 6): can't 
resolve symbol _kDADiskDescriptionMediaBSDNameKey in 
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation because 
dependent dylib #2 could not be loaded in 
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
  while executing
  "load /opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib"
  ("package ifneeded macports 1.0" script)
  invoked from within
  "package require macports"
  (file "/opt/local/bin/port" line 46)

Oops. And now PAM/su/sudo are now broken. I shouldn't have done that. :-)

cheers,
raf

Re: MacPorts 2.7.0 has been released

2021-05-20 Thread Ryan Schmidt 
On May 19, 2021, at 18:43, raf wrote:

> I have the same problem on 10.14.6

Thanks for confirming. So far everyone affected has been on 10.14. I suspect 
the difference between the 10.15 SDK SQLite version and the 10.14 runtime 
SQLite version is the issue.


>> sqlite3 --version
>  3.35.5 2021-04-19 18:32:05 
> 1b256d97b553a9611efca188a3d995a2fff712759044ba480f9a0c9e98fae886
>> /usr/bin/sqlite3 --version
>  3.24.0 2018-06-04 14:10:15 
> 95fbac39baaab1c3a84fdfc82ccb7f42398b2e92f18a2a57bce1d4a713cbaapl
> 
> And every attempt to use the port command gives an error:
> 
>> port help
>  sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER 
> TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants
>  while executing
>  "registry::open $db_path"
>  (procedure "mportinit" line 712)
>  invoked from within
>  "mportinit ui_options global_options global_variations"
>  Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: 
> near "COLUMN": syntax error (1) while executing query: ALTER TABLE 
> registry.ports RENAME COLUMN negated_variants TO requested_variants
> 
> It won't even selfupdate. Do I need to disable SIP and fiddle with 
> /usr/bin/sqlite3?

Nope. Visit the ticket, share what you've done there, help us find the solution 
there.

Re: MacPorts 2.7.0 has been released

2021-05-20 Thread Ryan Schmidt 
On May 19, 2021, at 18:31, Bjarne D Mathiesen wrote:

> Ryan Schmidt wrote:
>> Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax
>> first appeared in SQLite 3.25.0, and MacPorts base is coded only to
>> use the "RENAME COLUMN" syntax with SQLite 3.25.0 and later; for
>> earlier versions, a different method is used:
>> 
>> What version of SQLite does your version of macOS have? Run:
>> 
>> /usr/bin/sqlite3 --version
>> 
>> I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that problem.
> 
> Qs:
> 1) does MacPorts !explicitly! request /usr/bin/sqlite3

MacPorts uses /usr/lib/libsqlite3.dylib.

>   -or- does MacPorts use the one found in ${PATH}

> 2) is it advantagerous for MacPorts to use sqlite3 >= 3.25.0
> 
> eg for 10.6.8 I've got :
> 
> #=> /usr/bin/sqlite3 --version
> 3.6.12
> #=> which sqlite3
> /opt/local/bin/sqlite3
> #=> sqlite3 --version
> 3.35.5 2021-04-19 18:32:05 1b256d97b ... e98fae886

MacPorts by default uses the version of SQLite included with macOS. MacPorts 
2.7.0 is compatible with every version of SQLite that comes with every 
supported version of macOS (10.4 and later including 11).

The problem here may be that the version of SQLite whose headers were found at 
build time is different from the version of SQLite whose library was found at 
runtime. See the ticket.

Re: MacPorts 2.7.0 has been released

2021-05-19 Thread raf 
On Thu, May 20, 2021 at 01:31:18AM +0200, Bjarne D Mathiesen 
 wrote:

> Ryan Schmidt wrote:
> > Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax
> > first appeared in SQLite 3.25.0, and MacPorts base is coded only to
> > use the "RENAME COLUMN" syntax with SQLite 3.25.0 and later; for
> > earlier versions, a different method is used:
> >
> > What version of SQLite does your version of macOS have? Run:
> > 
> > /usr/bin/sqlite3 --version
> > 
> > I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that problem.
> 
> Qs:
> 1) does MacPorts !explicitly! request /usr/bin/sqlite3
>-or- does MacPorts use the one found in ${PATH}
> 2) is it advantagerous for MacPorts to use sqlite3 >= 3.25.0
> 
> eg for 10.6.8 I've got :
> 
> #=> /usr/bin/sqlite3 --version
> 3.6.12
> #=> which sqlite3
> /opt/local/bin/sqlite3
> #=> sqlite3 --version
> 3.35.5 2021-04-19 18:32:05 1b256d97b ... e98fae886
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa

I have the same problem on 10.14.6:

  > sqlite3 --version
  3.35.5 2021-04-19 18:32:05 
1b256d97b553a9611efca188a3d995a2fff712759044ba480f9a0c9e98fae886
  > /usr/bin/sqlite3 --version
  3.24.0 2018-06-04 14:10:15 
95fbac39baaab1c3a84fdfc82ccb7f42398b2e92f18a2a57bce1d4a713cbaapl

And every attempt to use the port command gives an error:

 > port help
  sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER 
TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants
  while executing
  "registry::open $db_path"
  (procedure "mportinit" line 712)
  invoked from within
  "mportinit ui_options global_options global_variations"
  Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: near 
"COLUMN": syntax error (1) while executing query: ALTER TABLE registry.ports 
RENAME COLUMN negated_variants TO requested_variants

It won't even selfupdate. Do I need to disable SIP and fiddle with 
/usr/bin/sqlite3?

cheers,
raf

Re: MacPorts 2.7.0 has been released

2021-05-19 Thread Bjarne D Mathiesen 



Ryan Schmidt wrote:
> Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax
> first appeared in SQLite 3.25.0, and MacPorts base is coded only to
> use the "RENAME COLUMN" syntax with SQLite 3.25.0 and later; for
> earlier versions, a different method is used:
>
> What version of SQLite does your version of macOS have? Run:
> 
> /usr/bin/sqlite3 --version
> 
> I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that problem.

Qs:
1) does MacPorts !explicitly! request /usr/bin/sqlite3
   -or- does MacPorts use the one found in ${PATH}
2) is it advantagerous for MacPorts to use sqlite3 >= 3.25.0

eg for 10.6.8 I've got :

#=> /usr/bin/sqlite3 --version
3.6.12
#=> which sqlite3
/opt/local/bin/sqlite3
#=> sqlite3 --version
3.35.5 2021-04-19 18:32:05 1b256d97b ... e98fae886

-- 
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: MacPorts 2.7.0 has been released

2021-05-19 Thread Ryan Schmidt 
On May 19, 2021, at 18:08, Ryan Schmidt wrote:
> 
> On May 19, 2021, at 11:04, Henning Hraban Ramm wrote:
> 
>> $ sudo port upgrade outdated
>> Password:
>> sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER 
>> TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants
>>   while executing
>> "registry::open $db_path"
>>   (procedure "mportinit" line 712)
>>   invoked from within
>> "mportinit ui_options global_options global_variations"
>> Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: 
>> near "COLUMN": syntax error (1) while executing query: ALTER TABLE 
>> registry.ports RENAME COLUMN negated_variants TO requested_variants
>> 
>> 
>> What can I do to fix this?
> 
> Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax first 
> appeared in SQLite 3.25.0, and MacPorts base is coded only to use the "RENAME 
> COLUMN" syntax with SQLite 3.25.0 and later; for earlier versions, a 
> different method is used:
> 
> https://github.com/macports/macports-base/commit/19c933969bc62ee54c86fbadaf4d98252b3df5ee#diff-780a9c883e001748860d3ed6b65f88c3be24a21feb1e71a408898f6243149b18R752-R753
> 
> What version of SQLite does your version of macOS have? Run:
> 
> /usr/bin/sqlite3 --version
> 
> I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that problem.

And I see we already have a ticket for this:

https://trac.macports.org/ticket/62929

So it would be best to add your information there, and Cc yourself there if you 
would like updates about this issue.

Re: MacPorts 2.7.0 has been released

2021-05-19 Thread Ryan Schmidt 
On May 19, 2021, at 11:04, Henning Hraban Ramm wrote:

> $ sudo port upgrade outdated
> Password:
> sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER 
> TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants
>while executing
> "registry::open $db_path"
>(procedure "mportinit" line 712)
>invoked from within
> "mportinit ui_options global_options global_variations"
> Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: near 
> "COLUMN": syntax error (1) while executing query: ALTER TABLE registry.ports 
> RENAME COLUMN negated_variants TO requested_variants
> 
> 
> What can I do to fix this?

Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax first 
appeared in SQLite 3.25.0, and MacPorts base is coded only to use the "RENAME 
COLUMN" syntax with SQLite 3.25.0 and later; for earlier versions, a different 
method is used:

https://github.com/macports/macports-base/commit/19c933969bc62ee54c86fbadaf4d98252b3df5ee#diff-780a9c883e001748860d3ed6b65f88c3be24a21feb1e71a408898f6243149b18R752-R753

What version of SQLite does your version of macOS have? Run:

/usr/bin/sqlite3 --version

I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that problem.

Re: MacPorts 2.7.0 has been released

2021-05-19 Thread Bjarne D Mathiesen 



Ken Cunningham wrote:
> I seem to remember something about a bunch of symlinks you made from cctools 
> things into macports cctools in the past (perhaps I recall wrong).

You were recalling partially correctly : I didn't symlink cctools into
/usr/bin - I pushed the Apple stuff common with cctools aside in order
to be able to compile mysql57 :

* https://trac.macports.org/ticket/59072#comment:1
* '[workaround] 10.6.8 & mysql57'

The promised forwardported fix from mysql56 -> mysql57 never seemed to
materialise itself [thinking]

But I think I'll (also) keep my :
/usr/bin/cc.apple -> ../llvm-gcc-4.2/bin/llvm-gcc-4.2
/usr/bin/cc -> /opt/local/bin/clang
fix

-- 
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: MacPorts 2.7.0 has been released

2021-05-19 Thread Bjarne D Mathiesen 
OK - I can see what the problem is :

It can't find at valid assembler - and checking I get :
root@MiniWeb 18:10:20 /usr
#=> find . -name 'as.*'
./bin/as.orig
./share/aclocal-1.10/as.m4
./share/man/man1/as.1

so at some point in time I've moved the Apple assembler aside to solve a
MacPorts problem [thinking] - in particular I think it's this :
https://trac.macports.org/ticket/59072#comment:1
It was discussed in the thread '[workaround] 10.6.8 & mysql57'
on 28/01/2021

-- 
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: MacPorts 2.7.0 has been released

2021-05-19 Thread Bjarne D Mathiesen 



Chris Jones wrote:
> See `config.log' for more details
> 
> We need to see what is in this file… (from the messages you posted below).
> 
re-instaling from source with :

./configure --prefix=/opt/local
make
make install

gives :

checking build system type... x86_64-apple-darwin10.8.0
checking host system type... x86_64-apple-darwin10.8.0
checking target system type... x86_64-apple-darwin10.8.0
checking MacPorts version... 2.7.0
checking for sw_vers... /usr/bin/sw_vers
checking for defaults... /usr/bin/defaults
checking for xcode-select... /usr/bin/xcode-select
checking macOS version... 10.6.8
checking Xcode location... /Developer
checking Xcode version... 4.0.1
checking for clang... clang

& no problems [thumbsup]

but emulating the selfupdate process with
CC=/usr/bin/cc ./configure \
 --prefix=/opt/local \
 --with-install-user=root \
 --with-install-group=admin \
 --with-directory-mode=0755 \
 --enable-readline \
&& make SELFUPDATING=1 \
&& make install SELFUPDATING=1

gives the following log :
https://macports.mathiesen.info/logs/MacPorts-2.7.0/config.log

-- 
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: MacPorts 2.7.0 has been released

2021-05-19 Thread Henning Hraban Ramm 
> Am 19.05.2021 um 12:15 schrieb Joshua Root :
> 
> The MacPorts Project is happy to announce that the 2.7.0 version has now
> been released. It is available via the usual methods:

$ sudo port selfupdate
Password:
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.6.4 installed,
MacPorts base version 2.7.0 downloaded.
--->  Updating the ports tree
--->  MacPorts base is outdated, installing new version 2.7.0
Installing new MacPorts release in /opt/local as root:wheel; permissions 0755

$ sudo port upgrade outdated
Password:
sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER 
TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants
while executing
"registry::open $db_path"
(procedure "mportinit" line 712)
invoked from within
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: near 
"COLUMN": syntax error (1) while executing query: ALTER TABLE registry.ports 
RENAME COLUMN negated_variants TO requested_variants


What can I do to fix this?
I used "port upgrade outdated" just yesterday, so everything should be quite 
recent.

(macOS 10.14.6)

Hraban


signature.asc
Description: Message signed with OpenPGP

Re: MacPorts 2.7.0 has been released

2021-05-19 Thread Ken Cunningham 
my SnowLeopard macports-base built and installed just fine.

As Chris says, post up your config log and we might see the error.

Or — simpler perhaps -- just try to build any “hello_world.c” program at all 
with your llvm-gcc-4.2 compiler and you might find out how it is broken.

I seem to remember something about a bunch of symlinks you made from cctools 
things into macports cctools in the past (perhaps I recall wrong).

K

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: MacPorts 2.7.0 has been released

2021-05-19 Thread Bjarne D Mathiesen 
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: MacPorts 2.7.0 has been released

2021-05-19 Thread Bjarne D Mathiesen 
I'm getting this on 10.6.8

Joshua Root wrote:
> The MacPorts Project is happy to announce that the 2.7.0 version has now
> been released. It is available via the usual methods:
> 
>  - selfupdate if you already have MacPorts installed

Installing new MacPorts release in /opt/local as root:admin; permissions
0755

DEBUG: system -W
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base:
CC=/usr/bin/cc ./configure --prefix=/opt/local --with-install-user=root
--with-install-group=admin --with-directory-mode=0755 --enable-readline
&& make SELFUPDATING=1 && make install SELFUPDATING=1
checking build system type... x86_64-apple-darwin10.8.0
checking host system type... x86_64-apple-darwin10.8.0
checking target system type... x86_64-apple-darwin10.8.0
checking MacPorts version... 2.7.0
checking for sw_vers... /usr/bin/sw_vers
checking for defaults... /usr/bin/defaults
checking for xcode-select... /usr/bin/xcode-select
checking macOS version... 10.6.8
checking Xcode location... /Developer
checking Xcode version... 4.0.1
checking whether the C compiler works... no
configure: error: in
`/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base':
configure: error: C compiler cannot create executables
See `config.log' for more details
Command failed: CC=/usr/bin/cc ./configure --prefix=/opt/local
--with-install-user=root --with-install-group=admin
--with-directory-mode=0755 --enable-readline && make SELFUPDATING=1 &&
make install SELFUPDATING=1

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

MacPorts 2.7.0 has been released

2021-05-19 Thread Joshua Root 

The MacPorts Project is happy to announce that the 2.7.0 version has now
been released. It is available via the usual methods:

 - selfupdate if you already have MacPorts installed
 - package installers [1] for macOS 11 Big Sur and all older releases
   back to Mac OS X 10.4 Tiger  (universal arm64/x86_64 for macOS 11,
   i386/x86_64 for 10.6, i386/ppc for 10.4 and 10.5, and the rest
   x86_64)
 - source tarballs, both .tar.bz2 [2] and .tar.gz [3]
 - git tag [4]

The list of what's new in 2.7.0 can be found in the ChangeLog [5].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.7.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [6].

- Josh

[1] 
[2] 

[3] 


[4] 
[5] 
[6] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD




OpenPGP_signature
Description: OpenPGP digital signature