Re: [MacPorts] #69737: ld: symbol(s) not found for architecture x86_64 in libX11.a @1.8.8_0+universal

[Mark Brethen]

The reduce developer usually pushes updates for every OS update. However I’m 
using intel based macs, so not in a position to facilitate a macport update for 
the Apple chips.


Sent from my iPhone

> On Apr 15, 2024, at 1:35 PM, MacPorts  wrote:
> 
> #69737: ld: symbol(s) not found for architecture x86_64 in libX11.a
> @1.8.8_0+universal
> +--
> Reporter:  marcoferraris  |  Owner:  jeremyhu
> Type:  defect | Status:  assigned
> Priority:  Normal |  Milestone:
> Component:  ports  |Version:
> Resolution: |   Keywords:
> Port:  xorg-libX11|
> +--
> 
> Comment (by marcoferraris):
> 
> In any case, this ticket should be treated as a ticket regarding the xorg-
> libX11 @1.8.8+universal port and not as a reduce port ticket.
> 
> Of course, any update of the reduce port would be welcome. Please take
> into account my report on X86_64 problems with xorg-libX11
> @1.8.8+universal.
> 
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS

[MacPorts] #68639: reduce @20211019_0: error: ld: symbol(s) not found for architecture arm64

[Mark Brethen]

I would forward this info to the developer. I don’t have time right now to 
test this, but you could try patching the source to use the libffi port instead.

Sent from my iPhone

> On Nov 8, 2023, at 10:07 AM, MacPorts  wrote:
> 
> #68639: reduce @20211019_0: error: ld: symbol(s) not found for architecture 
> arm64
> ---+--
> Reporter:  zzanderr  |  Owner:  mbrethen
> Type:  defect| Status:  assigned
> Priority:  Normal|  Milestone:
> Component:  ports |Version:  2.8.1
> Resolution:|   Keywords:  sonoma arm64
> Port:  reduce|
> ---+--
> 
> Comment (by kencu):
> 
> I fixed this ppc issue in our libffi port a few years ago:
> 
> https://github.com/macports/macports-
> ports/commit/5287b4e585c1277c33540e78cc8c8ef626dd776e
> 
> It looks like reduce is using a bundled libffi, so doesn’t have that fix.
> 
> BTW, I updated and installed reduce on arm64 yesterday… it builds but
> crashed on launch, so needs some testing and may need some sortingbout.
> 
> -- 
> Ticket URL: 
> MacPorts 
> Ports system for macOS

Re: include files for cgxCADTools

[Mark Brethen]

Thanks everyone for the much needed guidance, I submitted a ticket in the trac.

Mark



> On Aug 8, 2022, at 12:08 PM, Robert Kennedy  wrote:
> 
> Mark,
> 
> The Makefile template that you sent me looks like it was based on a Makefile 
> template for C programs, NOT C++ programs.
> 
> For C++, you need to set CXX to the compiler and use CXXFLAGS for the C++ 
> compiler flags.   Use+=.  Do not use := since MacPorts will likely want to 
> add its own flags.
> 
> LDFLAGS should be also be used to set any linker flags.  Again use +=
> e,g,  LDFLAGS += 
> 
> Here is the format.
> 
> $(MAIN): $(OBJS)
>  $(CXX) $(CXXFLAGS) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS)$(LFLAGS) 
> $(FWORKDIRS) $(LIBS) $(FWORKS)
> 
> where LFLAGS += library directories.
> LIBS += library flags e.g.  -lm for math library
> FWORKDIRS += Framework directories etc
> 
> Rob
> From: macports-dev  on behalf of 
> Mark Brethen 
> Sent: August 8, 2022 12:22 PM
> To: Joshua Root 
> Cc: MacPorts Developers 
> Subject: Re: include files for cgxCADTools
>  
> The makefile only sets cc, not c++. If I remove -lstc++ from LIBS, then I 
> need to add it to the portfile using LDFLAGS. The Makefile uses LFLAGS, which 
> I don’t want to override. Should I add LDFLAGS to MAIN, like so:
> 
> $(MAIN): $(OBJS) 
>     $(CC) $(CFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS) 
> $(LDFLAGS)
> 
> 
> 
> 
> 
> 
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
> > On Aug 8, 2022, at 11:10 AM, Joshua Root  wrote:
> > 
> > That's a completely different thing. The language standard is selected by 
> > -std, the stdlib implementation is selected by -stdlib, and linking to a 
> > stdlib directly (as -lstdc++ does) is usually a bug since the C++ compiler 
> > will implicitly add the appropriate stdlib when linking.
> > 
> > - Josh
> > 
> > On 2022-8-9 01:16 , Mark Brethen wrote:
> >> There is also -lstdc++, I thought those should be set in the Portfile. 
> >> Doesn’t macports-clang have its own standard?
> >> Mark Brethen
> >> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com 
> >> <mailto:mark.bret...@gmail.com>>
> >>> On Aug 7, 2022, at 7:22 PM, Ryan Schmidt  >>> <mailto:ryandes...@macports.org <mailto:ryandes...@macports.org>>> wrote:
> >>> 
> >>> In fact, the Makefile already had -std=c++11, but your patchfile removed 
> >>> it. So don't remove it.
> > 

Re: include files for cgxCADTools

[Mark Brethen]

Okay, this setup worked:

Portfile
Description: Binary data


patch-FbdReader-build.diff
Description: Binary data


main.log
Description: Binary data

Mark Brethenmark.bret...@gmail.com



On Aug 8, 2022, at 12:25 PM, Mark Brethen <mark.bret...@gmail.com> wrote:Robert,I assume FWORKDIRS needs to be defined in the portfile? How do you point to the framework? What is $(FWORKS)?Also, it was explained to me that build.args override the makefile whereas build.env are defaults that can be overridden or appended by the makefile. Therein lies my confusion. The ‘+=‘ only works if you use build.env.
Thanks,Mark


On Aug 8, 2022, at 12:08 PM, Robert Kennedy <am...@hotmail.com> wrote:$(FWORKDIRS)

Re: include files for cgxCADTools

[Mark Brethen]

Well, that didn’t work.


main.log
Description: Binary data


Portfile
Description: Binary data


patch-FbdReader-build.diff
Description: Binary data


Mark Brethen
mark.bret...@gmail.com



> On Aug 8, 2022, at 11:22 AM, Mark Brethen  wrote:
> 
> The makefile only sets cc, not c++. If I remove -lstc++ from LIBS, then I 
> need to add it to the portfile using LDFLAGS. The Makefile uses LFLAGS, which 
> I don’t want to override. Should I add LDFLAGS to MAIN, like so:
> 
> $(MAIN): $(OBJS) 
>   $(CC) $(CFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS) 
> $(LDFLAGS)
> 
> 
> 
> 
> 
> 
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Aug 8, 2022, at 11:10 AM, Joshua Root  wrote:
>> 
>> That's a completely different thing. The language standard is selected by 
>> -std, the stdlib implementation is selected by -stdlib, and linking to a 
>> stdlib directly (as -lstdc++ does) is usually a bug since the C++ compiler 
>> will implicitly add the appropriate stdlib when linking.
>> 
>> - Josh
>> 
>> On 2022-8-9 01:16 , Mark Brethen wrote:
>>> There is also -lstdc++, I thought those should be set in the Portfile. 
>>> Doesn’t macports-clang have its own standard?
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>> On Aug 7, 2022, at 7:22 PM, Ryan Schmidt >>> <mailto:ryandes...@macports.org>> wrote:
>>>> 
>>>> In fact, the Makefile already had -std=c++11, but your patchfile removed 
>>>> it. So don't remove it.
>> 
> 

Re: include files for cgxCADTools

[Mark Brethen]

The makefile only sets cc, not c++. If I remove -lstc++ from LIBS, then I need 
to add it to the portfile using LDFLAGS. The Makefile uses LFLAGS, which I 
don’t want to override. Should I add LDFLAGS to MAIN, like so:

$(MAIN): $(OBJS) 
$(CC) $(CFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS) 
$(LDFLAGS)



Makefile
Description: Binary data






Mark Brethen
mark.bret...@gmail.com



> On Aug 8, 2022, at 11:10 AM, Joshua Root  wrote:
> 
> That's a completely different thing. The language standard is selected by 
> -std, the stdlib implementation is selected by -stdlib, and linking to a 
> stdlib directly (as -lstdc++ does) is usually a bug since the C++ compiler 
> will implicitly add the appropriate stdlib when linking.
> 
> - Josh
> 
> On 2022-8-9 01:16 , Mark Brethen wrote:
>> There is also -lstdc++, I thought those should be set in the Portfile. 
>> Doesn’t macports-clang have its own standard?
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> On Aug 7, 2022, at 7:22 PM, Ryan Schmidt >> <mailto:ryandes...@macports.org>> wrote:
>>> 
>>> In fact, the Makefile already had -std=c++11, but your patchfile removed 
>>> it. So don't remove it.
> 

Re: include files for cgxCADTools

[Mark Brethen]

There is also -lstdc++, I thought those should be set in the Portfile. Doesn’t 
macports-clang have its own standard?


Mark Brethen
mark.bret...@gmail.com



> On Aug 7, 2022, at 7:22 PM, Ryan Schmidt  wrote:
> 
> In fact, the Makefile already had -std=c++11, but your patchfile removed it. 
> So don't remove it.

Re: include files for cgxCADTools

[Mark Brethen]

Build results with minimal patch of Makefile. Note in Portfile I have a single 
build.args-append statement.



main.log
Description: Binary data


Portfile
Description: Binary data


patch-FbdReader-build.diff
Description: Binary data


Mark Brethen
mark.bret...@gmail.com



> On Aug 7, 2022, at 7:22 PM, Ryan Schmidt  wrote:
> 
> On Aug 7, 2022, at 19:06, Ryan Schmidt wrote:
> 
>> configure.cxxflags-append -std=c++11
> 
> In fact, the Makefile already had -std=c++11, but your patchfile removed it. 
> So don't remove it.
> 

Re: include files for cgxCADTools

[Mark Brethen]

Interestingly, the Makefile only defined CC, even though the source is c++. Is 
that typical done?



Mark Brethen
mark.bret...@gmail.com



> On Aug 7, 2022, at 7:18 PM, Ryan Schmidt  wrote:
> 
> Why not let make's default value for CXX be used if the user (or in this case 
> MacPorts) doesn't specify it? To accomplish this, remove the "CXX =" line.

Re: include files for cgxCADTools

[Mark Brethen]

If passing build.env, need to remove cc, cxx, etc. assignments in makefile. 
Even ‘cc=‘ will cause those errors.


Mark Brethen
mark.bret...@gmail.com



> On Aug 6, 2022, at 9:47 AM, Mark Brethen  wrote:
> 
> See log file for errors I’m getting with using build.env instead of 
> build.args.
> 
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Aug 5, 2022, at 3:30 PM, Ryan Schmidt  wrote:
>> 
>> On Aug 5, 2022, at 15:26, Mark Brethen wrote:
>>> 
>>> I don’t see these errors when building with macports-clang, only Apple’s 
>>> clang.
>> 
>> Ok. Certainly, different compilers can behave differently. I didn't try to 
>> see what the actual error was, since it was jumbled. If you have an 
>> non-jumbled error message you need help fixing, show us the error.
>> 
>> 
>> 
>> 
> 

Re: include files for cgxCADTools

[Mark Brethen]

It builds successfully when I blacklist Apple’s clang.



Portfile
Description: Binary data


main.log
Description: Binary data


Mark Brethen
mark.bret...@gmail.com



> On Aug 6, 2022, at 12:09 PM, Mark Brethen  wrote:
> 
> Here’s the log file when using build.args instead of build.env and compiling 
> with Apple’s clang. Different failure this time.
> 
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Aug 6, 2022, at 9:47 AM, Mark Brethen  wrote:
>> 
>> See log file for errors I’m getting with using build.env instead of 
>> build.args.
>> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com
>> 
>> 
>> 
>>> On Aug 5, 2022, at 3:30 PM, Ryan Schmidt  wrote:
>>> 
>>> On Aug 5, 2022, at 15:26, Mark Brethen wrote:
>>>> 
>>>> I don’t see these errors when building with macports-clang, only Apple’s 
>>>> clang.
>>> 
>>> Ok. Certainly, different compilers can behave differently. I didn't try to 
>>> see what the actual error was, since it was jumbled. If you have an 
>>> non-jumbled error message you need help fixing, show us the error.
>>> 
>>> 
>>> 
>>> 
>> 
> 

Re: include files for cgxCADTools

[Mark Brethen]

Here’s the log file when using build.args instead of build.env and compiling 
with Apple’s clang. Different failure this time.



main.log
Description: Binary data


Portfile
Description: Binary data


patch-FbdReader-build.diff
Description: Binary data

Mark Brethen
mark.bret...@gmail.com



> On Aug 6, 2022, at 9:47 AM, Mark Brethen  wrote:
> 
> See log file for errors I’m getting with using build.env instead of 
> build.args.
> 
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Aug 5, 2022, at 3:30 PM, Ryan Schmidt  wrote:
>> 
>> On Aug 5, 2022, at 15:26, Mark Brethen wrote:
>>> 
>>> I don’t see these errors when building with macports-clang, only Apple’s 
>>> clang.
>> 
>> Ok. Certainly, different compilers can behave differently. I didn't try to 
>> see what the actual error was, since it was jumbled. If you have an 
>> non-jumbled error message you need help fixing, show us the error.
>> 
>> 
>> 
>> 
> 

Re: include files for cgxCADTools

[Mark Brethen]

See log file for errors I’m getting with using build.env instead of build.args.



Portfile
Description: Binary data


patch-FbdReader-build.diff
Description: Binary data


main.log
Description: Binary data

Mark Brethen
mark.bret...@gmail.com



> On Aug 5, 2022, at 3:30 PM, Ryan Schmidt  wrote:
> 
> On Aug 5, 2022, at 15:26, Mark Brethen wrote:
>> 
>> I don’t see these errors when building with macports-clang, only Apple’s 
>> clang.
> 
> Ok. Certainly, different compilers can behave differently. I didn't try to 
> see what the actual error was, since it was jumbled. If you have an 
> non-jumbled error message you need help fixing, show us the error.
> 
> 
> 
> 

Re: SPOOLES MT routines

[Mark Brethen]

So, moving from a post-patch CFLAGS, etc to a pre-build build.args CalculiX now does not build. So I compared them.Post-Patch::info:build Executing:  cd "/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src" && /usr/bin/make -j1 -w :debug:build system:  cd "/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src" && /usr/bin/make -j1 -w :info:build make: Entering directory `/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src':info:build /opt/local/bin/mpicc-mpich-mp -Wall -O2 -pthread -Os -arch x86_64 -I../../SPOOLES.2.2 -DARCH="Linux" -DSPOOLES -DARPACK -DMATRIXSTORAGE -DUSE_MT=1 -DBLAS_LIBRARIES=vecLibFort -DLAPACK_LIBRARIES=vecLibFort -c ccx_2.18.cPre-Build::info:build Executing:  cd "/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src" && /usr/bin/make -j1 -w CFLAGS="-Os -arch x86_64" FFLAGS="-Os -m64 -fallow-argument-mismatch" LDFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-rpath,/opt/local/lib/libgcc -arch x86_64" :debug:build system:  cd "/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src" && /usr/bin/make -j1 -w CFLAGS="-Os -arch x86_64" FFLAGS="-Os -m64 -fallow-argument-mismatch" LDFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-rpath,/opt/local/lib/libgcc -arch x86_64" :info:build make: Entering directory `/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src'Note that the pre-build approach is overriding the makefile cflags, makefile was patched to cflags += , etc. How do I prevent this?pre-build log: https://pastebin.com/2SrmjAv9post-patch log is 1.8 MB — not uploaded

Portfile
Description: Binary data


Portfile.new
Description: Binary data


patch-ccx-build.diff
Description: Binary data


patch-spooles-make.inc.diff
Description: Binary data

Mark Brethenmark.bret...@gmail.com


On Aug 5, 2022, at 3:04 PM, Ryan Schmidt <ryandes...@macports.org> wrote:On Aug 5, 2022, at 14:32, Mark Brethen wrote:pre-build {    set cflags  "${configure.cflags} [get_canonical_archflags cc]"    set ldflags "${configure.ldflags} [get_canonical_archflags ld]"    # workaround for Rank mismatch between actual argument    set ver [regsub -all {[[:alpha:]]+} ${compilers.gcc_default} {}]    if { ${ver} >= 10 } {    set fflags "${configure.fflags} [get_canonical_archflags fc] -fallow-argument-mismatch"    } else {    set fflags "${configure.fflags} [get_canonical_archflags fc]"    }    set args    "CFLAGS=${cflags} FFLAGS=${fflags} LDFLAGS=${ldflags}"    build.args-append   ${args}    # Build serial spooles library    ui_info "Building spooles"    system -W ${workpath}/spooles.2.2 "${args} ${build.cmd} lib"    # Extend library with multi-threading (MT) subroutines    system -W ${workpath}/spooles.2.2/MT/src "${args} ${build.cmd} makeLib"}:info:build Building spooles:debug:build system -W /opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/spooles.2.2: CFLAGS=-Os -arch x86_64 FFLAGS=-Os -m64 -fallow-argument-mismatch LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-rpath,/opt/local/lib/libgcc -arch x86_64 /usr/bin/make lib:info:build sh: -arch: command not foundIt worked when I patched the makefile with the flags, but these should probably be passed at build. What did I miss?Quoting?set args    "CFLAGS=\"${cflags}\" FFLAGS=\"${fflags}\" LDFLAGS=\"${ldflags}\""

Re: include files for cgxCADTools

[Mark Brethen]

I don’t see these errors when building with macports-clang, only Apple’s clang.

Mark Brethen
mark.bret...@gmail.com



> On Aug 5, 2022, at 3:09 PM, Ryan Schmidt  wrote:
> 
> On Aug 4, 2022, at 13:19, Mark Brethen wrote:
> 
>> I’m seeing this error when generate all the header dependencies for 
>> FbdReader. This is confusing, which file has the error?
> 
> Error messages from several different files are being jumbled together due to 
> parallel building. You can make it less confusing by disabling parallel 
> building:
> 
> sudo port build use_parallel_build=no
> 

Re: SPOOLES MT routines

[Mark Brethen]

Need to build spooles library before CalculiX-ccx:

pre-build {
set cflags  "${configure.cflags} [get_canonical_archflags cc]"
set ldflags "${configure.ldflags} [get_canonical_archflags ld]"

# workaround for Rank mismatch between actual argument
set ver [regsub -all {[[:alpha:]]+} ${compilers.gcc_default} {}]

if { ${ver} >= 10 } {
set fflags "${configure.fflags} [get_canonical_archflags fc] 
-fallow-argument-mismatch"
} else {
set fflags "${configure.fflags} [get_canonical_archflags fc]"
}

set args"CFLAGS=${cflags} FFLAGS=${fflags} LDFLAGS=${ldflags}"

build.args-append   ${args}

# Build serial spooles library
ui_info "Building spooles"
system -W ${workpath}/spooles.2.2 "${args} ${build.cmd} lib"

# Extend library with multi-threading (MT) subroutines
system -W ${workpath}/spooles.2.2/MT/src "${args} ${build.cmd} makeLib"
}


:info:build Building spooles
:debug:build system -W 
/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/spooles.2.2:
 CFLAGS=-Os -arch x86_64 FFLAGS=-Os -m64 -fallow-argument-mismatch 
LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names 
-Wl,-rpath,/opt/local/lib/libgcc -arch x86_64 /usr/bin/make lib
:info:build sh: -arch: command not found

It worked when I patched the makefile with the flags, but these should probably 
be passed at build. What did I miss?

Mark Brethen
mark.bret...@gmail.com



> On Jul 30, 2022, at 11:40 AM, Chris Jones  wrote:
> 
> 
> 
>> On 30 Jul 2022, at 5:11 pm, Mark Brethen  wrote:
>> 
>> Now that I think about it, a subport would not work since the ccx makefile 
>> expects spooles.a in its workpath.
> 
> No, it would still be perfectly fine. Just make the subport a build 
> dependency, and then pre-build just copy the static library from wherever the 
> subport installs it, to where ever it needs to be in the work path. Ugly, it 
> would be better to just point the makefile at the installed lib, but if it 
> really has to have it in a certain place that can be accommodated.
> 
>> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Jul 30, 2022, at 11:01 AM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> For the basic installation of CalculiX-ccx the library spooles.a with the 
>>> single- and multi-threading (MT) routines of SPOOLES is required. Currently 
>>> I have defined a pre-build phase for spooles, although a subport could 
>>> work.There are some entries in its makefile that will need to be patched:
>>> 
>>> #
>>> #-
>>> #
>>> #  MPI install library
>>> #
>>> # MPI_INSTALL_DIR = 
>>>   MPI_INSTALL_DIR = /usr/local/mpich-1.0.13
>>> #
>>> #-
>>> #
>>> #  MPI library path
>>> #
>>> # for sgi
>>> #
>>> # MPI_LIB_PATH = 
>>> #
>>> # for solaris
>>> #
>>>   MPI_LIB_PATH = -L$(MPI_INSTALL_DIR)/lib/solaris/ch_p4
>>> #
>>> # for hp
>>> #
>>> # MPI_LIB_PATH = 
>>> #
>>> #-
>>> #
>>> #  MPI libraries 
>>> #
>>> # for solaris
>>> #
>>>   MPI_LIBS = $(MPI_LIB_PATH) -D_REENTRANT -lmpi -lsocket -lnsl -lthread
>>> #
>>> # for sgi
>>> #
>>> # MPI_LIBS = $(MPI_LIB_PATH) -lmpi -lpthread 
>>> #
>>> # for hp
>>> # MPI_LIBS = -lpthread
>>> # MPI_LIBS = $(MPI_LIB_PATH) -lpthread 
>>> #
>>> #-
>>> #
>>> #  MPI include path
>>> #
>>> # MPI_INCLUDE_DIR = 
>>>   MPI_INCLUDE_DIR = -I$(MPI_INSTALL_DIR)/include
>>> #
>>> #-
>>> 
>>> The spooles.a library source is packaged with ccx and static linked. Would 
>>> a build dependency on mpich suffice? 
>>> 
>>> Thanks,
>>> Mark
>>> 
>>> 
>>> 
>> 

Re: port notes

[Mark Brethen]

With a little experimentation I got it: 

notes \
"- To test for a successfull installation, execute the tool by typing 
\"cad2fbd\"" \
\n \
"-> some usage information should be displayed" \
\n \
"- The file result.fbd should be opened with the cgx parameter '-a' 
(auto)" \
\n \
"  cgx -a result.fbd"

Thanks,
Mark



> On Aug 5, 2022, at 12:06 PM, Joshua Root  wrote:
> 
> On 2022-8-6 02:30 , Mark Brethen wrote:
>> Is formatting (e.g. \n for newline) available in the notes section of a 
>> portfile? Or is it just one block of text.
> 
> This is pretty easy to test, no? Yes, it's an arbitrary string, newlines are 
> fine. Easiest to include them if you enclose the string in quotes.
> 
> - Josh

port notes

[Mark Brethen]

Is formatting (e.g. \n for newline) available in the notes section of a 
portfile? Or is it just one block of text.

Mark Brethen
mark.bret...@gmail.com

Re: include files for cgxCADTools

[Mark Brethen]

I have a stub that installs the documentation files and both subports but I get these warning messages. How should I fix?The following dependencies will be installed:  CadReader FbdReaderContinue? [Y/n]: --->  Fetching distfiles for CadReader--->  Verifying checksums for CadReader--->  Extracting CadReader--->  Applying patches to CadReader--->  Configuring CadReader--->  Building CadReader--->  Staging CadReader into destroot                    --->  Installing CadReader @1.1_0--->  Activating CadReader @1.1_0--->  Cleaning CadReader--->  Fetching distfiles for FbdReader--->  Verifying checksums for FbdReader--->  Extracting FbdReader--->  Applying patches to FbdReader--->  Configuring FbdReader--->  Building FbdReader--->  Staging FbdReader into destroot                    --->  Installing FbdReader @1.1_0--->  Activating FbdReader @1.1_0--->  Cleaning FbdReader--->  Fetching distfiles for cgxCADTools--->  Verifying checksums for cgxCADTools--->  Extracting cgxCADTools--->  Configuring cgxCADTools--->  Building cgxCADTools--->  Staging cgxCADTools into destrootWarning: violation by /libexecWarning: cgxCADTools violates the layout of the ports-filesystems!Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases!ports $ 

Portfile
Description: Binary data

Mark Brethenmark.bret...@gmail.com


On Aug 4, 2022, at 1:19 PM, Mark Brethen <mark.bret...@gmail.com> wrote:I’m seeing this error when generate all the header dependencies for FbdReader. This is confusing, which file has the error?:info:build In file included from Point.cpp:In file included from In file included from 1In file included from Element2d.cppFbdReader.cppSeqa.cpp:::1::info:build In file included from ../../FbdReader/inc/FbdReader.hxx::info:build :127::info:build 2In file included from ::info:build In file included from ../../FbdReader/inc/FbdReader.hxx:::info:build 27::info:build In file included from /opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxxIn file included from ../../FbdReader/inc/FbdReader.hxx../../FbdReader/inc/FbdReader.hxx:27:In file included from :::info:build 24In file included from ::info:build /opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx:/opt/local/include/opencascade/BRepLib_MakeWire.hxx:1762427/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx::info:build In file included from :::info:build 81: error/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx: :a space is required between consecutive right angle brackets (use '> >')24:info:build :24/opt/local/include/opencascade/BRepLib_MakeWire.hxx::info:build :176:/opt/local/include/opencascade/BRepLib_MakeWire.hxx81::176 :error81: :a space is required between consecutive right angle brackets (use '> >') :info:build error: a space is required between consecutive right angle brackets (use '> >'):info:build                                  NCollection_List>& theGrVL);:info:build                                                                                 ^~:info:build                                                                                 > >:info:build                                  NCollection_List>& theGrVL);                                 NCollection_List>& theGrVL);:info:build                                                                                 ^~::info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:176                                                                                ^~::info:build 81                                                                                > >::info:build  error: a space is required between consecutive right angle brackets (use '> >'):info:build                                                                                 > >:info:build                                  NCollection_List>& theGrVL);:info:build                                                                                 ^~:info:build                                                                                 > >:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:178:79: error: a space is required between consecutive right angle brackets (use '> >'):info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:  void CreateNewVertices(const NCollection_List>& theGrVL, 178:info:build :                                                                              ^~79:info:build :                                                                              > > :info:build error: a space is required between consecutive right angle brackets (use '> >'):info:build   void CreateNewVertices(const NCollection_List>& theGrVL, :info:build                                                                               ^~:info:build                    

Re: include files for cgxCADTools

[Mark Brethen]

I’m seeing this error when generate all the header dependencies for FbdReader. 
This is confusing, which file has the error?

:info:build In file included from Point.cpp:In file included from In file 
included from 1In file included from Element2d.cppFbdReader.cppSeqa.cpp:::1:
:info:build In file included from ../../FbdReader/inc/FbdReader.hxx:
:info:build :127:
:info:build 2In file included from :
:info:build In file included from ../../FbdReader/inc/FbdReader.hxx::
:info:build 27:
:info:build In file included from 
/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxxIn file included from 
../../FbdReader/inc/FbdReader.hxx../../FbdReader/inc/FbdReader.hxx:27:In file 
included from ::
:info:build 24In file included from :
:info:build 
/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx:/opt/local/include/opencascade/BRepLib_MakeWire.hxx:1762427/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx:
:info:build In file included from ::
:info:build 81: 
error/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx: :a space is 
required between consecutive right angle brackets (use '> >')24
:info:build :24/opt/local/include/opencascade/BRepLib_MakeWire.hxx:
:info:build :176:/opt/local/include/opencascade/BRepLib_MakeWire.hxx81::176 
:error81: :a space is required between consecutive right angle brackets (use '> 
>') 
:info:build error: a space is required between consecutive right angle brackets 
(use '> >')
:info:build  
NCollection_List>& theGrVL);
:info:build 
^~
:info:build 
> >
:info:build  
NCollection_List>& theGrVL);
 NCollection_List>& theGrVL);
:info:build 
^~:
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:176 
   ^~:
:info:build 81  
  > >:
:info:build  error: a space is required between consecutive right angle 
brackets (use '> >')
:info:build 
> >
:info:build  
NCollection_List>& theGrVL);
:info:build 
^~
:info:build 
> >
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:178:79: error: 
a space is required between consecutive right angle brackets (use '> >')
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:  void 
CreateNewVertices(const NCollection_List>& 
theGrVL, 178
:info:build :   
   ^~79
:info:build :   
   > > 
:info:build error: a space is required between consecutive right angle brackets 
(use '> >')
:info:build   void CreateNewVertices(const 
NCollection_List>& theGrVL, 
:info:build 
  ^~
:info:build 
  > >
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:178:79: error: 
a space is required between consecutive right angle brackets (use '> >')
:info:build   void CreateNewVertices(const 
NCollection_List>& theGrVL, 
:info:build 
  ^~
:info:build 
  > >
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:178:79: error: 
a space is required between consecutive right angle brackets (use '> >')
:info:build   void CreateNewVertices(const 
NCollection_List>& theGrVL, 
:info:build         
  ^~
:info:build     
  > >


Mark Brethen
mark.bret...@gmail.com



> On Aug 3, 2022, at 3:51 PM, Mark Brethen  wrote:
> 
> I solved the build issue I was having with CadReader. I now have a different 
> problem with FbdReader using opencascade 7.6:
> 
> :info:build  :../../FbdReader/inc/FbdReader.hxx:1074:: 74fatal error:: 
> 'GeomAdaptor_HCurve.hxx' file not found
> :info:build fatal error10:10: fatal error: 'GeomAdaptor_HCurve.hxx' file not 
> found
> :info:build : 'GeomAdaptor_HCurve.hxx' file not found

Re: include files for cgxCADTools

[Mark Brethen]

I solved the build issue I was having with CadReader. I now have a different 
problem with FbdReader using opencascade 7.6:

:info:build  :../../FbdReader/inc/FbdReader.hxx:1074:: 74fatal error:: 
'GeomAdaptor_HCurve.hxx' file not found
:info:build fatal error10:10: fatal error: 'GeomAdaptor_HCurve.hxx' file not 
found
:info:build : 'GeomAdaptor_HCurve.hxx' file not found
:info:build #include 
:info:build  ^~~~
:info:build #include 
:info:build  ^~~~
:info:build #include 
:info:build  ^~~~
:info:build  fatal error: 'GeomAdaptor_HCurve.hxx' file not found
:info:build #include 
:info:build  ^~~~

I found this in the release notes:
> Upgrade to OCCT 7.6.0
> 
>  <>Simplification of surface/curve adaptor
> 
> Interfaces Adaptor2d_Curve2d 
> <https://dev.opencascade.org/doc/refman/html/class_adaptor2d___curve2d.html>, 
> Adaptor3d_Curve 
> <https://dev.opencascade.org/doc/refman/html/class_adaptor3d___curve.html> 
> and Adaptor3d_Surface 
> <https://dev.opencascade.org/doc/refman/html/class_adaptor3d___surface.html> 
> now inherit Standard_Transient 
> <https://dev.opencascade.org/doc/refman/html/class_standard___transient.html> 
> and can be Handle-managed. No more necessary parallel hiererchy of classes 
> Adaptor2d_HCurve2d, Adaptor3d_HCurve and Adaptor3d_HSurface (generated from 
> generic templates by WOK) has been eliminated. Existing code using old Handle 
> classes should be updated to:
> 
> Rename occurrences of old names (remove H suffix); upgrade.bat could be used 
> for that purpose.
> Replace redundant calls to previously declared methods 
> .GetCurve2d()/.GetCurve()/.GetSurface() with the common operator->() syntax.
> Pay attention on code calling GetSurface()/GetCurve() methods of removed 
> handle classes. Such places should be replaced with Handle dereference.

I'll try patching the source. 

Thanks,
Mark
Mark Brethen
mark.bret...@gmail.com



> On Aug 3, 2022, at 10:18 AM, Mark Brethen  wrote:
> 
> It turns out the headers were their, I just didn’t have access due to a 
> permissions setting on the ‘inc’ directory itself. There are quite a few 
> undefined symbols listed in the build log.
> 
> https://pastebin.com/dh1Wx67C <https://pastebin.com/dh1Wx67C>
> 
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Aug 3, 2022, at 2:21 AM, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> I confirmed the bzip file contains the header files, however, the files are 
>> missing in the workpath. And there is nothing unusual in the log to explain 
>> what happened.
>> 
>> 
>> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Aug 2, 2022, at 6:20 PM, Robert Kennedy >> <mailto:am...@hotmail.com>> wrote:
>>> 
>>> Mark,
>>> 
>>> I was able to spend more time with your Makefile.  I corrected some typos.
>>> 
>>> Attached is the FINAL Makefile Rev 4 along with the patch file (that will 
>>> patch the original Makefile)
>>> 
>>> It should work well for your purposes.
>>> 
>>> If you are having trouble with the extraction phase, please send me a copy 
>>> of your Portfile and I will take a look.  It can be frustrating when things 
>>> do not unpack as expected.\\
>>> 
>>> Rob
>>> 
>>> From: Mark Brethen mailto:mark.bret...@gmail.com>>
>>> Sent: August 2, 2022 4:51 PM
>>> To: Robert Kennedy mailto:am...@hotmail.com>>
>>> Cc: MacPorts Developers >> <mailto:macports-dev@lists.macports.org>>
>>> Subject: Re: include files for cgxCADTools
>>>  
>>> I found the issue: There should be header files in 
>>> ‘${workpath}/cgxCadTools/CadReader/inc’ but for some reason the extract 
>>> phase is omitting them, i.e. the ‘inc’ directory is empty.
>>> 
>>> Why would it be doing this?
>>> 
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> 
>>> 
>>> 
>>>> On Aug 2, 2022, at 2:52 PM, Robert Kennedy >>> <mailto:am...@hotmail.com>> wrote:
>>>> 
>>>> I missed one.  You also need to change:
>>>> 
>>>> $(CC) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>>>> 
>>>> to
>>>> 
>>>> $(CCX) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>&

Re: include files for cgxCADTools

[Mark Brethen]

It turns out the headers were their, I just didn’t have access due to a 
permissions setting on the ‘inc’ directory itself. There are quite a few 
undefined symbols listed in the build log.

https://pastebin.com/dh1Wx67C <https://pastebin.com/dh1Wx67C>


Mark Brethen
mark.bret...@gmail.com



> On Aug 3, 2022, at 2:21 AM, Mark Brethen  wrote:
> 
> I confirmed the bzip file contains the header files, however, the files are 
> missing in the workpath. And there is nothing unusual in the log to explain 
> what happened.
> 
> 
> 
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Aug 2, 2022, at 6:20 PM, Robert Kennedy > <mailto:am...@hotmail.com>> wrote:
>> 
>> Mark,
>> 
>> I was able to spend more time with your Makefile.  I corrected some typos.
>> 
>> Attached is the FINAL Makefile Rev 4 along with the patch file (that will 
>> patch the original Makefile)
>> 
>> It should work well for your purposes.
>> 
>> If you are having trouble with the extraction phase, please send me a copy 
>> of your Portfile and I will take a look.  It can be frustrating when things 
>> do not unpack as expected.\\
>> 
>> Rob
>> 
>> From: Mark Brethen mailto:mark.bret...@gmail.com>>
>> Sent: August 2, 2022 4:51 PM
>> To: Robert Kennedy mailto:am...@hotmail.com>>
>> Cc: MacPorts Developers > <mailto:macports-dev@lists.macports.org>>
>> Subject: Re: include files for cgxCADTools
>>  
>> I found the issue: There should be header files in 
>> ‘${workpath}/cgxCadTools/CadReader/inc’ but for some reason the extract 
>> phase is omitting them, i.e. the ‘inc’ directory is empty.
>> 
>> Why would it be doing this?
>> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Aug 2, 2022, at 2:52 PM, Robert Kennedy >> <mailto:am...@hotmail.com>> wrote:
>>> 
>>> I missed one.  You also need to change:
>>> 
>>> $(CC) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>>> 
>>> to
>>> 
>>> $(CCX) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>>> 
>>> Rob
>>> From: Robert Kennedy mailto:am...@hotmail.com>>
>>> Sent: August 2, 2022 3:46 PM
>>> To: Mark Brethen mailto:mark.bret...@gmail.com>>
>>> Subject: Re: include files for cgxCADTools
>>>  
>>> Mark,
>>> 
>>> Since it is a C++ project (not a C project), I modified the Makefile 
>>> accordingly. See attached.
>>> 
>>> Please note that I added LDFLAGS = -stdlib=libc++ and added $LDFLAGS to the 
>>> Makefile target that does the linking.
>>> 
>>> This is needed so the code will link properly on older macs (like my old 
>>> Mac running Lion).
>>> 
>>> Alternatively, you could add the following to the Portfile:
>>> configure.ldflags-append"-stdlib=${configure.cxx_stdlib}"
>>> 
>>> Rob
>>> 
>>> From: Robert Kennedy mailto:am...@hotmail.com>>
>>> Sent: August 2, 2022 3:03 PM
>>> To: Mark Brethen mailto:mark.bret...@gmail.com>>
>>> Subject: Re: include files for cgxCADTools
>>>  
>>> I forgot to mention that I normally change all the CFLAGS and LDFLAGS as 
>>> follows:
>>> 
>>> CFLAGS = blah blah
>>> CFLAGS += blah blah
>>> 
>>> This will allow Macports to add its own flags.
>>> 
>>> You do not need to do that with CC or CCX.
>>> 
>>> Rob
>>> From: Robert Kennedy mailto:am...@hotmail.com>>
>>> Sent: August 2, 2022 3:00 PM
>>> To: Mark Brethen mailto:mark.bret...@gmail.com>>
>>> Subject: Re: include files for cgxCADTools
>>>  
>>> Mark,
>>> 
>>> I could not get the patch file to patch the Makefile.  So I manually 
>>> applied the patches.  And added my changes.  
>>> 
>>> Attached please find the FINAL Makefile and a patch file showing all the 
>>> diffs (including yours) from the original Makefile.  
>>> 
>>> I also did the following:
>>> Deleted all the dependencies, generated by makedepend below the "# DO NOT 
>>> DELETE THIS LINE -- make depend needs it" line.
>>> Added "macports" to .PHONY  (P.S.  PHONY targets provide rules that do not 
>>> directly build or link real binary objects.  They call on other targets 
>>> th

Re: include files for cgxCADTools

[Mark Brethen]

I confirmed the bzip file contains the header files, however, the files are missing in the workpath. And there is nothing unusual in the log to explain what happened.

main.log
Description: Binary data

Mark Brethenmark.bret...@gmail.com


On Aug 2, 2022, at 6:20 PM, Robert Kennedy <am...@hotmail.com> wrote:Mark,I was able to spend more time with your Makefile.  I corrected some typos.Attached is the FINAL Makefile Rev 4 along with the patch file (that will patch the original Makefile)It should work well for your purposes.If you are having trouble with the extraction phase, please send me a copy of your Portfile and I will take a look.  It can be frustrating when things do not unpack as expected.\\RobFrom: Mark Brethen <mark.bret...@gmail.com>Sent: August 2, 2022 4:51 PMTo: Robert Kennedy <am...@hotmail.com>Cc: MacPorts Developers <macports-dev@lists.macports.org>Subject: Re: include files for cgxCADTools I found the issue: There should be header files in ‘${workpath}/cgxCadTools/CadReader/inc’ but for some reason the extract phase is omitting them, i.e. the ‘inc’ directory is empty.Why would it be doing this?Mark Brethenmark.bret...@gmail.comOn Aug 2, 2022, at 2:52 PM, Robert Kennedy <am...@hotmail.com> wrote:I missed one.  You also need to change:$(CC) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)to$(CCX) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)RobFrom: Robert Kennedy <am...@hotmail.com>Sent: August 2, 2022 3:46 PMTo: Mark Brethen <mark.bret...@gmail.com>Subject: Re: include files for cgxCADTools Mark,Since it is a C++ project (not a C project), I modified the Makefile accordingly. See attached.Please note that I added LDFLAGS = -stdlib=libc++ and added $LDFLAGS to the Makefile target that does the linking.This is needed so the code will link properly on older macs (like my old Mac running Lion).Alternatively, you could add the following to the Portfile:configure.ldflags-append    "-stdlib=${configure.cxx_stdlib}"RobFrom: Robert Kennedy <am...@hotmail.com>Sent: August 2, 2022 3:03 PMTo: Mark Brethen <mark.bret...@gmail.com>Subject: Re: include files for cgxCADTools I forgot to mention that I normally change all the CFLAGS and LDFLAGS as follows:CFLAGS = blah blahCFLAGS += blah blahThis will allow Macports to add its own flags.You do not need to do that with CC or CCX.RobFrom: Robert Kennedy <am...@hotmail.com>Sent: August 2, 2022 3:00 PMTo: Mark Brethen <mark.bret...@gmail.com>Subject: Re: include files for cgxCADTools Mark,I could not get the patch file to patch the Makefile.  So I manually applied the patches.  And added my changes.  Attached please find the FINAL Makefile and a patch file showing all the diffs (including yours) from the original Makefile.  I also did the following:Deleted all the dependencies, generated by makedepend below the "# DO NOT DELETE THIS LINE -- make depend needs it" line.Added "macports" to .PHONY  (P.S.  PHONY targets provide rules that do not directly build or link real binary objects.  They call on other targets that build and link the actual code).Added the "macports" target:macports:   depend all  The rule for the Macports target is:macports:   depend all  When make macports is run, it will first run the "depend" target in the Makefile and generate all the header dependencies and then it will run the "all" target to build and link the code.Now you have two choices as far as Macports is concerned:Just use the Makefile as is and see if the code builds and links.  It likely will unless you are missing a header directory in $(INCLUDES).  ORAdd the following to the Portfile which causes makedepend to run (which will generate all those dependencies) before compiling and linking the code:depends_build       port:makedependbuild.target        macportsIf the Makefile is doing all the building and linking for your Project, you should probably also add the following to the Portfile:PortGroup           makefile 1.0I am working with a similar Makefile.  Both approaches above work for me.  Approach 1 runs a lot faster since it does not call on makedependto generate all those header dependencies (which can take some time for a large project).  And as mentioned in my previous posts to the Macports mailing list, the compiler typically does NOT need to know about these header dependencies to properly build and link the final binary product for the first time.  But the compiler does need to know the location of all the directories where all the non-system headers can be found so when it processes an #include in a source file, it can find the needed header.  The $(INCLUDES) does not need to contain any of the directories where the system headers are located since the compiler knows where they are.  And as you found out, the location of the system headers will change from MacOS to MacOS.I went with Approach 1 for my project

Re: include files for cgxCADTools

[Mark Brethen]

I found the issue: There should be header files in 
‘${workpath}/cgxCadTools/CadReader/inc’ but for some reason the extract phase 
is omitting them, i.e. the ‘inc’ directory is empty.

Why would it be doing this?


Mark Brethen
mark.bret...@gmail.com



> On Aug 2, 2022, at 2:52 PM, Robert Kennedy  wrote:
> 
> I missed one.  You also need to change:
> 
> $(CC) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
> 
> to
> 
> $(CCX) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
> 
> Rob
> From: Robert Kennedy 
> Sent: August 2, 2022 3:46 PM
> To: Mark Brethen 
> Subject: Re: include files for cgxCADTools
>  
> Mark,
> 
> Since it is a C++ project (not a C project), I modified the Makefile 
> accordingly. See attached.
> 
> Please note that I added LDFLAGS = -stdlib=libc++ and added $LDFLAGS to the 
> Makefile target that does the linking.
> 
> This is needed so the code will link properly on older macs (like my old Mac 
> running Lion).
> 
> Alternatively, you could add the following to the Portfile:
> configure.ldflags-append"-stdlib=${configure.cxx_stdlib}"
> 
> Rob
> 
> From: Robert Kennedy 
> Sent: August 2, 2022 3:03 PM
> To: Mark Brethen 
> Subject: Re: include files for cgxCADTools
>  
> I forgot to mention that I normally change all the CFLAGS and LDFLAGS as 
> follows:
> 
> CFLAGS = blah blah
> CFLAGS += blah blah
> 
> This will allow Macports to add its own flags.
> 
> You do not need to do that with CC or CCX.
> 
> Rob
> From: Robert Kennedy 
> Sent: August 2, 2022 3:00 PM
> To: Mark Brethen 
> Subject: Re: include files for cgxCADTools
>  
> Mark,
> 
> I could not get the patch file to patch the Makefile.  So I manually applied 
> the patches.  And added my changes.  
> 
> Attached please find the FINAL Makefile and a patch file showing all the 
> diffs (including yours) from the original Makefile.  
> 
> I also did the following:
> Deleted all the dependencies, generated by makedepend below the "# DO NOT 
> DELETE THIS LINE -- make depend needs it" line.
> Added "macports" to .PHONY  (P.S.  PHONY targets provide rules that do not 
> directly build or link real binary objects.  They call on other targets that 
> build and link the actual code).
> Added the "macports" target:
> macports:   depend all  
> The rule for the Macports target is:
> 
> macports:   depend all  
> 
> When make macports is run, it will first run the "depend" target in the 
> Makefile and generate all the header dependencies and then it will run the 
> "all" target to build and link the code.
> 
> Now you have two choices as far as Macports is concerned:
> Just use the Makefile as is and see if the code builds and links.  It likely 
> will unless you are missing a header directory in $(INCLUDES).  OR
> Add the following to the Portfile which causes makedepend to run (which will 
> generate all those dependencies) before compiling and linking the code:
> depends_build   port:makedepend
> build.targetmacports
> If the Makefile is doing all the building and linking for your Project, you 
> should probably also add the following to the Portfile:
> 
> PortGroup   makefile 1.0
> 
> I am working with a similar Makefile.  Both approaches above work for me.  
> Approach 1 runs a lot faster since it does not call on makedependto generate 
> all those header dependencies (which can take some time for a large project). 
>  And as mentioned in my previous posts to the Macports mailing list, the 
> compiler typically does NOT need to know about these header dependencies to 
> properly build and link the final binary product for the first time.  
> 
> But the compiler does need to know the location of all the directories where 
> all the non-system headers can be found so when it processes an #include in a 
> source file, it can find the needed header.  The $(INCLUDES) does not need to 
> contain any of the directories where the system headers are located since the 
> compiler knows where they are.  And as you found out, the location of the 
> system headers will change from MacOS to MacOS.
> 
> I went with Approach 1 for my project.
> 
> P.S.  It looks like the project is using autotools or cmake to generate the 
> Makefile so you likely need to patch the Makefile at the end of the configure 
> stage or before building.  The most important thing is deleting all those 
> header dependencies at the end of the Makefile.
> 
> Good Luck.
> 
> Rob
> 
> 
> From: Mark Brethen 
> Sent: August 2, 2022 1:34 PM
> To: Robert Kennedy 
> Subject: Re: include files for cgxCADTools
>  
> Rob,

Re: include files for cgxCADTools

[Mark Brethen]

I stripped those lines but there were some glitches in the build. First the 
Makefile only defines CC but the source is c++. 

:info:build /opt/local/include/opencascade/Standard_Handle.hxx:75:19: warning: 
rvalue references are a C++11 extension [-Wc++11-extensions]

Second, I’m missing an include somewhere.

:info:build   plotTopology() in CadReader.o
:info:build   std::__1::basic_stringstream, std::__1::allocator >::~basic_stringstream() 
in CadReader.o
:info:build   ...
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
:info:build make: *** [tmain] Error 1


https://pastebin.com/9xYCd74R <https://pastebin.com/9xYCd74R>



Mark Brethen
mark.bret...@gmail.com



> On Aug 2, 2022, at 12:34 PM, Mark Brethen  wrote:
> 
> Rob,
> 
> There is the line '.PHONY: depend clean' but 'make all’ only calls $(MAIN). 
> 
> 
> 
> Thanks,
> Mark
> 
> 
> 
>> On Aug 2, 2022, at 9:34 AM, Robert Kennedy > <mailto:am...@hotmail.com>> wrote:
>> 
>> Mark,
>> 
>> To be clear, I would first try patching the Makefile by deleting all the 
>> system header dependencies from the Makefile and then see if  Macports will 
>> build the project.  But make sure the Makefile lists the location of all the 
>> directories where the header files are located.  (I typically place them in 
>> $(INCLUDES)).  And make sure the rules contain $(INCLUDES).
>> 
>> You typically do not need to list the directories of the system header files 
>> because the compiler typically knows where they are (which as you know may 
>> change from MacOS to MacOS).
>> 
>> If you want to know why, keep reading
>> 
>> Typically "make" only needs to know the following to build the initial 
>> Project from scratch:
>>  The rules that define what source code files are needed to build each 
>> object and a rule for linking the object files and the location of the 
>> directories for the header files (e.g. main.h).  
>> e.g
>> 
>>      INCLUDES := -I./ 
>> 
>> .PHONY all
>> 
>>  all:  edit
>>    
>> edit:  main.o kdb.o
>> $(CC) $(LDFLAGS) -o main.o kbd.o
>> 
>>      main.o: main.c myfunc.c
>> $(CC) $(CFLAGS) $(INCLUDES) -c main.c myfunc.c
>> 
>> kbd.o: kbd.c
>> $(CC) $(CFLAGS) $(INCLUDES) -c kbd.c
>> 
>> 
>> In the example above, the directories of the header files are in listed in 
>> $(INCLUDES).   
>> 
>> You do not need to list the directories of the system header files in 
>> $(INCLUDES) because the compiler knows where they are (which as you know may 
>> change from MacOS to MacOS).
>> 
>> Ideally, if you know that a particular header is a dependency for an object, 
>> it is better to list it in the rule (e.g.  main.o:  main.c myfunc.c main.h)  
>> OR create a separate rule for the header dependency:
>> 
>> main.o:  main.h
>> 
>> But these header dependency rules are typically not needed to build the 
>> initial project from scratch!  These rules exist so "make" will only rebuild 
>> the minimum number of objects when a header file has changed.
>> 
>> E.g.  If I change header.h and then run "make all" again in the above 
>> example, make will only recompile main.o and then it will link main.o with 
>> the previously built kbd.o.  kbd.o does not need to be recompiled.  This 
>> saves time.  Great for development!
>> 
>> Macports does not do this.  It typically will rebuild the whole project from 
>> scratch. (i.e. build all the objects and then link them into the final 
>> product).
>> 
>> In my view, Macports was not designed for development but for building a 
>> finished project and making a binary package.  (i.e. package management)
>> 
>> If you are still having problems, please EMAIL me the Makefile and I will 
>> take a look.
>> 
>> RobK88
>> From: macports-dev > <mailto:macports-dev-boun...@lists.macports.org>> on behalf of Robert 
>> Kennedy mailto:am...@hotmail.com>>
>> Sent: August 2, 2022 8:10 AM
>> To: Mark Brethen mailto:mark.bret...@gmail.com>>; 
>> MacPorts Developers > <mailto:macports-dev@lists.macports.org>>
>> Subject: Re: include files for cgxCADTools
>>  
>> Mark,
>> 
>> I agree with Josh, these headers look like they were automatically generated 
>> using something like "make depends".  
>> 
>> When creating a Makefile, it is GOOD practice to include these lines as it 
>> w

Re: include files for cgxCADTools

[Mark Brethen]

I’ll ask the developer

Sent from my iPhone

> On Aug 1, 2022, at 4:53 PM, Joshua Root  wrote:
> 
> A lot of them aren't even standard headers; I believe the ones under bits/ 
> are glibc implementation details. I would suspect this part of the Makefile 
> was not hand-written but generated with one of the compiler's -M options. To 
> work correctly in that case, it would need to be regenerated for each new 
> system the software is built on.
> 
> - Josh
> 
>> On 2022-8-2 05:23 , Chris Jones wrote:
>> The makefile here is very poorly written. You should never directly 
>> reference standard headers like that…
>>>> On 1 Aug 2022, at 4:52 pm, Mark Brethen  wrote:
>>> 
>>> This Makefile has the following lines:
>>> 
>>> CadReader.o: /usr/include/stdlib.h /usr/include/bits/libc-header-start.h
>>> CadReader.o: /usr/include/features.h /usr/include/stdc-predef.h
>>> CadReader.o: /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h
>>> CadReader.o: /usr/include/bits/long-double.h /usr/include/gnu/stubs.h
>>> CadReader.o: /usr/include/bits/waitflags.h /usr/include/bits/waitstatus.h
>>> CadReader.o: /usr/include/bits/floatn.h /usr/include/sys/types.h
>>> CadReader.o: /usr/include/bits/types.h /usr/include/bits/typesizes.h
>>> CadReader.o: /usr/include/bits/types/clock_t.h
>>> CadReader.o: /usr/include/bits/types/clockid_t.h
>>> CadReader.o: /usr/include/bits/types/time_t.h
>>> CadReader.o: /usr/include/bits/types/timer_t.h
>>> CadReader.o: /usr/include/bits/stdint-intn.h /usr/include/endian.h
>>> CadReader.o: /usr/include/bits/endian.h /usr/include/bits/byteswap.h
>>> CadReader.o: /usr/include/bits/byteswap-16.h
>>> CadReader.o: /usr/include/bits/uintn-identity.h /usr/include/sys/select.h
>>> CadReader.o: /usr/include/bits/select.h /usr/include/bits/types/sigset_t.h
>>> CadReader.o: /usr/include/bits/types/__sigset_t.h
>>> CadReader.o: /usr/include/bits/types/struct_timeval.h
>>> CadReader.o: /usr/include/bits/types/struct_timespec.h
>>> CadReader.o: /usr/include/sys/sysmacros.h /usr/include/bits/sysmacros.h
>>> CadReader.o: /usr/include/bits/pthreadtypes.h
>>> CadReader.o: /usr/include/bits/thread-shared-types.h
>>> CadReader.o: /usr/include/bits/pthreadtypes-arch.h /usr/include/alloca.h
>>> CadReader.o: /usr/include/bits/stdlib-float.h
>>> 
>>> /usr/include doesn’t exist on Big Sure (I assume its deprecated?) however, 
>>> they can be found at
>>> 
>>> ~ $ xcrun --sdk macosx --show-sdk-path
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk
>>> 
>>> although I don’t see a ‘bits’ subdirectory. Has it been relocated?
>>> 
>>> Thanks,
>>> Mark
>>> 
>>> 
>>> 
> 

Re: include files for cgxCADTools

[Mark Brethen]

The top of the makefile looks normal enough, then it lists a boat-load of 
headers. I guess I won’t spend any more time on it.



Mark Brethen
mark.bret...@gmail.com



> On Aug 1, 2022, at 2:23 PM, Chris Jones  wrote:
> 
> 
> The makefile here is very poorly written. You should never directly reference 
> standard headers like that…
> 
>> On 1 Aug 2022, at 4:52 pm, Mark Brethen  wrote:
>> 
>> This Makefile has the following lines:
>> 
>> CadReader.o: /usr/include/stdlib.h /usr/include/bits/libc-header-start.h
>> CadReader.o: /usr/include/features.h /usr/include/stdc-predef.h
>> CadReader.o: /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h
>> CadReader.o: /usr/include/bits/long-double.h /usr/include/gnu/stubs.h
>> CadReader.o: /usr/include/bits/waitflags.h /usr/include/bits/waitstatus.h
>> CadReader.o: /usr/include/bits/floatn.h /usr/include/sys/types.h
>> CadReader.o: /usr/include/bits/types.h /usr/include/bits/typesizes.h
>> CadReader.o: /usr/include/bits/types/clock_t.h
>> CadReader.o: /usr/include/bits/types/clockid_t.h
>> CadReader.o: /usr/include/bits/types/time_t.h
>> CadReader.o: /usr/include/bits/types/timer_t.h
>> CadReader.o: /usr/include/bits/stdint-intn.h /usr/include/endian.h
>> CadReader.o: /usr/include/bits/endian.h /usr/include/bits/byteswap.h
>> CadReader.o: /usr/include/bits/byteswap-16.h
>> CadReader.o: /usr/include/bits/uintn-identity.h /usr/include/sys/select.h
>> CadReader.o: /usr/include/bits/select.h /usr/include/bits/types/sigset_t.h
>> CadReader.o: /usr/include/bits/types/__sigset_t.h
>> CadReader.o: /usr/include/bits/types/struct_timeval.h
>> CadReader.o: /usr/include/bits/types/struct_timespec.h
>> CadReader.o: /usr/include/sys/sysmacros.h /usr/include/bits/sysmacros.h
>> CadReader.o: /usr/include/bits/pthreadtypes.h
>> CadReader.o: /usr/include/bits/thread-shared-types.h
>> CadReader.o: /usr/include/bits/pthreadtypes-arch.h /usr/include/alloca.h
>> CadReader.o: /usr/include/bits/stdlib-float.h
>> 
>> /usr/include doesn’t exist on Big Sure (I assume its deprecated?) however, 
>> they can be found at
>> 
>> ~ $ xcrun --sdk macosx --show-sdk-path
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk
>> 
>> although I don’t see a ‘bits’ subdirectory. Has it been relocated?
>> 
>> Thanks,
>> Mark
>> 
>> 
>> 

include files for cgxCADTools

[Mark Brethen]

This Makefile has the following lines:

CadReader.o: /usr/include/stdlib.h /usr/include/bits/libc-header-start.h
CadReader.o: /usr/include/features.h /usr/include/stdc-predef.h
CadReader.o: /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h
CadReader.o: /usr/include/bits/long-double.h /usr/include/gnu/stubs.h
CadReader.o: /usr/include/bits/waitflags.h /usr/include/bits/waitstatus.h
CadReader.o: /usr/include/bits/floatn.h /usr/include/sys/types.h
CadReader.o: /usr/include/bits/types.h /usr/include/bits/typesizes.h
CadReader.o: /usr/include/bits/types/clock_t.h
CadReader.o: /usr/include/bits/types/clockid_t.h
CadReader.o: /usr/include/bits/types/time_t.h
CadReader.o: /usr/include/bits/types/timer_t.h
CadReader.o: /usr/include/bits/stdint-intn.h /usr/include/endian.h
CadReader.o: /usr/include/bits/endian.h /usr/include/bits/byteswap.h
CadReader.o: /usr/include/bits/byteswap-16.h
CadReader.o: /usr/include/bits/uintn-identity.h /usr/include/sys/select.h
CadReader.o: /usr/include/bits/select.h /usr/include/bits/types/sigset_t.h
CadReader.o: /usr/include/bits/types/__sigset_t.h
CadReader.o: /usr/include/bits/types/struct_timeval.h
CadReader.o: /usr/include/bits/types/struct_timespec.h
CadReader.o: /usr/include/sys/sysmacros.h /usr/include/bits/sysmacros.h
CadReader.o: /usr/include/bits/pthreadtypes.h
CadReader.o: /usr/include/bits/thread-shared-types.h
CadReader.o: /usr/include/bits/pthreadtypes-arch.h /usr/include/alloca.h
CadReader.o: /usr/include/bits/stdlib-float.h

/usr/include doesn’t exist on Big Sure (I assume its deprecated?) however, they 
can be found at

~ $ xcrun --sdk macosx --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk

although I don’t see a ‘bits’ subdirectory. Has it been relocated?

Thanks,
Mark

Re: SPOOLES MT routines

[Mark Brethen]

Now that I think about it, a subport would not work since the ccx makefile 
expects spooles.a in its workpath.


Mark Brethen
mark.bret...@gmail.com



> On Jul 30, 2022, at 11:01 AM, Mark Brethen  wrote:
> 
> For the basic installation of CalculiX-ccx the library spooles.a with the 
> single- and multi-threading (MT) routines of SPOOLES is required. Currently I 
> have defined a pre-build phase for spooles, although a subport could 
> work.There are some entries in its makefile that will need to be patched:
> 
> #
> #-
> #
> #  MPI install library
> #
> # MPI_INSTALL_DIR = 
>   MPI_INSTALL_DIR = /usr/local/mpich-1.0.13
> #
> #-
> #
> #  MPI library path
> #
> # for sgi
> #
> # MPI_LIB_PATH = 
> #
> # for solaris
> #
>   MPI_LIB_PATH = -L$(MPI_INSTALL_DIR)/lib/solaris/ch_p4
> #
> # for hp
> #
> # MPI_LIB_PATH = 
> #
> #-
> #
> #  MPI libraries 
> #
> # for solaris
> #
>   MPI_LIBS = $(MPI_LIB_PATH) -D_REENTRANT -lmpi -lsocket -lnsl -lthread
> #
> # for sgi
> #
> # MPI_LIBS = $(MPI_LIB_PATH) -lmpi -lpthread 
> #
> # for hp
> # MPI_LIBS = -lpthread
> # MPI_LIBS = $(MPI_LIB_PATH) -lpthread 
> #
> #-
> #
> #  MPI include path
> #
> # MPI_INCLUDE_DIR = 
>   MPI_INCLUDE_DIR = -I$(MPI_INSTALL_DIR)/include
> #
> #-
> 
> The spooles.a library source is packaged with ccx and static linked. Would a 
> build dependency on mpich suffice? 
> 
> Thanks,
> Mark
> 
> 
> 

SPOOLES MT routines

[Mark Brethen]

For the basic installation of CalculiX-ccx the library spooles.a with the 
single- and multi-threading (MT) routines of SPOOLES is required. Currently I 
have defined a pre-build phase for spooles, although a subport could work.There 
are some entries in its makefile that will need to be patched:

#
#-
#
#  MPI install library
#
# MPI_INSTALL_DIR = 
  MPI_INSTALL_DIR = /usr/local/mpich-1.0.13
#
#-
#
#  MPI library path
#
# for sgi
#
# MPI_LIB_PATH = 
#
# for solaris
#
  MPI_LIB_PATH = -L$(MPI_INSTALL_DIR)/lib/solaris/ch_p4
#
# for hp
#
# MPI_LIB_PATH = 
#
#-
#
#  MPI libraries 
#
# for solaris
#
  MPI_LIBS = $(MPI_LIB_PATH) -D_REENTRANT -lmpi -lsocket -lnsl -lthread
#
# for sgi
#
# MPI_LIBS = $(MPI_LIB_PATH) -lmpi -lpthread 
#
# for hp
# MPI_LIBS = -lpthread
# MPI_LIBS = $(MPI_LIB_PATH) -lpthread 
#
#-
#
#  MPI include path
#
# MPI_INCLUDE_DIR = 
  MPI_INCLUDE_DIR = -I$(MPI_INSTALL_DIR)/include
#
#-

The spooles.a library source is packaged with ccx and static linked. Would a 
build dependency on mpich suffice? 

Thanks,
Mark

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

cgx.h already had a call to extUtil.h, so I replaced it in parser.c. Build 
completed without further errors.

Thanks,
Mark



> On Jul 28, 2022, at 11:22 AM, Chris Jones  wrote:
> 
> 
> 
>> On 28 Jul 2022, at 5:21 pm, Chris Jones  wrote:
>> 
>> 
>> 
>> 
>>> On 28 Jul 2022, at 5:17 pm, Mark Brethen  wrote:
>>> 
>>> 
>>> ~ $ cd 
>>> /opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src
>>> src $ sudo ack DrawCommandLine
>>> Password:
>>> cgx.c
>>> 5009:  DrawCommandLine(keystroke, strlen(keystroke)+curshft);
>>> 5071:DrawCommandLine(keystroke, strlen(keystroke)+curshft);
>>> 5799:  DrawCommandLine(0,0);
>>> 5803:void DrawCommandLine(char *string, int curpos)
>>> 5807:  printf(" in DrawCommandLine\n");
>>> 5874:DrawCommandLine(0,0);
>>> 
>>> cgx.h
>>> 588:void DrawCommandLine(char *string, int curpos);
>>> 
>>> parser.c
>>> 85:DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
>>> 
>>> 
>>> cgx.h has 'void DrawCommandLine(char *string, int curpos);’ 
>>> 
>>> cgx.c has '#include ’
>>> 
>>> parser.c has '#include ’ only
>>> 
>>> should I add '#include ’ to parser.c or add 'void 
>>> DrawCommandLine(char *string, int curpos);’  to extUtil.h?
>> 
>> Based on the above, no, but instead add it to parser.c
> 
> Apologies, misread your reply. I would say yes to the first part.
> 
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> 
>>> 
>>> 
>>>> On Jul 27, 2022, at 8:41 PM, Joshua Root >>> <mailto:j...@macports.org>> wrote:
>>>> 
>>>> There's only one -Wimplicit-function-declaration warning in the log, so it 
>>>> doesn't look like there's a lot that needs fixing. Just say yes to 
>>>> function prototypes. :)
>>>> 
>>>> - Josh

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

~ $ cd 
/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src
src $ sudo ack DrawCommandLine
Password:
cgx.c
5009:  DrawCommandLine(keystroke, strlen(keystroke)+curshft);
5071:DrawCommandLine(keystroke, strlen(keystroke)+curshft);
5799:  DrawCommandLine(0,0);
5803:void DrawCommandLine(char *string, int curpos)
5807:  printf(" in DrawCommandLine\n");
5874:DrawCommandLine(0,0);

cgx.h
588:void DrawCommandLine(char *string, int curpos);

parser.c
85:DrawCommandLine(keystroke, strlen(keystroke)+*curshft);


cgx.h has 'void DrawCommandLine(char *string, int curpos);’ 

cgx.c has '#include ’

parser.c has '#include ’ only

should I add '#include ’ to parser.c or add 'void DrawCommandLine(char 
*string, int curpos);’  to extUtil.h?

Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 8:41 PM, Joshua Root  wrote:
> 
> There's only one -Wimplicit-function-declaration warning in the log, so it 
> doesn't look like there's a lot that needs fixing. Just say yes to function 
> prototypes. :)
> 
> - Josh

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

:debug:configure Preferred compilers: clang macports-clang-14 macports-clang-13 macports-clang-12 macports-clang-11 macports-clang-10 macports-clang-9.0It does build with macports-clang*: https://pastebin.com/vmKFHatf

Portfile
Description: Binary data

Thanks,Mark


On Jul 27, 2022, at 10:39 AM, Mark Brethen <mark.bret...@gmail.com> wrote:I suppose it dies on the first error… there could be others downstream, which turns into an exhaustive cycle.
Mark Brethenmark.bret...@gmail.com


On Jul 27, 2022, at 9:58 AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:patch the code to remove the improper implicit declaration

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

I suppose it dies on the first error… there could be others downstream, which 
turns into an exhaustive cycle.


Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 9:58 AM, Chris Jones  wrote:
> 
> patch the code to remove the improper implicit declaration

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

Clang12 w/-std=c99: 
:info:build parser.c:85:5: warning: implicit declaration of function 
'DrawCommandLine' is invalid in C99 [-Wimplicit-function-declaration]

Clang14 w/-std=c89:
:info:build /usr/bin/clang -std=c89 -Os -arch x86_64 -I./ -I/opt/local/include 
-I/opt/local/include/GL -I../../libSNL/src -I../../glut-3.5/src   -c -o 
parser.o parser.c
:info:build parser.c:85:5: error: implicit declaration of function 
'DrawCommandLine' [-Werror,-Wimplicit-function-declaration]
:info:build DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
:info:build ^
:info:build 1 error generated.
:info:build make: *** [parser.o] Error 1



Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 7:23 AM, Chris Jones  wrote:
> 
> Latest clang compilers probably default to a 'recent' c standard, unless 
> otherwise told. If the code in question only builds using the less 
> restrictive older standards, then the builds should specify this using 
> -std=c89 for instance..

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

I tried setting CFLAGS in he pre-build before, which negates the includes in 
the patch, and the build fails.

:info:build Executing:  cd 
"/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX/CalculiX/work/CalculiX/cgx_2.18/src"
 && /usr/bin/make -j4 -w CXX=/usr/bin/clang++ CC=/usr/bin/clang CFLAGS="-Os 
-arch x86_64" LDFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -arch 
x86_64" 

:info:build In file included from adjustMidsideNode.c:31:
:info:build In file included from ./cgx.h:25:
:info:build ./extUtil.h:40:12: fatal error: 'GL/glut_cgx.h' file not found
:info:build   #include 
:info:build^~~

Either I add those to the patch or put everything in the pre-build.

Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 7:52 AM, Chris Jones  wrote:
> 
> Then you should at least set these as well pre-build
> 
> CFLAGS="${configure.cflags} [get_canonical_archflags cc]"
> 
> LDFLAGS="${configure.ldflags} [get_canonical_archflags ld]"
> 
> The info in CXXFLAGS should also be passed in some way as well
> 
> CXXFLAGS="${configure.cxxflags} [get_canonical_archflags cxx]"
> 
> If the makefile currently does not use this, it should be added.

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

As you can see in the makefile (post-patch), it only makes use of CFLAGS and LDFLAGS.

Makefile
Description: Binary data

Mark Brethenmark.bret...@gmail.com


On Jul 27, 2022, at 7:41 AM, Joshua Root  wrote:It's also not passing in the MacPorts CFLAGS, CXXFLAGS, and LDFLAGS. If it's a handcrafted Makefile, it may need some modification to even accept and use those.

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

As the source does not use configure, I pass the compiler args:

pre-build {
build.args-appendCXX=${configure.cxx} \
 CC=${configure.cc}
}

For reasons I don’t understand, If I don’t put it in a pre-build override it’s 
ignored.

Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 7:30 AM, Chris Jones  wrote:
> 
> 
> 
> On 27/07/2022 1:14 pm, Mark Brethen wrote:
>> log for gcc build: https://pastebin.com/qbmWHm1M 
>> <https://pastebin.com/qbmWHm1M>
> 
> above shows gcc is indeed being used to build c++ code
> 
> :info:build /opt/local/bin/g++-mp-12  userFunction.o  AsplitA.o AsplitL.o 
> adjustMidsideNode.o compareStrings.o XFunktions.o badelems.o bodyMesh2.o 
> bsort.o bsortf.o bsorti.o calcNormalen.o calcPrinc.o calcPvector.o 
> calcWeight.o checkIfNumber.o cgx.o compare.o copyEntity.o corrad.o dataGeo.o 
> dataMesh.o defineEntity.o dispLists.o elemChecker.o extFunktions.o extGL.o 
> fillBody2.o frecord.o foamFaces.o gl3grades.o getGeoDataTria.o graph.o 
> ifind.o iinsert.o improveBadTr3.o improveMesh.o iniMeshData.o intpol.o 
> intpol2.o intpol3.o iremove.o linelength.o m_copy.o m_sub.o mergEntity.o 
> mesh2d.o meshSet.o meshSurf.o messages.o near3d.o normdist.o nurbl2seq.o 
> orient.o p_angle.o parser.o pickFunktions.o plotFunktions.o readAnsysList.o 
> readEdges.o readfrd.o readFoam.o readStdCmap.o readStl.o readccx.o readDuns.o 
> readNastran.o readNG.o readTG.o readIsaac.o readstep.o readWf.o rectcyl.o 
> renumberfrd.o selectDisplayFaces.o sendMpc.o sendSet.o setFunktions.o 
> shapeFunctions.o spline.o splitElementsToTets.o stof.o stoi.o stopClock.o 
> stos.o strfind.o strsplt.o sins.o surfMesh2.o sword.o trackball.o v_distA.o 
> v_rec2cyl.o v_add.o v_angle.o v_angle_ref.o v_betrag.o v_matmult.o v_norm.o 
> v_prod.o v_result.o v_scal.o v_rot.o v_sprod.o m_prod.o m_prodtr.o 
> write2aba.o write2ansys.o write2aster.o write2darwin.o write2dolfyn.o 
> write2isaac.o write2duns.o write2frd.o write2foam.o write2nas.o 
> write2samcef.o write2tochnog.o writefbd.o writebp.o contact.o 
> makeTriFromElems.o uselibSNL.cpp generateTet.cpp ../../libSNL/src/*.cpp  -O2 
> -Wall -Wno-narrowing -I./ -I/opt/local/include -I/opt/local/include/GL 
> -I../../libSNL/src -I../../glut-3.5/src  -L/opt/local/lib -lGL -lGLU -lglut 
> -lX11 -lXi -lXmu -lXext -lXt -lSM -lICE -lm -lpthread -o  cgx
> 
> this is not really supported. Your time would be better spent fixing the 
> issues with using clang++ to build.
> 
> Chris
> 
>> log for clang12 build: https://pastebin.com/4WG7VsfA 
>> <https://pastebin.com/4WG7VsfA>
>> clang14 is more restrictive on C implementation:
>> :info:build /usr/bin/clang -O2 -Wall -Wno-narrowing -I./ 
>> -I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src 
>> -I../../glut-3.5/src-c -o parser.o parser.c
>> :info:build parser.c:85:5: error: implicit declaration of function 
>> 'DrawCommandLine' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>> :info:build DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
>> :info:build ^
>> :info:build 1 error generated.
>> :info:build make: *** [parser.o] Error 1
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> On Jul 27, 2022, at 3:49 AM, Chris Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> 
>>> Please post a complete, clean, build log for the port in question.
>>> 
>>> In general GCC should not be used to build c++ (*) as doing so leads to 
>>> these c++ runtime mis-matches. You should use clang for c++ (and c as well, 
>>> although there is no runtime issues there).
>>> 
>>> cheers Chris
>>> 
>>> * The latest GCC versions now actually support building against libc++, the 
>>> clang runtime, which would make this possible in theory. It needs support 
>>> in base though (https://github.com/macports/macports-base/pull/275 
>>> <https://github.com/macports/macports-base/pull/275>) so cannot be used 
>>> until that is available.
>>> 
>>> On 27/07/2022 1:15 am, Mark Brethen wrote:
>>>> Installing CalculiX with a clang variant is successful, however when 
>>>> selecting a gcc variant:
>>>> --->  Scanning binaries for linking errors
>>>> --->  No broken files found.
>>>> CalculiX is using libstdc++ (this installation is configured to use libc++)
>>>> --->  Found 1 broken port, determining rebuild order
>>>> You can always run 'port rev-upgrade' again to fix errors.
>>>> The following ports will be rebuilt: CalculiX @2.18+docs+examples+gcc12
>>>> Continue? [Y/n]:
>>>> Choosing ‘Y’ puts it into and endless re-install. Adding 
>>>> 'configure.cxx_stdlib macports-libstdc++’ seems to fix things.
>>>> 1. What is causing this?
>>>> 2. Should the compilers group be removed and stick with clang?
>>>> 3. What changes to the portfile would need to made to permit either 
>>>> compiler variant?
>>>> Thanks,
>>>> Mark

Re: CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

log for gcc build: https://pastebin.com/qbmWHm1M <https://pastebin.com/qbmWHm1M>

log for clang12 build: https://pastebin.com/4WG7VsfA 
<https://pastebin.com/4WG7VsfA>

clang14 is more restrictive on C implementation:

:info:build /usr/bin/clang -O2 -Wall -Wno-narrowing -I./ -I/opt/local/include 
-I/opt/local/include/GL -I../../libSNL/src -I../../glut-3.5/src-c -o 
parser.o parser.c
:info:build parser.c:85:5: error: implicit declaration of function 
'DrawCommandLine' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
:info:build DrawCommandLine(keystroke, strlen(keystroke)+*curshft);
:info:build ^
:info:build 1 error generated.
:info:build make: *** [parser.o] Error 1

Mark Brethen
mark.bret...@gmail.com



> On Jul 27, 2022, at 3:49 AM, Chris Jones  wrote:
> 
> 
> Please post a complete, clean, build log for the port in question.
> 
> In general GCC should not be used to build c++ (*) as doing so leads to these 
> c++ runtime mis-matches. You should use clang for c++ (and c as well, 
> although there is no runtime issues there).
> 
> cheers Chris
> 
> * The latest GCC versions now actually support building against libc++, the 
> clang runtime, which would make this possible in theory. It needs support in 
> base though (https://github.com/macports/macports-base/pull/275) so cannot be 
> used until that is available.
> 
> On 27/07/2022 1:15 am, Mark Brethen wrote:
>> Installing CalculiX with a clang variant is successful, however when 
>> selecting a gcc variant:
>> --->  Scanning binaries for linking errors
>> --->  No broken files found.
>> CalculiX is using libstdc++ (this installation is configured to use libc++)
>> --->  Found 1 broken port, determining rebuild order
>> You can always run 'port rev-upgrade' again to fix errors.
>> The following ports will be rebuilt: CalculiX @2.18+docs+examples+gcc12
>> Continue? [Y/n]:
>> Choosing ‘Y’ puts it into and endless re-install. Adding 
>> 'configure.cxx_stdlib macports-libstdc++’ seems to fix things.
>> 1. What is causing this?
>> 2. Should the compilers group be removed and stick with clang?
>> 3. What changes to the portfile would need to made to permit either compiler 
>> variant?
>> Thanks,
>> Mark

CalculiX is using libstdc++ (this installation is configured to use libc++)

[Mark Brethen]

Installing CalculiX with a clang variant is successful, however when selecting a gcc variant:--->  Scanning binaries for linking errors--->  No broken files found.CalculiX is using libstdc++ (this installation is configured to use libc++)--->  Found 1 broken port, determining rebuild orderYou can always run 'port rev-upgrade' again to fix errors.The following ports will be rebuilt: CalculiX @2.18+docs+examples+gcc12Continue? [Y/n]:Choosing ‘Y’ puts it into and endless re-install. Adding 'configure.cxx_stdlib macports-libstdc++’ seems to fix things.1. What is causing this?2. Should the compilers group be removed and stick with clang?3. What changes to the portfile would need to made to permit either compiler variant?

Portfile
Description: Binary data

Thanks,Mark

Re: CalculiX build error using clang

[Mark Brethen]

Thanks for the feedback everyone. I also created patches to replace sem_init and sem_destory instances and will be forwarding them to the developer. I didn’t see any warnings or errors but it wouldn’t hurt to give them another look.

patch-cgx_2_18-src-cgx_c.diff
Description: Binary data


patch-cgx_2_18-src-pickFunktions_c.diff
Description: Binary data


patch-cgx_2_18-src-setFunktions_c.diff
Description: Binary data
Thanks,
Mark


On Jul 26, 2022, at 3:12 PM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:On 26 Jul 2022, at 8:59 pm, Mark Brethen <mark.bret...@gmail.com> wrote:Only 1 instance found:src $ sudo ack moveLineEndPointPassword:cgx.h941:void moveLineEndPoint(int lineNr, int pntNr, double llength);pickFunktions.c4583:void moveLineEndPoint(int lineNr, int pntNr, double llength)4800:    moveLineEndPoint( lineNr, px, pickbuf);int createLine( char *apnt, int flag ){  int i,j=0, nr=-1;  static int px, p1, p2, pc=-1, pm=-1, ps[1000], seq=1;  double P1[3], P2[3], Pc[3], Pm[3], pbuf[3], u;  char name[MAX_LINE_LENGTH], setname[MAX_LINE_LENGTH];  double pmp1[3], pmp2[3], pmp1_2[3], pmp2_2[3], nm12[3];  double eva[3], evb[3], va[3], vb[3], p0p1_2[3], p0p2_2[3], vr[3];…  else if (flag==5)  {    if(lineNr==-1)    {      printf("ERROR: select line with key l first\n");      return(-1);    }    px  = getPntNr( apnt );    moveLineEndPoint( lineNr, px, pickbuf);    for (i=0; il; i++) repLine(i);    lineNr=-1;  }  return (nr);}It looks like the return(-1) is needed?Nope, the opposite. That one call to the method ignores the return value. So the void signature is valid and the return statement should just omit the value. I.e.return;ChrisMark Brethenmark.bret...@gmail.comOn Jul 26, 2022, at 2:18 PM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:On 26 Jul 2022, at 6:27 pm, Mark Brethen <mark.bret...@gmail.com> wrote:would a ‘return;’ instead of ‘return(-1);’ suffice>?Depends on what the intentions of the developers are here…If callees of the function expect a return value, then the method should instead be updated to declare a return type, and then to always return something (usually 0 for successful calls). Mark Brethenmark.bret...@gmail.comOn Jul 26, 2022, at 11:51 AM, Christopher Jones <jon...@hep.phy.cam.ac.uk> wrote:clang is correct in this case, gcc is being sloppy. Basically you cannot return a value, from a function declared as void… fairly basic stuff really..On 26 Jul 2022, at 5:34 pm, Mark Brethen <mark.bret...@gmail.com> wrote:I’m seeing this build error when using clang (gcc doesn’t complain):info:build /opt/local/bin/clang-mp-14 -O2 -Wall -Wno-narrowing -I./ -I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src -I../../glut-3.5/src    -c -o pickFunktions.o pickFunktions.c:info:build pickFunktions.c:4599:7: error: void function 'moveLineEndPoint' should not return a value [-Wreturn-type]:info:build       return(-1);:info:build       ^     code snippet below: void moveLineEndPoint(int lineNr, int pntNr, double llength){  int p1,p2, flag=0;  double P1[3], P2[3], u, eva[3], va[3], p0p1_2[3];    p1=line[lineNr].p1;    p2=line[lineNr].p2;    /* determine which side of the line has to be moved */    if(pntNr==p1) flag=-1;    else if(pntNr==p2) flag=1;    else    {      printf("ERROR: selected point:%s is no line endpoint\n", point[pntNr].name);      return(-1);    }    u=flag*llength;    u/=scale->w;    /* calc direction */    if(line[lineNr].typ=='s')    {      if(flag==-1) p2=set[line[lineNr].trk].pnt[1];      else  p1=set[line[lineNr].trk].pnt[set[line[lineNr].trk].anz_p-2];    }    P1[0]=point[p1].px;    P1[1]=point[p1].py;    P1[2]=point[p1].pz;    P2[0]=point[p2].px;    P2[1]=point[p2].py;    P2[2]=point[p2].pz;    v_result( P1, P2, p0p1_2);    v_norm(p0p1_2,eva);    v_scal(,eva, va);    point[pntNr].px+=va[0];    point[pntNr].py+=va[1];    point[pntNr].pz+=va[2];    printf("moved by dxyz= %lf %lf %lf\n",      (va[0]* scale->w),      (va[1]* scale->w),      (va[2]* scale->w));}I do not code in C, so I’ll pass this up to the developer. How should this be patched?Thanks,Mark

Re: CalculiX build error using clang

[Mark Brethen]

Only 1 instance found:

src $ sudo ack moveLineEndPoint
Password:
cgx.h
941:void moveLineEndPoint(int lineNr, int pntNr, double llength);

pickFunktions.c
4583:void moveLineEndPoint(int lineNr, int pntNr, double llength)
4800:moveLineEndPoint( lineNr, px, pickbuf);



int createLine( char *apnt, int flag )
{
  int i,j=0, nr=-1;
  static int px, p1, p2, pc=-1, pm=-1, ps[1000], seq=1;
  double P1[3], P2[3], Pc[3], Pm[3], pbuf[3], u;
  char name[MAX_LINE_LENGTH], setname[MAX_LINE_LENGTH];
  double pmp1[3], pmp2[3], pmp1_2[3], pmp2_2[3], nm12[3];
  double eva[3], evb[3], va[3], vb[3], p0p1_2[3], p0p2_2[3], vr[3];
…
  else if (flag==5)
  {
if(lineNr==-1)
{
  printf("ERROR: select line with key l first\n");
  return(-1);
}
px  = getPntNr( apnt );
moveLineEndPoint( lineNr, px, pickbuf);
for (i=0; il; i++) repLine(i);

lineNr=-1;
  }
  return (nr);
}

It looks like the return(-1) is needed?

Mark Brethen
mark.bret...@gmail.com



> On Jul 26, 2022, at 2:18 PM, Chris Jones  wrote:
> 
> 
> 
>> On 26 Jul 2022, at 6:27 pm, Mark Brethen  wrote:
>> 
>> would a ‘return;’ instead of ‘return(-1);’ suffice>?
> 
> Depends on what the intentions of the developers are here…
> 
> If callees of the function expect a return value, then the method should 
> instead be updated to declare a return type, and then to always return 
> something (usually 0 for successful calls).
>  
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Jul 26, 2022, at 11:51 AM, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> 
>>> clang is correct in this case, gcc is being sloppy. 
>>> 
>>> Basically you cannot return a value, from a function declared as void… 
>>> fairly basic stuff really..
>>> 
>>>> On 26 Jul 2022, at 5:34 pm, Mark Brethen >>> <mailto:mark.bret...@gmail.com>> wrote:
>>>> 
>>>> I’m seeing this build error when using clang (gcc doesn’t complain):
>>>> 
>>>> info:build /opt/local/bin/clang-mp-14 -O2 -Wall -Wno-narrowing -I./ 
>>>> -I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src 
>>>> -I../../glut-3.5/src-c -o pickFunktions.o pickFunktions.c
>>>> :info:build pickFunktions.c:4599:7: error: void function 
>>>> 'moveLineEndPoint' should not return a value [-Wreturn-type]
>>>> :info:build   return(-1);
>>>> :info:build   ^ 
>>>> 
>>>> code snippet below:
>>>> 
>>>>  void moveLineEndPoint(int lineNr, int pntNr, double llength)
>>>> {
>>>>   int p1,p2, flag=0;
>>>>   double P1[3], P2[3], u, eva[3], va[3], p0p1_2[3];
>>>> 
>>>> p1=line[lineNr].p1;
>>>> p2=line[lineNr].p2;
>>>> 
>>>> /* determine which side of the line has to be moved */
>>>> if(pntNr==p1) flag=-1;
>>>> else if(pntNr==p2) flag=1;
>>>> else
>>>> {
>>>>   printf("ERROR: selected point:%s is no line endpoint\n", 
>>>> point[pntNr].name);
>>>>   return(-1);
>>>> }
>>>> u=flag*llength;
>>>> u/=scale->w;
>>>> 
>>>> /* calc direction */
>>>> if(line[lineNr].typ=='s')
>>>> {
>>>>   if(flag==-1) p2=set[line[lineNr].trk].pnt[1];
>>>>   else  p1=set[line[lineNr].trk].pnt[set[line[lineNr].trk].anz_p-2];
>>>> }
>>>> P1[0]=point[p1].px;
>>>> P1[1]=point[p1].py;
>>>> P1[2]=point[p1].pz;
>>>> P2[0]=point[p2].px;
>>>> P2[1]=point[p2].py;
>>>> P2[2]=point[p2].pz;
>>>> v_result( P1, P2, p0p1_2);
>>>> v_norm(p0p1_2,eva);
>>>> v_scal(,eva, va);
>>>> point[pntNr].px+=va[0];
>>>> point[pntNr].py+=va[1];
>>>> point[pntNr].pz+=va[2];
>>>> printf("moved by dxyz= %lf %lf %lf\n",
>>>>   (va[0]* scale->w),
>>>>   (va[1]* scale->w),
>>>>   (va[2]* scale->w));
>>>> }
>>>> 
>>>> I do not code in C, so I’ll pass this up to the developer. How should this 
>>>> be patched?
>>>> 
>>>> Thanks,
>>>> Mark
>>>> 
>>>> 
>>>> 
>>> 
>> 

Re: CalculiX build error using clang

[Mark Brethen]

would a ‘return;’ instead of ‘return(-1);’ suffice>?

Mark Brethen
mark.bret...@gmail.com



> On Jul 26, 2022, at 11:51 AM, Christopher Jones  
> wrote:
> 
> 
> clang is correct in this case, gcc is being sloppy. 
> 
> Basically you cannot return a value, from a function declared as void… fairly 
> basic stuff really..
> 
>> On 26 Jul 2022, at 5:34 pm, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> I’m seeing this build error when using clang (gcc doesn’t complain):
>> 
>> info:build /opt/local/bin/clang-mp-14 -O2 -Wall -Wno-narrowing -I./ 
>> -I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src 
>> -I../../glut-3.5/src-c -o pickFunktions.o pickFunktions.c
>> :info:build pickFunktions.c:4599:7: error: void function 'moveLineEndPoint' 
>> should not return a value [-Wreturn-type]
>> :info:build   return(-1);
>> :info:build   ^ 
>> 
>> code snippet below:
>> 
>>  void moveLineEndPoint(int lineNr, int pntNr, double llength)
>> {
>>   int p1,p2, flag=0;
>>   double P1[3], P2[3], u, eva[3], va[3], p0p1_2[3];
>> 
>> p1=line[lineNr].p1;
>> p2=line[lineNr].p2;
>> 
>> /* determine which side of the line has to be moved */
>> if(pntNr==p1) flag=-1;
>> else if(pntNr==p2) flag=1;
>> else
>> {
>>   printf("ERROR: selected point:%s is no line endpoint\n", 
>> point[pntNr].name);
>>   return(-1);
>> }
>> u=flag*llength;
>> u/=scale->w;
>> 
>> /* calc direction */
>> if(line[lineNr].typ=='s')
>> {
>>   if(flag==-1) p2=set[line[lineNr].trk].pnt[1];
>>   else  p1=set[line[lineNr].trk].pnt[set[line[lineNr].trk].anz_p-2];
>> }
>> P1[0]=point[p1].px;
>> P1[1]=point[p1].py;
>> P1[2]=point[p1].pz;
>> P2[0]=point[p2].px;
>> P2[1]=point[p2].py;
>> P2[2]=point[p2].pz;
>> v_result( P1, P2, p0p1_2);
>> v_norm(p0p1_2,eva);
>> v_scal(,eva, va);
>> point[pntNr].px+=va[0];
>> point[pntNr].py+=va[1];
>> point[pntNr].pz+=va[2];
>> printf("moved by dxyz= %lf %lf %lf\n",
>>   (va[0]* scale->w),
>>   (va[1]* scale->w),
>>   (va[2]* scale->w));
>> }
>> 
>> I do not code in C, so I’ll pass this up to the developer. How should this 
>> be patched?
>> 
>> Thanks,
>> Mark
>> 
>> 
>> 
> 

CalculiX build error using clang

[Mark Brethen]

I’m seeing this build error when using clang (gcc doesn’t complain):

info:build /opt/local/bin/clang-mp-14 -O2 -Wall -Wno-narrowing -I./ 
-I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src 
-I../../glut-3.5/src-c -o pickFunktions.o pickFunktions.c
:info:build pickFunktions.c:4599:7: error: void function 'moveLineEndPoint' 
should not return a value [-Wreturn-type]
:info:build   return(-1);
:info:build   ^ 

code snippet below:

 void moveLineEndPoint(int lineNr, int pntNr, double llength)
{
  int p1,p2, flag=0;
  double P1[3], P2[3], u, eva[3], va[3], p0p1_2[3];

p1=line[lineNr].p1;
p2=line[lineNr].p2;

/* determine which side of the line has to be moved */
if(pntNr==p1) flag=-1;
else if(pntNr==p2) flag=1;
else
{
  printf("ERROR: selected point:%s is no line endpoint\n", 
point[pntNr].name);
  return(-1);
}
u=flag*llength;
u/=scale->w;

/* calc direction */
if(line[lineNr].typ=='s')
{
  if(flag==-1) p2=set[line[lineNr].trk].pnt[1];
  else  p1=set[line[lineNr].trk].pnt[set[line[lineNr].trk].anz_p-2];
}
P1[0]=point[p1].px;
P1[1]=point[p1].py;
P1[2]=point[p1].pz;
P2[0]=point[p2].px;
P2[1]=point[p2].py;
P2[2]=point[p2].pz;
v_result( P1, P2, p0p1_2);
v_norm(p0p1_2,eva);
v_scal(,eva, va);
point[pntNr].px+=va[0];
point[pntNr].py+=va[1];
point[pntNr].pz+=va[2];
printf("moved by dxyz= %lf %lf %lf\n",
  (va[0]* scale->w),
  (va[1]* scale->w),
  (va[2]* scale->w));
}

I do not code in C, so I’ll pass this up to the developer. How should this be 
patched?

Thanks,
Mark

Re: fetch timeout

[Mark Brethen]

The mp curl no longer downloads from the target website, wias-berlin.de; web 
download still works. The only changes were an Xcode update and reinstalling 
commandlinetools and macports for big sur.

Mark Brethen
mark.bret...@gmail.com



> On Jul 22, 2022, at 3:34 PM, Ryan Schmidt  wrote:
> 
> On Jul 15, 2022, at 09:55, Chris Jones wrote:
> 
>> On 15/07/2022 3:49 pm, Mark Brethen wrote:
>>> -rw-r--r--1 root  wheel  346545 Jan  1  2020 cert.pem
>> 
>> The above could be your problem, as that is very old, 2.5 years or so now. 
>> It actually pre-dates the public release of macOS 11, which wasn't until 
>> November that year, which makes it quite suspicious...
>> 
>> In comparison mine is from May this year, on macOS12. I would imagine the 
>> same on macOS 11 to be much more up to date than the above.
> 
> I don't believe the above indicates a problem with Mark's system but rather a 
> strangeness of macOS 11. On both an Intel MacBook Pro and on an Apple Silicon 
> Mac mini I have access to, the creation and modification date of the macOS 11 
> disk volume and all of its system files is and has always been Jan 1, 2020 
> midnight California time. The same is not true of macOS 12 volumes on the 
> same machines.
> 

Re: py310-pyqt5 build error big sur

[Mark Brethen]

I had switched developer path to commandlinetools. When I switched it back fftw 
installed.

Mark Brethen
mark.bret...@gmail.com



> On Jul 25, 2022, at 7:59 PM, Mark Brethen  wrote:
> 
> fftw-3 is also failing to build. Is this an apple or MacPorts issue?
> 
> :info:build ld: warning: argument missing after -rpath
> :info:build ld: can't map file, errno=22 file 
> '/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk' for architecture 
> x86_64
> :info:build collect2: error: ld returned 1 exit status
> :info:build make[2]: *** [libfftw3.la <http://libfftw3.la/>] Error 1
> :info:build make[2]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_fftw-3/fftw-3/
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 24, 2022, at 9:24 AM, chrischa...@gmx.us <mailto:chrischa...@gmx.us> 
>> wrote:
>> 
>> On 7/24/22 at 9:19 AM, Mark Brethen wrote: 
>> 
>>> :info:build Project ERROR: Could not resolve SDK Path for 'macosx11' using 
>>> --show-sdk-path
>>>  
>>> I then tried
>>>  
>>> 
>>> ports $ xcrun --sdk macosx10.11 --show-sdk-path
>>> xcodebuild: error: SDK "macosx10.11" cannot be located.
>>> xcodebuild: error: SDK "macosx10.11" cannot be located.
>>> xcrun: error: unable to lookup item 'Path' in SDK 'macosx10.11'
>>> ports $ xcrun --show-sdk-path
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
>>>  
>>> How should I proceed?
>>>  
>>> Thanks,
>>> 
>>> Mark
>>  
>> 
>> Already reported: https://trac.macports.org/ticket/65410 
>> <https://trac.macports.org/ticket/65410>

Re: py310-pyqt5 build error big sur

[Mark Brethen]

fftw-3 is also failing to build. Is this an apple or MacPorts issue?

:info:build ld: warning: argument missing after -rpath
:info:build ld: can't map file, errno=22 file 
'/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk' for architecture x86_64
:info:build collect2: error: ld returned 1 exit status
:info:build make[2]: *** [libfftw3.la] Error 1
:info:build make[2]: Leaving directory 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_fftw-3/fftw-3/

Mark Brethen
mark.bret...@gmail.com



> On Jul 24, 2022, at 9:24 AM, chrischa...@gmx.us wrote:
> 
> On 7/24/22 at 9:19 AM, Mark Brethen wrote: 
> 
>> :info:build Project ERROR: Could not resolve SDK Path for 'macosx11' using 
>> --show-sdk-path
>>  
>> I then tried
>>  
>> 
>> ports $ xcrun --sdk macosx10.11 --show-sdk-path
>> xcodebuild: error: SDK "macosx10.11" cannot be located.
>> xcodebuild: error: SDK "macosx10.11" cannot be located.
>> xcrun: error: unable to lookup item 'Path' in SDK 'macosx10.11'
>> ports $ xcrun --show-sdk-path
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
>>  
>> How should I proceed?
>>  
>> Thanks,
>> 
>> Mark
>  
> 
> Already reported: https://trac.macports.org/ticket/65410 
> <https://trac.macports.org/ticket/65410>

Re: py310-pyqt5 build error big sur

[Mark Brethen]

I made a mistake

ports $ xcrun --sdk macOSX11 --show-sdk-path
xcodebuild: error: SDK "macOSX11" cannot be located.
^[[Axcodebuild: error: SDK "macOSX11" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK ‘macOSX11'
ports $ xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

as you showed:

~ $ cd /Library/Developer/CommandLineTools/SDKs
SDKs $ ls -al
total 0
drwxr-xr-x@ 9 root  wheel  288 Jul 16 16:01 ./
drwxr-xr-x@ 5 root  admin  160 Jul 16 16:01 ../
lrwxr-xr-x  1 root  wheel   14 Jul 16 15:59 MacOSX.sdk@ -> MacOSX11.3.sdk
drwxr-xr-x  8 root  wheel  256 Jul 16 15:59 MacOSX10.15.sdk/
drwxr-xr-x@ 7 root  wheel  224 Jul 16 16:01 MacOSX11.1.sdk/
drwxr-xr-x  7 root  wheel  224 Jul 16 15:58 MacOSX11.3.sdk/
lrwxr-xr-x  1 root  wheel   14 Jul 16 15:57 MacOSX11.sdk@ -> MacOSX11.3.sdk
drwxr-xr-x  7 root  wheel  224 Nov 19  2021 MacOSX12.1.sdk/
lrwxr-xr-x  1 root  wheel   14 Jul 16 15:51 MacOSX12.sdk@ -> MacOSX12.1.sdk

but xcrun points to 

MacOSX.sdk $ cd 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
SDKs $ ls -al
total 0
drwxr-xr-x  4 marbre  staff  128 Jun 20 17:55 ./
drwxr-xr-x  6 marbre  staff  192 Nov 23  2021 ../
drwxr-xr-x  7 marbre  staff  224 Jun 20 17:44 MacOSX.sdk/
lrwxr-xr-x  1 marbre  staff   10 Jun 20 17:42 MacOSX12.1.sdk@ -> MacOSX.sdk

Mark Brethen
mark.bret...@gmail.com



> On Jul 24, 2022, at 9:24 AM, chrischa...@gmx.us wrote:
> 
> On 7/24/22 at 9:19 AM, Mark Brethen wrote: 
> 
>> :info:build Project ERROR: Could not resolve SDK Path for 'macosx11' using 
>> --show-sdk-path
>>  
>> I then tried
>>  
>> 
>> ports $ xcrun --sdk macosx10.11 --show-sdk-path
>> xcodebuild: error: SDK "macosx10.11" cannot be located.
>> xcodebuild: error: SDK "macosx10.11" cannot be located.
>> xcrun: error: unable to lookup item 'Path' in SDK 'macosx10.11'
>> ports $ xcrun --show-sdk-path
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
>>  
>> How should I proceed?
>>  
>> Thanks,
>> 
>> Mark
>  
> 
> Already reported: https://trac.macports.org/ticket/65410 
> <https://trac.macports.org/ticket/65410>

py310-pyqt5 build error big sur

[Mark Brethen]

py310-pyqt5 error:

:info:build Project ERROR: Could not resolve SDK Path for 'macosx11' using 
--show-sdk-path

I then tried

ports $ xcrun --sdk macosx10.11 --show-sdk-path
xcodebuild: error: SDK "macosx10.11" cannot be located.
xcodebuild: error: SDK "macosx10.11" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx10.11'
ports $ xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

How should I proceed?

Thanks,
Mark

Re: openGL Framework

[Mark Brethen]

if I switch to X11 server, should I remove /opt/X11 along with Xquartz.app?

Mark Brethen
mark.bret...@gmail.com



> On Jul 22, 2022, at 6:28 PM, Ryan Schmidt  wrote:
> 
> On Jul 19, 2022, at 17:18, Mark Brethen wrote:
> 
>> I’m also confused about the two x11 window environments (xorg-server vs 
>> xquartz). I’m assuming Xquartz libraries, etc are in /opt/local, what about 
>> xorg?
> 
> XQuartz is a standalone package that installs a complete X11 system, 
> including the X11 server application XQuartz.app into /Applications/Utilities 
> and the supporting X11 libraries into /opt/X11.
> 
> The xorg ports in MacPorts are the same software but you can pick and choose 
> what you want to install, and we might have newer versions of some of the 
> software than XQuartz since we update ports individually whereas XQuartz is a 
> monolithic distribution. We call the X11 server application X11.app and 
> install it into /Applications/MacPorts or whatever your applications_dir is 
> set to and we install the X11 libraries into /opt/local or whatever your 
> prefix is set to.
> 
> Both XQuartz and the xorg ports in MacPorts are maintained by Jeremy 
> Huddleston Sequoia.
> 
> Any ports in MacPorts that need X11 libraries will use the ones provided by 
> MacPorts X11 ports, not those provided by XQuartz.
> 
> If you want to run an X11 server, you can use either one, but most MacPorts 
> users probably choose the MacPorts xorg-server port since that's one less 
> thing to need to update separately and you don't end up with redundant copies 
> of X11 libraries.
> 

Re: openGL Framework

[Mark Brethen]

I was able to build CalculiX but I’m seeing this error upon testing:cgx -c beamp.inpError in:sem_initError in:sem_initError in:sem_initError in:sem_initon a Darwin machine, nodename brethen-air.attlocal.net, release 20.6.0, version Darwin Kernel Version 20.6.0: Tue Apr 19 21:04:45 PDT 2022; root:xnu-7195.141.29~1/RELEASE_X86_64, machine x86_64  The HOME was detected:/Users/marbreparameters:3 arguments:2GL_MAX_EVAL_ORDER:10, mesh threads:1 /Users/marbre/.cgx openedThere isn’t a configure for this, everything is defined in the Makefile so a patch is necessary. During build I’m seeing this message multiple times: :info:build cgx.c:6476:3: warning: 'sem_init' is deprecated [-Wdeprecated-declarations]

patch-cgx-build.diff
Description: Binary data


Portfile
Description: Binary data

Mark

Re: openGL Framework

[Mark Brethen]

I should have read through the whole document, further clarification:

 B: Instalation from the source:


Make sure that you have the devel packages for the graphic system
installed (the headers for X11 etc.)

You need openGL on your system. Check your file system for the
two following libraries:

The openGL-library:  libGL.so  or  libMesaGL.so
The higher level openGL-library: libGLU.so  or  libMesaGLU.so

The libGLU should be the one from SGI. Otherwise the nurbs rendering
is not supported.


Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 5:18 PM, Mark Brethen  wrote:
> 
> This is from the install notes for CalculiX:
> 
> The libGLU should be the one from SGI. Otherwise the nurbs rendering is
> not supported.
> mesa’s API is very similar to that of OpenGL however it doesn't claim to be a 
> compatible replacement for OpenGL. So I’m not sure if that’s what I should 
> build with. 
> 
> I’m also confused about the two x11 window environments (xorg-server vs 
> xquartz). I’m assuming Xquartz libraries, etc are in /opt/local, what about 
> xorg?
> 
> Thanks,
> Mark
> 
> 
>> On Jul 2, 2022, at 12:00 AM, Ryan Schmidt > <mailto:ryandes...@macports.org>> wrote:
>> 
>> On Jun 30, 2022, at 07:50, Mark Brethen wrote:
>>> 
>>> I noticed that -framework OpenGL exists in /System/Library/Frameworks. Is 
>>> there an OpenGL framework port that I should be using?
>> 
>> The MacPorts equivalent of the OpenGL framework is the mesa port.
>> 
> 

Re: fetch timeout

[Mark Brethen]

port is setup to use apple’s curl/openssl.

Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 7:13 PM, Dave Allured - NOAA Affiliate via macports-dev 
>  wrote:
> 
> Hmmm.  If port curl is already installed and active, then why would 
> subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?
> 
> 
> On Tue, Jul 19, 2022 at 6:00 PM Mark Brethen  <mailto:mark.bret...@gmail.com>> wrote:
> tetgen has dependency on cmake which depends on curl. If it's possible to 
> check the machine and os version, could override fetch under those specific 
> cases.
> 
> I’ll also contact the host, but I suspect it’s a bug in openssl:
> 
> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake 
> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>  alert number 40
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
>> On Jul 19, 2022, at 6:00 PM, Dave Allured - NOAA Affiliate via macports-dev 
>> mailto:macports-dev@lists.macports.org>> 
>> wrote:
>> 
>> Several of us have now reproduced the SSL problem.  I see two things in 
>> common:
>> (1)  Older curl/SSL versions bundled into older MacOS versions, such as 
>> Catalina.
>> (2)  The target website, wias-berlin.de <http://wias-berlin.de/>.
>> 
>> I suspect wias-berlin.de <http://wias-berlin.de/> is misconfigured somehow.  
>> Mark, consider showing this problem to them, and ask them to check their 
>> server configuration.  It is reasonable to expect Catalina Macs to be able 
>> to download their files using the system curl.  I can certainly download 
>> from many other websites.
>> 
>> Another possibility is to go back to one of Mark's earlier ideas.  Get 
>> Macports to use the MP version of curl.  I don't know how to do this.  What 
>> happens if you simply install and activate port curl, before install tetgen 
>> (Mark's new port)?
>> 
>> 
>> On Tue, Jul 19, 2022 at 11:26 AM Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> Big Sur installs the same version curl/openssl and it does not work on 
>> intel. It does work on an M1, which is surprising.
>> 
>> ~ $ /usr/bin/curl --version
>> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
>> Release-Date: 2019-03-27
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
>> pop3s rtsp smb smbs smtp smtps telnet tftp 
>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
>> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>> ~ $ 
>> 
>> I noticed nghttp2 @1.41.0 vs 1.39.2.
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>>> On Jul 19, 2022, at 12:07 PM, Gary Palter >> <mailto:pal...@clozure.com>> wrote:
>>> 
>>> Apparently not.
>>>> Last login: Tue Jul 19 12:56:44 on console
>>>> palter@Catalina ~ % /usr/bin/curl --version
>>>> curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) 
>>>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
>>>> Release-Date: 2019-03-27
>>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
>>>> pop3s rtsp smb smbs smtp smtps telnet tftp 
>>>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
>>>> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>>>> palter@Catalina ~ % cd Downloads 
>>>> palter@Catalina Downloads % /usr/bin/curl -O 
>>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>>>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>>> Current
>>>>  Dload  Upload   Total   Spent    Left  
>>>> Speed
>>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--   
>>>>   0
>>>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>>>> handshake failure
>>>> palter@Catalina Downloads % 
>>> The above is a vanilla install of Intel Catalina running in a VM.
>>> 
>>>   - Gary
>>> 
>>>> On Jul 19, 2022, at 12:55 PM, Mark Brethen >>> <mailto:mark.bret...@gmail.com>> wrote:
>>>> 
>>>> Anyone else confirm

Re: fetch timeout

[Mark Brethen]

tetgen has dependency on cmake which depends on curl. If it's possible to check 
the machine and os version, could override fetch under those specific cases.

I’ll also contact the host, but I suspect it’s a bug in openssl:

routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake 
failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
 alert number 40

Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 6:00 PM, Dave Allured - NOAA Affiliate via macports-dev 
>  wrote:
> 
> Several of us have now reproduced the SSL problem.  I see two things in 
> common:
> (1)  Older curl/SSL versions bundled into older MacOS versions, such as 
> Catalina.
> (2)  The target website, wias-berlin.de <http://wias-berlin.de/>.
> 
> I suspect wias-berlin.de <http://wias-berlin.de/> is misconfigured somehow.  
> Mark, consider showing this problem to them, and ask them to check their 
> server configuration.  It is reasonable to expect Catalina Macs to be able to 
> download their files using the system curl.  I can certainly download from 
> many other websites.
> 
> Another possibility is to go back to one of Mark's earlier ideas.  Get 
> Macports to use the MP version of curl.  I don't know how to do this.  What 
> happens if you simply install and activate port curl, before install tetgen 
> (Mark's new port)?
> 
> 
> On Tue, Jul 19, 2022 at 11:26 AM Mark Brethen  <mailto:mark.bret...@gmail.com>> wrote:
> Big Sur installs the same version curl/openssl and it does not work on intel. 
> It does work on an M1, which is surprising.
> 
> ~ $ /usr/bin/curl --version
> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
> Release-Date: 2019-03-27
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
> pop3s rtsp smb smbs smtp smtps telnet tftp 
> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
> ~ $ 
> 
> I noticed nghttp2 @1.41.0 vs 1.39.2.
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
>> On Jul 19, 2022, at 12:07 PM, Gary Palter > <mailto:pal...@clozure.com>> wrote:
>> 
>> Apparently not.
>>> Last login: Tue Jul 19 12:56:44 on console
>>> palter@Catalina ~ % /usr/bin/curl --version
>>> curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) 
>>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
>>> Release-Date: 2019-03-27
>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
>>> pop3s rtsp smb smbs smtp smtps telnet tftp 
>>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
>>> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>>> palter@Catalina ~ % cd Downloads 
>>> palter@Catalina Downloads % /usr/bin/curl -O 
>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>>  Dload  Upload   Total   SpentLeft  
>>> Speed
>>>   0     00 00 0  0  0 --:--:-- --:--:-- --:--:--
>>>  0
>>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>>> handshake failure
>>> palter@Catalina Downloads % 
>> The above is a vanilla install of Intel Catalina running in a VM.
>> 
>>   - Gary
>> 
>>> On Jul 19, 2022, at 12:55 PM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> Anyone else confirm system curl works with this host on intel mac with 
>>> catalina or big sur?
>>> 
>>> Mark
>>> 
>>>> On Jul 19, 2022, at 11:49 AM, Mark Brethen >>> <mailto:mark.bret...@gmail.com>> wrote:
>>>> 
>>>> Yes, I have mp curl as well. Unfortunately, port uses Apple’s 
>>>> curl/openssl. Only work around is to override fetch and use mp.
>>>> 
>>>> Mark Brethen
>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>> 
>>>>> On Jul 19, 2022, at 11:42 AM, Nils Breunese >>>> <mailto:n...@breun.nl>> wrote:
>>>>> 
>>>>> Mark Brethen mailto:mark.bret...@gmail.com>> 
>>>>> wrote:
>>>>> 
>>>>>> What version of curl/libressl?
>&g

Re: openGL Framework

[Mark Brethen]

This is from the install notes for CalculiX:

The libGLU should be the one from SGI. Otherwise the nurbs rendering is
not supported.
mesa’s API is very similar to that of OpenGL however it doesn't claim to be a 
compatible replacement for OpenGL. So I’m not sure if that’s what I should 
build with. 

I’m also confused about the two x11 window environments (xorg-server vs 
xquartz). I’m assuming Xquartz libraries, etc are in /opt/local, what about 
xorg?

Thanks,
Mark


> On Jul 2, 2022, at 12:00 AM, Ryan Schmidt  wrote:
> 
> On Jun 30, 2022, at 07:50, Mark Brethen wrote:
>> 
>> I noticed that -framework OpenGL exists in /System/Library/Frameworks. Is 
>> there an OpenGL framework port that I should be using?
> 
> The MacPorts equivalent of the OpenGL framework is the mesa port.
> 

Re: fetch timeout

[Mark Brethen]

Big Sur installs the same version curl/openssl and it does not work on intel. 
It does work on an M1, which is surprising.

~ $ /usr/bin/curl --version
curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
~ $ 

I noticed nghttp2 @1.41.0 vs 1.39.2.

Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 12:07 PM, Gary Palter  wrote:
> 
> Apparently not.
> 
>> Last login: Tue Jul 19 12:56:44 on console
>> palter@Catalina ~ % /usr/bin/curl --version
>> curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) 
>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
>> Release-Date: 2019-03-27
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
>> pop3s rtsp smb smbs smtp smtps telnet tftp 
>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
>> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>> palter@Catalina ~ % cd Downloads 
>> palter@Catalina Downloads % /usr/bin/curl -O 
>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>>  Dload  Upload   Total   SpentLeft  Speed
>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- >> 0
>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>> handshake failure
>> palter@Catalina Downloads % 
> 
> The above is a vanilla install of Intel Catalina running in a VM.
> 
>   - Gary
> 
> 
>> On Jul 19, 2022, at 12:55 PM, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> Anyone else confirm system curl works with this host on intel mac with 
>> catalina or big sur?
>> 
>> Mark
>> 
>> 
>> 
>>> On Jul 19, 2022, at 11:49 AM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> Yes, I have mp curl as well. Unfortunately, port uses Apple’s curl/openssl. 
>>> Only work around is to override fetch and use mp.
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> 
>>> 
>>> 
>>>> On Jul 19, 2022, at 11:42 AM, Nils Breunese  wrote:
>>>> 
>>>> Mark Brethen  wrote:
>>>> 
>>>>> What version of curl/libressl?
>>>> 
>>>> 
>>>> I have curl and openssl installed from MacPorts:
>>>> 
>>>> ❯ port installed | egrep 'curl|openssl'
>>>> curl @7.84.0_0+http2+ssl (active)
>>>> curl-ca-bundle @7.84.0_0 (active)
>>>> openssl @3_6 (active)
>>>> openssl3 @3.0.5_0+legacy (active)
>>>> openssl11 @1.1.1q_0 (active)
>>>> 
>>>> MacPorts curl 7.84.0 uses OpenSSL 3.0.5:
>>>> 
>>>> ❯ /opt/local/bin/curl --version
>>>> curl 7.84.0 (x86_64-apple-darwin21.3.0) libcurl/7.84.0 OpenSSL/3.0.5 
>>>> zlib/1.2.12 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.3 libpsl/0.21.1 
>>>> (+libidn2/2.3.2) nghttp2/1.48.0
>>>> Release-Date: 2022-06-27
>>>> Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt 
>>>> pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
>>>> Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 
>>>> Largefile libz NTLM NTLM_WB PSL SSL threadsafe TLS-SRP UnixSockets zstd
>>>> 
>>>> macOS 12.4 curl 7.79.1 uses LibreSSL 3.3.6:
>>>> 
>>>> ❯ /usr/bin/curl --version
>>>> curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) 
>>>> LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
>>>> Release-Date: 2021-09-22
>>>> Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap 
>>>> ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
>>>> Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos 
>>>> Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>>>> 
>>>> Using macOS curl also works:
>>>> 
>>>> ❯ /usr/bin/curl -O 
>>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>>>> % Total% Received % Xferd  Average Speed   TimeTime Time  
>>>> Current
>>>>   Dload  Upload   Total   SpentLeft  Speed
>>>> 100  275k  100  275k0 0   758k  0 --:--:-- --:--:-- --:--:—  
>>>> 779k
>>>> 
>>>> Nils.
>>>> 
>>> 
>> 
> 

Re: fetch timeout

[Mark Brethen]

Anyone else confirm system curl works with this host on intel mac with catalina 
or big sur?

Mark



> On Jul 19, 2022, at 11:49 AM, Mark Brethen  wrote:
> 
> Yes, I have mp curl as well. Unfortunately, port uses Apple’s curl/openssl. 
> Only work around is to override fetch and use mp.
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jul 19, 2022, at 11:42 AM, Nils Breunese  wrote:
>> 
>> Mark Brethen  wrote:
>> 
>>> What version of curl/libressl?
>> 
>> 
>> I have curl and openssl installed from MacPorts:
>> 
>> ❯ port installed | egrep 'curl|openssl'
>> curl @7.84.0_0+http2+ssl (active)
>> curl-ca-bundle @7.84.0_0 (active)
>> openssl @3_6 (active)
>> openssl3 @3.0.5_0+legacy (active)
>> openssl11 @1.1.1q_0 (active)
>> 
>> MacPorts curl 7.84.0 uses OpenSSL 3.0.5:
>> 
>> ❯ /opt/local/bin/curl --version
>> curl 7.84.0 (x86_64-apple-darwin21.3.0) libcurl/7.84.0 OpenSSL/3.0.5 
>> zlib/1.2.12 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.3 libpsl/0.21.1 
>> (+libidn2/2.3.2) nghttp2/1.48.0
>> Release-Date: 2022-06-27
>> Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 
>> pop3s rtsp smb smbs smtp smtps telnet tftp 
>> Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile 
>> libz NTLM NTLM_WB PSL SSL threadsafe TLS-SRP UnixSockets zstd
>> 
>> macOS 12.4 curl 7.79.1 uses LibreSSL 3.3.6:
>> 
>> ❯ /usr/bin/curl --version
>> curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) 
>> LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
>> Release-Date: 2021-09-22
>> Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap 
>> ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
>> Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos 
>> Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>> 
>> Using macOS curl also works:
>> 
>> ❯ /usr/bin/curl -O 
>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 100  275k  100  275k0 0   758k  0 --:--:-- --:--:-- --:--:—  779k
>> 
>> Nils.
>> 
> 

Re: fetch timeout

[Mark Brethen]

Yes, I have mp curl as well. Unfortunately, port uses Apple’s curl/openssl. 
Only work around is to override fetch and use mp.

Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 11:42 AM, Nils Breunese  wrote:
> 
> Mark Brethen  wrote:
> 
>> What version of curl/libressl?
> 
> 
> I have curl and openssl installed from MacPorts:
> 
> ❯ port installed | egrep 'curl|openssl'
>  curl @7.84.0_0+http2+ssl (active)
>  curl-ca-bundle @7.84.0_0 (active)
>  openssl @3_6 (active)
>  openssl3 @3.0.5_0+legacy (active)
>  openssl11 @1.1.1q_0 (active)
> 
> MacPorts curl 7.84.0 uses OpenSSL 3.0.5:
> 
> ❯ /opt/local/bin/curl --version
> curl 7.84.0 (x86_64-apple-darwin21.3.0) libcurl/7.84.0 OpenSSL/3.0.5 
> zlib/1.2.12 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.3 libpsl/0.21.1 
> (+libidn2/2.3.2) nghttp2/1.48.0
> Release-Date: 2022-06-27
> Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 
> pop3s rtsp smb smbs smtp smtps telnet tftp 
> Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile 
> libz NTLM NTLM_WB PSL SSL threadsafe TLS-SRP UnixSockets zstd
> 
> macOS 12.4 curl 7.79.1 uses LibreSSL 3.3.6:
> 
> ❯ /usr/bin/curl --version
> curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) 
> LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
> Release-Date: 2021-09-22
> Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps 
> mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
> Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos 
> Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
> 
> Using macOS curl also works:
> 
> ❯ /usr/bin/curl -O 
> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100  275k  100  275k0 0   758k  0 --:--:-- --:--:-- --:--:—  779k
> 
> Nils.
> 

Re: fetch timeout

[Mark Brethen]

I tried it on my spouse’s intel MacBook— confirmed it works on MacOS version 
10.13.6 (LibreSSL 2.2.7). And yes, I extracted the file this time!

Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 11:34 AM, Mark Brethen  wrote:
> 
> What version of curl/libressl?
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jul 19, 2022, at 11:31 AM, Nils Breunese  wrote:
>> 
>> Mark Brethen  wrote:
>> 
>>> it has the file name and extensions but you’re right, it’s not a compressed 
>>> file.
>> 
>> The -O flag will write whatever body gets returned by the server into a file 
>> with the same name as the 'file name’ part of the URL, regardless of whether 
>> the HTTP status code of the response indicates success, a redirect, a client 
>> error or a server error.
>> 
>> You’ll see that the 273 bytes that get returned by requesting 
>> http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz are just 
>> HTML saying the the document should be requested via HTTPS:
>> 
>> ❯ curl -O http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 100   273  100   2730 0   1122  0 --:--:-- --:--:-- --:--:—  1181
>> 
>> 
>> ❯ cat tetgen1.5.1.tar.gz 
>> 
>> 
>> 301 Moved Permanently
>> 
>> Moved Permanently
>> The document has moved > href="https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz;>here.
>> 
>> 
>> When you tell curl to follow redirects, you’ll see a second request being 
>> made and 275k getting downloaded:
>> 
>> ❯ curl -OL http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 100   273  100   2730 0194  0  0:00:01  0:00:01 --:--:--   
>> 195
>> 100  275k  100  275k0 0  75618  0  0:00:03  0:00:03 --:--:—  249k
>> 
>> ❯ file tetgen1.5.1.tar.gz 
>> tetgen1.5.1.tar.gz: gzip compressed data, was "tetgen1.5.1.tar", last 
>> modified: Tue Aug 21 14:40:36 2018, max compression, from Unix, original 
>> size modulo 2^32 1528832
>> 
>> This works fine for me on macOS 12.4 Intel.
>> 
>> Nils.
>> 
>>> I tried two different intel-based Macs with clean installs of Catalina and 
>>> Big Sur (both use LibreSSL 2.8.3 btw) and was able to repeat that error. 
>>> However, it works correctly on an M1 installed with Big Sur. Since this is 
>>> the only host that I have run into problems with fetch, I’m not sure it’s 
>>> worth the time spent.
>>> 
>>>> On Jul 19, 2022, at 10:36 AM, Nils Breunese  wrote:
>>>> 
>>>> It doesn’t look like the .tar.gz file downloaded successfully, it looks 
>>>> like the HTML for the 301 redirect was downloaded.
>>>> 
>>>> Nils.
>>>> 
>>>>> Op 19 jul. 2022 om 17:20 heeft Mark Brethen  het 
>>>>> volgende geschreven:
>>>>> 
>>>>> Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you 
>>>>> look at the command line output (not port), that error didn’t occur and 
>>>>> the file downloaded successfully. I was curious what the fetch curl 
>>>>> command looked like vs the command line?
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Jul 19, 2022, at 9:57 AM, Nils Breunese  wrote:
>>>>>> 
>>>>>> 
>>>>>> This depends on your definition of succeeding. The request to the HTTP 
>>>>>> URL returns a 301 redirect, which is not necessarily a ‘success’ status 
>>>>>> code. This response points to the HTTPS URL and the TLS/SSL error only 
>>>>>> occurs when requesting that URL.
>>>>>> 
>>>>>> Nils.
>>>>>> 
>>>>>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen  
>>>>>>> het volgende geschreven:
>>>>>>> 
>>>>>>> Please tell me why fetch still fails when /usr/bin/curl succeeds in 
>>>>>>> terminal?
>>>>>>> 
>>>>>>> :notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
>>>>>>> http://wias-berlin.d

Re: fetch timeout

[Mark Brethen]

What version of curl/libressl?

Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 11:31 AM, Nils Breunese  wrote:
> 
> Mark Brethen  wrote:
> 
>> it has the file name and extensions but you’re right, it’s not a compressed 
>> file.
> 
> The -O flag will write whatever body gets returned by the server into a file 
> with the same name as the 'file name’ part of the URL, regardless of whether 
> the HTTP status code of the response indicates success, a redirect, a client 
> error or a server error.
> 
> You’ll see that the 273 bytes that get returned by requesting 
> http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz are just 
> HTML saying the the document should be requested via HTTPS:
> 
> ❯ curl -O http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100   273  100   2730 0   1122  0 --:--:-- --:--:-- --:--:—  1181
> 
> 
> ❯ cat tetgen1.5.1.tar.gz 
> 
> 
> 301 Moved Permanently
> 
> Moved Permanently
> The document has moved  href="https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz;>here.
> 
> 
> When you tell curl to follow redirects, you’ll see a second request being 
> made and 275k getting downloaded:
> 
> ❯ curl -OL http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100   273  100   2730 0194  0  0:00:01  0:00:01 --:--:--   195
> 100  275k  100  275k0 0  75618  0  0:00:03  0:00:03 --:--:—  249k
> 
> ❯ file tetgen1.5.1.tar.gz 
> tetgen1.5.1.tar.gz: gzip compressed data, was "tetgen1.5.1.tar", last 
> modified: Tue Aug 21 14:40:36 2018, max compression, from Unix, original size 
> modulo 2^32 1528832
> 
> This works fine for me on macOS 12.4 Intel.
> 
> Nils.
> 
>> I tried two different intel-based Macs with clean installs of Catalina and 
>> Big Sur (both use LibreSSL 2.8.3 btw) and was able to repeat that error. 
>> However, it works correctly on an M1 installed with Big Sur. Since this is 
>> the only host that I have run into problems with fetch, I’m not sure it’s 
>> worth the time spent.
>> 
>>> On Jul 19, 2022, at 10:36 AM, Nils Breunese  wrote:
>>> 
>>> It doesn’t look like the .tar.gz file downloaded successfully, it looks 
>>> like the HTML for the 301 redirect was downloaded.
>>> 
>>> Nils.
>>> 
>>>> Op 19 jul. 2022 om 17:20 heeft Mark Brethen  het 
>>>> volgende geschreven:
>>>> 
>>>> Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you 
>>>> look at the command line output (not port), that error didn’t occur and 
>>>> the file downloaded successfully. I was curious what the fetch curl 
>>>> command looked like vs the command line?
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Jul 19, 2022, at 9:57 AM, Nils Breunese  wrote:
>>>>> 
>>>>> 
>>>>> This depends on your definition of succeeding. The request to the HTTP 
>>>>> URL returns a 301 redirect, which is not necessarily a ‘success’ status 
>>>>> code. This response points to the HTTPS URL and the TLS/SSL error only 
>>>>> occurs when requesting that URL.
>>>>> 
>>>>> Nils.
>>>>> 
>>>>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen  het 
>>>>>> volgende geschreven:
>>>>>> 
>>>>>> Please tell me why fetch still fails when /usr/bin/curl succeeds in 
>>>>>> terminal?
>>>>>> 
>>>>>> :notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
>>>>>> http://wias-berlin.de/software/tetgen/1.5/src/
>>>>>> :debug:fetch Fetching distfile failed: error:14008410:SSL 
>>>>>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
>>>>>> 
>>>>>> Mark Brethen
>>>>>> mark.bret...@gmail.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use 
>>>>>>&g

Re: fetch timeout

[Mark Brethen]

it has the file name and extensions but you’re right, it’s not a compressed 
file. I tried two different intel-based Macs with clean installs of Catalina 
and Big Sur (both use LibreSSL 2.8.3 btw) and was able to repeat that error. 
However, it works correctly on an M1 installed with Big Sur. Since this is the 
only host that I have run into problems with fetch, I’m not sure it’s worth the 
time spent.

> On Jul 19, 2022, at 10:36 AM, Nils Breunese  wrote:
> 
> It doesn’t look like the .tar.gz file downloaded successfully, it looks like 
> the HTML for the 301 redirect was downloaded.
> 
> Nils.
> 
>> Op 19 jul. 2022 om 17:20 heeft Mark Brethen  het 
>> volgende geschreven:
>> 
>> Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you look 
>> at the command line output (not port), that error didn’t occur and the file 
>> downloaded successfully. I was curious what the fetch curl command looked 
>> like vs the command line?
>> 
>> Sent from my iPhone
>> 
>>> On Jul 19, 2022, at 9:57 AM, Nils Breunese  wrote:
>>> 
>>> 
>>> This depends on your definition of succeeding. The request to the HTTP URL 
>>> returns a 301 redirect, which is not necessarily a ‘success’ status code. 
>>> This response points to the HTTPS URL and the TLS/SSL error only occurs 
>>> when requesting that URL.
>>> 
>>> Nils.
>>> 
>>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen  het 
>>>> volgende geschreven:
>>>> 
>>>> Please tell me why fetch still fails when /usr/bin/curl succeeds in 
>>>> terminal?
>>>> 
>>>> :notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
>>>> http://wias-berlin.de/software/tetgen/1.5/src/ 
>>>> <http://wias-berlin.de/software/tetgen/1.5/src/>
>>>> :debug:fetch Fetching distfile failed: error:14008410:SSL 
>>>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
>>>> 
>>>> Mark Brethen
>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>> 
>>>> 
>>>> 
>>>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen >>>> <mailto:mark.bret...@gmail.com>> wrote:
>>>>> 
>>>>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use 
>>>>> HTTP instead:
>>>>> 
>>>>> ~ $ cd Downloads
>>>>> Downloads $ /usr/bin/curl -vO 
>>>>> http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>>>>> <http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>>>> Current
>>>>>  Dload  Upload   Total   SpentLeft  
>>>>> Speed
>>>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--  
>>>>>0*   Trying 62.141.177.111...
>>>>> * TCP_NODELAY set
>>>>> * Connected to wias-berlin.de <http://wias-berlin.de/> (62.141.177.111) 
>>>>> port 80 (#0)
>>>>> > GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
>>>>> > Host: wias-berlin.de <http://wias-berlin.de/>
>>>>> > User-Agent: curl/7.64.1
>>>>> > Accept: */*
>>>>> > 
>>>>> < HTTP/1.1 301 Moved Permanently
>>>>> < Date: Tue, 19 Jul 2022 09:37:56 GMT
>>>>> < Server: Apache
>>>>> < Location: 
>>>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>>>>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>>>> < Content-Length: 273
>>>>> < Content-Type: text/html; charset=iso-8859-1
>>>>> < 
>>>>> { [273 bytes data]
>>>>> 100   273  100   2730 0291  0 --:--:-- --:--:-- --:--:--  
>>>>>  291
>>>>> * Connection #0 to host wias-berlin.de <http://wias-berlin.de/> left 
>>>>> intact
>>>>> * Closing connection 0
>>>>> 
>>>>> Mark Brethen
>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 18, 2022, at 11:56 AM, Mark Brethen >>>>> <mailto:mark.bret...@gmail.com>> wrote:
>>>>>> 
>>>>>> It’s more l

Re: fetch timeout

[Mark Brethen]

Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you look at 
the command line output (not port), that error didn’t occur and the file 
downloaded successfully. I was curious what the fetch curl command looked like 
vs the command line?

Sent from my iPhone

> On Jul 19, 2022, at 9:57 AM, Nils Breunese  wrote:
> 
> 
> This depends on your definition of succeeding. The request to the HTTP URL 
> returns a 301 redirect, which is not necessarily a ‘success’ status code. 
> This response points to the HTTPS URL and the TLS/SSL error only occurs when 
> requesting that URL.
> 
> Nils.
> 
>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen  het 
>>> volgende geschreven:
>>> 
>> Please tell me why fetch still fails when /usr/bin/curl succeeds in 
>> terminal?
>> 
>> :notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
>> http://wias-berlin.de/software/tetgen/1.5/src/
>> :debug:fetch Fetching distfile failed: error:14008410:SSL 
>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
>> 
>> Mark Brethen
>> mark.bret...@gmail.com
>> 
>> 
>> 
>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen  wrote:
>>> 
>>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use 
>>> HTTP instead:
>>> 
>>> ~ $ cd Downloads
>>> Downloads $ /usr/bin/curl -vO 
>>> http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>>  Dload  Upload   Total   SpentLeft  
>>> Speed
>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>>>  0*   Trying 62.141.177.111...
>>> * TCP_NODELAY set
>>> * Connected to wias-berlin.de (62.141.177.111) port 80 (#0)
>>> > GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
>>> > Host: wias-berlin.de
>>> > User-Agent: curl/7.64.1
>>> > Accept: */*
>>> > 
>>> < HTTP/1.1 301 Moved Permanently
>>> < Date: Tue, 19 Jul 2022 09:37:56 GMT
>>> < Server: Apache
>>> < Location: 
>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>>> < Content-Length: 273
>>> < Content-Type: text/html; charset=iso-8859-1
>>> < 
>>> { [273 bytes data]
>>> 100   273  100   2730 0291  0 --:--:-- --:--:-- --:--:--   
>>> 291
>>> * Connection #0 to host wias-berlin.de left intact
>>> * Closing connection 0
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com
>>> 
>>> 
>>> 
>>>> On Jul 18, 2022, at 11:56 AM, Mark Brethen  wrote:
>>>> 
>>>> It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 
>>>> fails with alert number 40 (see below). It might be related to the server 
>>>> which has several virtual hosts. openssl 3.0.5 (mp) seems to handle it 
>>>> fine compared to openssl 2.8.3.
>>>> 
>>>> Downloads $ openssl version
>>>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>>>> 
>>>> Downloads $ openssl s_client -connect wias-berlin.de:443 -servername 
>>>> wias-berlin.de
>>>> CONNECTED(0005)
>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>>> verify return:1
>>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>>> verify return:1
>>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>>> verify return:1
>>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin 
>>>> e.V., OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik 
>>>> (WIAS), OU = RT, CN = www.wias-berlin.de
>>>> verify return:1
>>>> 
>>>> Downloads $ /usr/bin/openssl version
>>>> LibreSSL 2.8.3
>>>> 
>>>> Downloads $ /usr/bin/openssl s_client -connect wias-berlin.de:443 
>>>> -servername wias-berlin.de
>>>> CONNECTED(0005)
>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>>> ve

Re: fetch timeout

[Mark Brethen]

Please tell me why fetch still fails when /usr/bin/curl succeeds in terminal?

:notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
http://wias-berlin.de/software/tetgen/1.5/src/
:debug:fetch Fetching distfile failed: error:14008410:SSL 
routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure

Mark Brethen
mark.bret...@gmail.com



> On Jul 19, 2022, at 4:46 AM, Mark Brethen  wrote:
> 
> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use HTTP 
> instead:
> 
> ~ $ cd Downloads
> Downloads $ /usr/bin/curl -vO 
> http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
> <http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
> 0*   Trying 62.141.177.111...
> * TCP_NODELAY set
> * Connected to wias-berlin.de <http://wias-berlin.de/> (62.141.177.111) port 
> 80 (#0)
> > GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
> > Host: wias-berlin.de <http://wias-berlin.de/>
> > User-Agent: curl/7.64.1
> > Accept: */*
> > 
> < HTTP/1.1 301 Moved Permanently
> < Date: Tue, 19 Jul 2022 09:37:56 GMT
> < Server: Apache
> < Location: https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
> < Content-Length: 273
> < Content-Type: text/html; charset=iso-8859-1
> < 
> { [273 bytes data]
> 100   273  100   2730     0    291  0 --:--:-- --:--:-- --:--:--   291
> * Connection #0 to host wias-berlin.de <http://wias-berlin.de/> left intact
> * Closing connection 0
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 18, 2022, at 11:56 AM, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 
>> fails with alert number 40 (see below). It might be related to the server 
>> which has several virtual hosts. openssl 3.0.5 (mp) seems to handle it fine 
>> compared to openssl 2.8.3.
>> 
>> Downloads $ openssl version
>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>> 
>> Downloads $ openssl s_client -connect wias-berlin.de:443 
>> <http://wias-berlin.de:443/> -servername wias-berlin.de 
>> <http://wias-berlin.de/>
>> CONNECTED(0005)
>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
>> Center, CN = T-TeleSec GlobalRoot Class 2
>> verify return:1
>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>> verify return:1
>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>> verify return:1
>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>> verify return:1
>> 
>> Downloads $ /usr/bin/openssl version
>> LibreSSL 2.8.3
>> 
>> Downloads $ /usr/bin/openssl s_client -connect wias-berlin.de:443 
>> <http://wias-berlin.de:443/> -servername wias-berlin.de 
>> <http://wias-berlin.de/>
>> CONNECTED(0005)
>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
>> Center, CN = T-TeleSec GlobalRoot Class 2
>> verify return:1
>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>> verify return:1
>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>> verify return:1
>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>> verify return:1
>> 4381900460:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>> handshake 
>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>>  alert number 40
>> 4381900460:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake 
>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585:
>> ---
>> 
>> 
>> 
>> Mark
>> 
>> 
>> 
>>> On Jul 18, 2022, at 8:11 AM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> wias-berlin.de <http://wias-berlin.de/>
> 

Re: fetch timeout

[Mark Brethen]

HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use HTTP 
instead:

~ $ cd Downloads
Downloads $ /usr/bin/curl -vO 
http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 62.141.177.111...
* TCP_NODELAY set
* Connected to wias-berlin.de (62.141.177.111) port 80 (#0)
> GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
> Host: wias-berlin.de
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Tue, 19 Jul 2022 09:37:56 GMT
< Server: Apache
< Location: https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
< Content-Length: 273
< Content-Type: text/html; charset=iso-8859-1
< 
{ [273 bytes data]
100   273  100   2730 0291  0 --:--:-- --:--:-- --:--:--   291
* Connection #0 to host wias-berlin.de left intact
* Closing connection 0

Mark Brethen
mark.bret...@gmail.com



> On Jul 18, 2022, at 11:56 AM, Mark Brethen  wrote:
> 
> It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 
> fails with alert number 40 (see below). It might be related to the server 
> which has several virtual hosts. openssl 3.0.5 (mp) seems to handle it fine 
> compared to openssl 2.8.3.
> 
> Downloads $ openssl version
> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
> 
> Downloads $ openssl s_client -connect wias-berlin.de:443 
> <http://wias-berlin.de:443/> -servername wias-berlin.de 
> <http://wias-berlin.de/>
> CONNECTED(0005)
> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
> Center, CN = T-TeleSec GlobalRoot Class 2
> verify return:1
> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
> verify return:1
> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
> verify return:1
> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
> verify return:1
> 
> Downloads $ /usr/bin/openssl version
> LibreSSL 2.8.3
> 
> Downloads $ /usr/bin/openssl s_client -connect wias-berlin.de:443 
> <http://wias-berlin.de:443/> -servername wias-berlin.de 
> <http://wias-berlin.de/>
> CONNECTED(0005)
> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
> Center, CN = T-TeleSec GlobalRoot Class 2
> verify return:1
> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
> verify return:1
> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
> verify return:1
> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
> verify return:1
> 4381900460:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
> handshake 
> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>  alert number 40
> 4381900460:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake 
> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585:
> ---
> 
> 
> 
> Mark
> 
> 
> 
>> On Jul 18, 2022, at 8:11 AM, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> wias-berlin.de <http://wias-berlin.de/>

Re: fetch timeout

[Mark Brethen]

It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 fails 
with alert number 40 (see below). It might be related to the server which has 
several virtual hosts. openssl 3.0.5 (mp) seems to handle it fine compared to 
openssl 2.8.3.

Downloads $ openssl version
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)

Downloads $ openssl s_client -connect wias-berlin.de:443 -servername 
wias-berlin.de
CONNECTED(0005)
depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
Center, CN = T-TeleSec GlobalRoot Class 2
verify return:1
depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
verify return:1
depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
verify return:1
depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU 
= Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN 
= www.wias-berlin.de
verify return:1

Downloads $ /usr/bin/openssl version
LibreSSL 2.8.3

Downloads $ /usr/bin/openssl s_client -connect wias-berlin.de:443 -servername 
wias-berlin.de
CONNECTED(0005)
depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
Center, CN = T-TeleSec GlobalRoot Class 2
verify return:1
depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
verify return:1
depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
verify return:1
depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU 
= Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN 
= www.wias-berlin.de
verify return:1
4381900460:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
handshake 
failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
 alert number 40
4381900460:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake 
failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585:
---



Mark



> On Jul 18, 2022, at 8:11 AM, Mark Brethen  wrote:
> 
> wias-berlin.de <http://wias-berlin.de/>

Re: fetch timeout

[Mark Brethen]

outines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
handshake failure
 
Chrome has a 'Copy as cURL' feature so you can inspect what the browser is 
doing:

curl 'https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz' \
  -H 'Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9'
 \
  -H 'Accept-Language: en-US,en;q=0.9' \
  -H 'Connection: keep-alive' \
  -H 'Cookie: JSESSIONID=45D13EF3D3A2EA7165891DDD8E42CF09' \
  -H 'Sec-Fetch-Dest: document' \
  -H 'Sec-Fetch-Mode: navigate' \
  -H 'Sec-Fetch-Site: cross-site' \
  -H 'Sec-Fetch-User: ?1' \
  -H 'Upgrade-Insecure-Requests: 1' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36' \
  -H 'sec-ch-ua: ".Not/A)Brand";v="99", "Google Chrome";v="103", 
"Chromium";v="103"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  --compressed

Although it downloaded the file, It noted this error:

Mixed Content: The site at 'https://wias-berlin.de/' was loaded over a secure 
connection, but the file at 
'https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz' was 
redirected through an insecure connection. This file should be served over 
HTTPS. This download has been blocked. See 
https://blog.chromium.org/2020/02/protecting-users-from-insecure.html for more 
details.

So it may have something to do with this host in particular and the curl 
version, I don’t think it has anything to do with the cert files.



Mark Brethen
mark.bret...@gmail.com



> On Jul 18, 2022, at 3:21 AM, Christopher Jones  
> wrote:
> 
> 
> 
>> On 17 Jul 2022, at 7:12 pm, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> It’s interesting that curl fails from my older MacBook Air, but passes on 
>> the M1 iMac, both with OS 11 installed. Even after a clean reinstall. I 
>> suspect it’s something about Apple’s openssl. Browsers don’t seem to mind 
>> the certificate.
> 
> No, I very much doubt that is the case. If it where the case if would fail 
> for you on both machines.
> 
>> 
>> As a work around, I’d like to add something like this:
>> 
>> set check.os.major 21
>> if {${check.os.major} > ${os.major}} {
>> depends_fetch-append curl
>> fetch {
>> system "curl -L -o ${distpath}/${distfiles} 
>> ${master_sites}${distfiles}"
>> }
>> }
> 
> It is not appropriate to add that to a port file when the origin of the issue 
> is still not understood, and quite likely something specific to your setup.
> 
> Chris
> 
>> 
>> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Jul 17, 2022, at 8:49 AM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> I think I’m getting to the root of the problem. I tried to obtain the SSL 
>>> certificate from the host server using openssl.
>>> 
>>> Downloads $ echo | openssl s_client -servername wias-berlin.de 
>>> <http://wias-berlin.de/> -connect wias-berlin.de:443 
>>> <http://wias-berlin.de:443/> |\ 
>>>
>>>   sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > certificate.crt
>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>> verify return:1
>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>> verify return:1
>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>> verify return:1
>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>>> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>>> verify return:1
>>> 4479426220:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>>> handshake 
>>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>>>  alert number 4

Re: compilers PortGroup

[Mark Brethen]

It’s a local port I’m updating. The source does not have configure, so the makefile has to be patched and build environment passed.

Portfile
Description: Binary data

Mark Brethenmark.bret...@gmail.com


On Jul 17, 2022, at 6:41 PM, Ken Cunningham  wrote:Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
To work around this, you need to add -fallow-argument-mismatch to the FFLAGS inside Makefile:
Funny, that is exactly the argument that:compilers.allow_arguments_mismatch yesis supposed to add for you to fix this. Now I wonder why it doesn’t add it?What port are you trying to build again? Something fishy here, it seems.K

Re: compilers PortGroup

[Mark Brethen]

Have I got this right? It seems to work:

set ver [regsub -all {[[:alpha:]]+} ${compilers.gcc_default} {}]
if { ${ver} >= 10 } {
reinplace \
"s|FFLAGS = -Wall -O2|FFLAGS = -Wall -O2 
-fallow-argument-mismatch|g" \
${worksrcpath}/src/Makefile
}


Thanks,
Mark



> On Jul 17, 2022, at 12:48 PM, Mark Brethen  wrote:
> 
> Unfortunately spooles is no longer maintained, but I found this discussion 
> online:
> 
> If you compile with GCC 10 or newer, you will get the following error, 
> originating from CalculiX:
> 
> Error: Rank mismatch between actual argument at (1) and actual argument at 
> (2) (rank-1 and scalar)
> To work around this, you need to add -fallow-argument-mismatch to the FFLAGS 
> inside Makefile:
> 
> - FFLAGS = -Wall -O3 -fopenmp $(INCLUDES)
> + FFLAGS = -Wall -O3 -fopenmp -fallow-argument-mismatch $(INCLUDES)
> 
> I’ll implement this in a patch, assuming everyone is building with >+ 10? 
> Would it hurt to patch it even if gcc <10?
> 
> Mark 
> 
> 
> 
>> On Jul 17, 2022, at 12:01 PM, Chris Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> Ok, shame.
>> 
>> Nevertheless, this is not an issue with the compiler but the code itself. 
>> You might try discussing it with the upstream maintainers.
>> 
>> Chris
>> 
>>> On 17 Jul 2022, at 3:29 pm, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> Hmm, 'compilers.allow_arguments_mismatch yes’ had no effect—same failure. 
>>> I looked at the compilers group and with it set, and gfortran variant is 
>>> selected, chooses ${compilers.gcc_default}. Which in my case was 
>>> gcc12—which is already installed.
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> 
>>> 
>>> 
>>>> On Jul 17, 2022, at 6:15 AM, Chris Jones >>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 17 Jul 2022, at 1:59 am, Mark Brethen >>>> <mailto:mark.bret...@gmail.com>> wrote:
>>>>> 
>>>>> I’ve tested the build with gfortran-mp-12  which fails:
>>>>> 
>>>>> :info:build /opt/local/bin/gfortran-mp-12 -Wall -O2 -c gencontelem_n2f.f
>>>>> :info:build gencontelem_n2f.f:595:39:
>>>>> :info:build   184 |call 
>>>>> isortii(ialset(istartset(iset)),idummy,
>>>>> :info:build   |2
>>>>> :info:build ..
>>>>> :info:build   595 | call 
>>>>> isortii(nodef,iorder,nopes,kflag)
>>>>> :info:build   |   1
>>>>> :info:build Error: Rank mismatch between actual argument at (1) and 
>>>>> actual argument at (2) (scalar and rank-1)
>>>>> :info:build make: *** [gencontelem_n2f.o] Error 1
>>>>> 
>>>>> How is a particular value of gfortran blacklisted, in this case 
>>>>> gfortran-mp-12? 
>>>> 
>>>> As Ken has eluded to, this is not a problem with the compiler, but an 
>>>> issue i. The code itself made apparent by stricter checks in recent 
>>>> compilers. You will likely run into the same with most recent versions so 
>>>> blacklisting is not the fix here.
>>>> 
>>>> The option Ken mentioned turns off those checks
>>>> 
>>>> https://github.com/macports/macports-ports/blob/8f07e286eac6e7fa7c9bcd282cc461ee945c7c8d/_resources/port1.0/group/compilers-1.0.tcl#L782
>>>>  
>>>> <https://github.com/macports/macports-ports/blob/8f07e286eac6e7fa7c9bcd282cc461ee945c7c8d/_resources/port1.0/group/compilers-1.0.tcl#L782>
>>>> 
>>>> so is definitely the way forward I would think.
>>>> 
>>>> Chris
>>>> 
>>>>> 
>>>>> Mark Brethen
>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 6, 2022, at 10:19 PM, Mark Brethen >>>>> <mailto:mark.bret...@gmail.com>> wrote:
>>>>>> 
>>>>>> The Spooles library is written in C language and has multi-threading 
>>>>>> subroutines.
>>>>>> 
>>>>>> Mark Brethen
>>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jul 6, 2022, at 5:06 PM, Joshua Root >>>>>> <mailto:j...@macports.org>> wrote:
>>>>>>> 
>>>>>>> On 2022-7-7 07:40 , Mark Brethen wrote:
>>>>>>>> The source is a combination of C and fortran, so a C-compiler with 
>>>>>>>> fortran is needed-preferably gcc. The gcc8 build is the only one that 
>>>>>>>> does not issue those warnings. But I have successfully run 
>>>>>>>> verification test cases packaged with the source against gcc8, gcc9, 
>>>>>>>> gcc11 and gfortran builds.
>>>>>>>> The compilers PortGroup sets gfortran by default with these settings:
>>>>>>>> compilers.choosefc cc
>>>>>>>> compilers.setup require_fortran -g95 -clang
>>>>>>>> But it uses clang to compile the C-code. I tried blacklisting clang 
>>>>>>>> but then it wants to install clang-14. Choosing a gcc variant uses its 
>>>>>>>> associated mp-gfortan compiler.
>>>>>>> 
>>>>>>> Yes, +gfortran is there to only give you a fortran compiler (because 
>>>>>>> clang doesn't have one). Is there a reason you need the C code to be 
>>>>>>> compiled with gcc?
>>>>>>> 
>>>>>>> - Josh
>>> 
> 

Re: fetch timeout

[Mark Brethen]

It’s interesting that curl fails from my older MacBook Air, but passes on the 
M1 iMac, both with OS 11 installed. Even after a clean reinstall. I suspect 
it’s something about Apple’s openssl. Browsers don’t seem to mind the 
certificate.

As a work around, I’d like to add something like this:

set check.os.major 21
if {${check.os.major} > ${os.major}} {
depends_fetch-append curl
fetch {
system "curl -L -o ${distpath}/${distfiles} ${master_sites}${distfiles}"
    }
}



Mark Brethen
mark.bret...@gmail.com



> On Jul 17, 2022, at 8:49 AM, Mark Brethen  wrote:
> 
> I think I’m getting to the root of the problem. I tried to obtain the SSL 
> certificate from the host server using openssl.
> 
> Downloads $ echo | openssl s_client -servername wias-berlin.de 
> <http://wias-berlin.de/> -connect wias-berlin.de:443 
> <http://wias-berlin.de:443/> |\   
>   
>   sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > certificate.crt
> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
> Center, CN = T-TeleSec GlobalRoot Class 2
> verify return:1
> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
> verify return:1
> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
> verify return:1
> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
> verify return:1
> 4479426220:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
> handshake 
> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>  alert number 40
> 4479426220:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake 
> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585:
> 
> 
> I don’t get this error on the iMac with the same OS, same openssl versions.
> 
> Mark
> 
> 
> 
>> On Jul 15, 2022, at 1:44 PM, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> Maybe it’s openssl in /opt/local/bin? On the MacBook Air:
>> 
>> ports $ which openssl
>> /opt/local/bin/openssl
>> ports $ openssl version
>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>> 
>> The iMac has /opt/local/bin/openssl 1.1.1
>> 
>> /usr/bin/openssl is libressl 2.8.3 for both.
>> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Jul 15, 2022, at 1:32 PM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> Heck if I know what’s wrong. Everything being equal, curl on the iMac 
>>> works, but on the MacBook Air it does not. Both have the same OS, same curl 
>>> version at /usr/bin, same cert.pem.
>>> 
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> 
>>> 
>>> 
>>>> On Jul 15, 2022, at 11:42 AM, Mark Brethen >>> <mailto:mark.bret...@gmail.com>> wrote:
>>>> 
>>>> On the MacBook Air openssl is able to get the certificate
>>>> 
>>>> Downloads $ openssl s_client -connect wias-berlin.de:443 
>>>> <http://wias-berlin.de:443/>
>>>> CONNECTED(0005)
>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>>> verify return:1
>>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>>> verify return:1
>>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>>> verify return:1
>>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin 
>>>> e.V., OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik 
>>>> (WIAS), OU = RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>>>> verify return:1
>>>> ---
>>>> Certificate chain
>>>>  0 s:C = DE, ST = Berlin, L = 

Re: compilers PortGroup

[Mark Brethen]

Unfortunately spooles is no longer maintained, but I found this discussion 
online:

If you compile with GCC 10 or newer, you will get the following error, 
originating from CalculiX:

Error: Rank mismatch between actual argument at (1) and actual argument at (2) 
(rank-1 and scalar)
To work around this, you need to add -fallow-argument-mismatch to the FFLAGS 
inside Makefile:

- FFLAGS = -Wall -O3 -fopenmp $(INCLUDES)
+ FFLAGS = -Wall -O3 -fopenmp -fallow-argument-mismatch $(INCLUDES)

I’ll implement this in a patch, assuming everyone is building with >+ 10? Would 
it hurt to patch it even if gcc <10?

Mark 



> On Jul 17, 2022, at 12:01 PM, Chris Jones  wrote:
> 
> Ok, shame.
> 
> Nevertheless, this is not an issue with the compiler but the code itself. You 
> might try discussing it with the upstream maintainers.
> 
> Chris
> 
>> On 17 Jul 2022, at 3:29 pm, Mark Brethen  wrote:
>> 
>> Hmm, 'compilers.allow_arguments_mismatch yes’ had no effect—same failure. I 
>> looked at the compilers group and with it set, and gfortran variant is 
>> selected, chooses ${compilers.gcc_default}. Which in my case was gcc12—which 
>> is already installed.
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Jul 17, 2022, at 6:15 AM, Chris Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> 
>>> 
>>>> On 17 Jul 2022, at 1:59 am, Mark Brethen >>> <mailto:mark.bret...@gmail.com>> wrote:
>>>> 
>>>> I’ve tested the build with gfortran-mp-12  which fails:
>>>> 
>>>> :info:build /opt/local/bin/gfortran-mp-12 -Wall -O2 -c gencontelem_n2f.f
>>>> :info:build gencontelem_n2f.f:595:39:
>>>> :info:build   184 |call 
>>>> isortii(ialset(istartset(iset)),idummy,
>>>> :info:build   |2
>>>> :info:build ..
>>>> :info:build   595 | call 
>>>> isortii(nodef,iorder,nopes,kflag)
>>>> :info:build   |   1
>>>> :info:build Error: Rank mismatch between actual argument at (1) and actual 
>>>> argument at (2) (scalar and rank-1)
>>>> :info:build make: *** [gencontelem_n2f.o] Error 1
>>>> 
>>>> How is a particular value of gfortran blacklisted, in this case 
>>>> gfortran-mp-12? 
>>> 
>>> As Ken has eluded to, this is not a problem with the compiler, but an issue 
>>> i. The code itself made apparent by stricter checks in recent compilers. 
>>> You will likely run into the same with most recent versions so blacklisting 
>>> is not the fix here.
>>> 
>>> The option Ken mentioned turns off those checks
>>> 
>>> https://github.com/macports/macports-ports/blob/8f07e286eac6e7fa7c9bcd282cc461ee945c7c8d/_resources/port1.0/group/compilers-1.0.tcl#L782
>>>  
>>> <https://github.com/macports/macports-ports/blob/8f07e286eac6e7fa7c9bcd282cc461ee945c7c8d/_resources/port1.0/group/compilers-1.0.tcl#L782>
>>> 
>>> so is definitely the way forward I would think.
>>> 
>>> Chris
>>> 
>>>> 
>>>> Mark Brethen
>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>> 
>>>> 
>>>> 
>>>>> On Jul 6, 2022, at 10:19 PM, Mark Brethen >>>> <mailto:mark.bret...@gmail.com>> wrote:
>>>>> 
>>>>> The Spooles library is written in C language and has multi-threading 
>>>>> subroutines.
>>>>> 
>>>>> Mark Brethen
>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 6, 2022, at 5:06 PM, Joshua Root >>>>> <mailto:j...@macports.org>> wrote:
>>>>>> 
>>>>>> On 2022-7-7 07:40 , Mark Brethen wrote:
>>>>>>> The source is a combination of C and fortran, so a C-compiler with 
>>>>>>> fortran is needed-preferably gcc. The gcc8 build is the only one that 
>>>>>>> does not issue those warnings. But I have successfully run verification 
>>>>>>> test cases packaged with the source against gcc8, gcc9, gcc11 and 
>>>>>>> gfortran builds.
>>>>>>> The compilers PortGroup sets gfortran by default with these settings:
>>>>>>> compilers.choosefc cc
>>>>>>> compilers.setup require_fortran -g95 -clang
>>>>>>> But it uses clang to compile the C-code. I tried blacklisting clang but 
>>>>>>> then it wants to install clang-14. Choosing a gcc variant uses its 
>>>>>>> associated mp-gfortan compiler.
>>>>>> 
>>>>>> Yes, +gfortran is there to only give you a fortran compiler (because 
>>>>>> clang doesn't have one). Is there a reason you need the C code to be 
>>>>>> compiled with gcc?
>>>>>> 
>>>>>> - Josh
>> 

Re: compilers PortGroup

[Mark Brethen]

Hmm, 'compilers.allow_arguments_mismatch yes’ had no effect—same failure. I 
looked at the compilers group and with it set, and gfortran variant is 
selected, chooses ${compilers.gcc_default}. Which in my case was gcc12—which is 
already installed.

Mark Brethen
mark.bret...@gmail.com



> On Jul 17, 2022, at 6:15 AM, Chris Jones  wrote:
> 
> 
> 
>> On 17 Jul 2022, at 1:59 am, Mark Brethen  wrote:
>> 
>> I’ve tested the build with gfortran-mp-12  which fails:
>> 
>> :info:build /opt/local/bin/gfortran-mp-12 -Wall -O2 -c gencontelem_n2f.f
>> :info:build gencontelem_n2f.f:595:39:
>> :info:build   184 |call 
>> isortii(ialset(istartset(iset)),idummy,
>> :info:build   |2
>> :info:build ..
>> :info:build   595 | call 
>> isortii(nodef,iorder,nopes,kflag)
>> :info:build   |   1
>> :info:build Error: Rank mismatch between actual argument at (1) and actual 
>> argument at (2) (scalar and rank-1)
>> :info:build make: *** [gencontelem_n2f.o] Error 1
>> 
>> How is a particular value of gfortran blacklisted, in this case 
>> gfortran-mp-12? 
> 
> As Ken has eluded to, this is not a problem with the compiler, but an issue 
> i. The code itself made apparent by stricter checks in recent compilers. You 
> will likely run into the same with most recent versions so blacklisting is 
> not the fix here.
> 
> The option Ken mentioned turns off those checks
> 
> https://github.com/macports/macports-ports/blob/8f07e286eac6e7fa7c9bcd282cc461ee945c7c8d/_resources/port1.0/group/compilers-1.0.tcl#L782
>  
> <https://github.com/macports/macports-ports/blob/8f07e286eac6e7fa7c9bcd282cc461ee945c7c8d/_resources/port1.0/group/compilers-1.0.tcl#L782>
> 
> so is definitely the way forward I would think.
> 
> Chris
> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com
>> 
>> 
>> 
>>> On Jul 6, 2022, at 10:19 PM, Mark Brethen  wrote:
>>> 
>>> The Spooles library is written in C language and has multi-threading 
>>> subroutines.
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com
>>> 
>>> 
>>> 
>>>> On Jul 6, 2022, at 5:06 PM, Joshua Root  wrote:
>>>> 
>>>> On 2022-7-7 07:40 , Mark Brethen wrote:
>>>>> The source is a combination of C and fortran, so a C-compiler with 
>>>>> fortran is needed-preferably gcc. The gcc8 build is the only one that 
>>>>> does not issue those warnings. But I have successfully run verification 
>>>>> test cases packaged with the source against gcc8, gcc9, gcc11 and 
>>>>> gfortran builds.
>>>>> The compilers PortGroup sets gfortran by default with these settings:
>>>>> compilers.choosefc cc
>>>>> compilers.setup require_fortran -g95 -clang
>>>>> But it uses clang to compile the C-code. I tried blacklisting clang but 
>>>>> then it wants to install clang-14. Choosing a gcc variant uses its 
>>>>> associated mp-gfortan compiler.
>>>> 
>>>> Yes, +gfortran is there to only give you a fortran compiler (because clang 
>>>> doesn't have one). Is there a reason you need the C code to be compiled 
>>>> with gcc?
>>>> 
>>>> - Josh

Re: fetch timeout

[Mark Brethen]

I think I’m getting to the root of the problem. I tried to obtain the SSL 
certificate from the host server using openssl.

Downloads $ echo | openssl s_client -servername wias-berlin.de -connect 
wias-berlin.de:443 |\   
  
  sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > certificate.crt
depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
Center, CN = T-TeleSec GlobalRoot Class 2
verify return:1
depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
verify return:1
depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
verify return:1
depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU 
= Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN 
= www.wias-berlin.de
verify return:1
4479426220:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
handshake 
failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
 alert number 40
4479426220:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake 
failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585:


I don’t get this error on the iMac with the same OS, same openssl versions.

Mark



> On Jul 15, 2022, at 1:44 PM, Mark Brethen  wrote:
> 
> Maybe it’s openssl in /opt/local/bin? On the MacBook Air:
> 
> ports $ which openssl
> /opt/local/bin/openssl
> ports $ openssl version
> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
> 
> The iMac has /opt/local/bin/openssl 1.1.1
> 
> /usr/bin/openssl is libressl 2.8.3 for both.
> 
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 15, 2022, at 1:32 PM, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> Heck if I know what’s wrong. Everything being equal, curl on the iMac works, 
>> but on the MacBook Air it does not. Both have the same OS, same curl version 
>> at /usr/bin, same cert.pem.
>> 
>> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> 
>> 
>> 
>>> On Jul 15, 2022, at 11:42 AM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> On the MacBook Air openssl is able to get the certificate
>>> 
>>> Downloads $ openssl s_client -connect wias-berlin.de:443 
>>> <http://wias-berlin.de:443/>
>>> CONNECTED(0005)
>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>> verify return:1
>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>> verify return:1
>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>> verify return:1
>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>>> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>>> verify return:1
>>> ---
>>> Certificate chain
>>>  0 s:C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU 
>>> = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>>> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>>>i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>>> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>>a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
>>>v:NotBefore: Aug  4 13:43:33 2021 GMT; NotAfter: Sep  4 13:43:33 2022 GMT
>>>  1 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>>> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>>i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>>> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>>>v:NotBefore: May 24 11:38:40 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
>>>  2 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>>> V., OU = DFN-PKI, CN = DFN-Verein Certification Au

Re: compilers PortGroup

[Mark Brethen]

I’ve tested the build with gfortran-mp-12  which fails:

:info:build /opt/local/bin/gfortran-mp-12 -Wall -O2 -c gencontelem_n2f.f
:info:build gencontelem_n2f.f:595:39:
:info:build   184 |call isortii(ialset(istartset(iset)),idummy,
:info:build   |2
:info:build ..
:info:build   595 | call isortii(nodef,iorder,nopes,kflag)
:info:build   |   1
:info:build Error: Rank mismatch between actual argument at (1) and actual 
argument at (2) (scalar and rank-1)
:info:build make: *** [gencontelem_n2f.o] Error 1

How is a particular value of gfortran blacklisted, in this case gfortran-mp-12? 

Mark Brethen
mark.bret...@gmail.com



> On Jul 6, 2022, at 10:19 PM, Mark Brethen  wrote:
> 
> The Spooles library is written in C language and has multi-threading 
> subroutines.
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jul 6, 2022, at 5:06 PM, Joshua Root  wrote:
>> 
>> On 2022-7-7 07:40 , Mark Brethen wrote:
>>> The source is a combination of C and fortran, so a C-compiler with fortran 
>>> is needed-preferably gcc. The gcc8 build is the only one that does not 
>>> issue those warnings. But I have successfully run verification test cases 
>>> packaged with the source against gcc8, gcc9, gcc11 and gfortran builds.
>>> The compilers PortGroup sets gfortran by default with these settings:
>>> compilers.choosefc cc
>>> compilers.setup require_fortran -g95 -clang
>>> But it uses clang to compile the C-code. I tried blacklisting clang but 
>>> then it wants to install clang-14. Choosing a gcc variant uses its 
>>> associated mp-gfortan compiler.
>> 
>> Yes, +gfortran is there to only give you a fortran compiler (because clang 
>> doesn't have one). Is there a reason you need the C code to be compiled with 
>> gcc?
>> 
>> - Josh
> 

Re: fetch timeout

[Mark Brethen]

Maybe it’s openssl in /opt/local/bin? On the MacBook Air:

ports $ which openssl
/opt/local/bin/openssl
ports $ openssl version
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)

The iMac has /opt/local/bin/openssl 1.1.1

/usr/bin/openssl is libressl 2.8.3 for both.


Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 1:32 PM, Mark Brethen  wrote:
> 
> Heck if I know what’s wrong. Everything being equal, curl on the iMac works, 
> but on the MacBook Air it does not. Both have the same OS, same curl version 
> at /usr/bin, same cert.pem.
> 
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 15, 2022, at 11:42 AM, Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> 
>> On the MacBook Air openssl is able to get the certificate
>> 
>> Downloads $ openssl s_client -connect wias-berlin.de:443 
>> <http://wias-berlin.de:443/>
>> CONNECTED(0005)
>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
>> Center, CN = T-TeleSec GlobalRoot Class 2
>> verify return:1
>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>> verify return:1
>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>> verify return:1
>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>> verify return:1
>> ---
>> Certificate chain
>>  0 s:C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU 
>> = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, 
>> CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>>i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
>>v:NotBefore: Aug  4 13:43:33 2021 GMT; NotAfter: Sep  4 13:43:33 2022 GMT
>>  1 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>>v:NotBefore: May 24 11:38:40 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
>>  2 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
>> Center, CN = T-TeleSec GlobalRoot Class 2
>>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>>v:NotBefore: Feb 22 13:38:22 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
>> ---
>> Server certificate
>> -BEGIN CERTIFICATE-
>> 
>> -END CERTIFICATE-
>> subject=C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
>> issuer=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
>> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>> ---
>> No client certificate CA names sent
>> Peer signing digest: SHA256
>> Peer signature type: RSA-PSS
>> Server Temp Key: X25519, 253 bits
>> ---
>> SSL handshake has read 5958 bytes and written 400 bytes
>> Verification: OK
>> ---
>> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
>> Server public key is 4096 bit
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> Early data was not sent
>> Verify return code: 0 (ok)
>> ---
>> ---
>> Post-Handshake New Session Ticket arrived:
>> SSL-Session:
>> Protocol  : TLSv1.3
>> Cipher: TLS_AES_256_GCM_SHA384
>> Session-ID: 
>> 59F731F1CDD19B47E950494E9EE1B8A0550BF8AC10649DB3C7232926EEC1530A
>> Session-ID-ctx: 
>> Resumption PSK: 
>> A3FDED018305178A2940F1CC082F27F0BFD32592CA51C904C07E446B5B5EEDBC496CDC1711F7E87A9AED84131B1A790C
>> PSK identity: None
>> PSK identity hint: None
>> SRP username: None
>> 

Re: fetch timeout

[Mark Brethen]

Heck if I know what’s wrong. Everything being equal, curl on the iMac works, 
but on the MacBook Air it does not. Both have the same OS, same curl version at 
/usr/bin, same cert.pem.


Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 11:42 AM, Mark Brethen  wrote:
> 
> On the MacBook Air openssl is able to get the certificate
> 
> Downloads $ openssl s_client -connect wias-berlin.de:443 
> <http://wias-berlin.de:443/>
> CONNECTED(0005)
> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
> Center, CN = T-TeleSec GlobalRoot Class 2
> verify return:1
> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
> verify return:1
> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
> verify return:1
> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
> verify return:1
> ---
> Certificate chain
>  0 s:C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU = 
> Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN 
> = www.wias-berlin.de <http://www.wias-berlin.de/>
>i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
>v:NotBefore: Aug  4 13:43:33 2021 GMT; NotAfter: Sep  4 13:43:33 2022 GMT
>  1 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: May 24 11:38:40 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
>  2 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
> Center, CN = T-TeleSec GlobalRoot Class 2
>a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>v:NotBefore: Feb 22 13:38:22 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> 
> -END CERTIFICATE-
> subject=C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
> RT, CN = www.wias-berlin.de <http://www.wias-berlin.de/>
> issuer=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
> V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Peer signature type: RSA-PSS
> Server Temp Key: X25519, 253 bits
> ---
> SSL handshake has read 5958 bytes and written 400 bytes
> Verification: OK
> ---
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
> ---
> Post-Handshake New Session Ticket arrived:
> SSL-Session:
> Protocol  : TLSv1.3
> Cipher: TLS_AES_256_GCM_SHA384
> Session-ID: 
> 59F731F1CDD19B47E950494E9EE1B8A0550BF8AC10649DB3C7232926EEC1530A
> Session-ID-ctx: 
> Resumption PSK: 
> A3FDED018305178A2940F1CC082F27F0BFD32592CA51C904C07E446B5B5EEDBC496CDC1711F7E87A9AED84131B1A790C
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> TLS session ticket lifetime hint: 300 (seconds)
> TLS session ticket:
>  - 04 c1 6f 8b 74 4d 64 1e-64 33 c2 af 4c 3d 57 07   ..o.tMd.d3..L=W.
> 0010 - b8 55 a9 29 03 a4 7c 58-7a 93 f8 48 f2 7a c6 a9   .U.)..|Xz..H.z..
> 
> Start Time: 1657903105
> Timeout   : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> Max Early Data: 0
> ---
> read R BLOCK
> ---
> Post-Handshake New Session Ticket arrived:
> SSL-Session:
> Protocol  : TLSv1.3
> Cipher: TLS_AES_256_GCM_SHA384
> Session-ID: 
> 442D3ABED4D45BD62EA3B62E38EEE60BEE8D146EAC1B5549645F78E5AEC70D70
> Session-ID-ctx: 
> Resumption PSK: 
> D32F86E1E5AE9DC8A3F551D4F4E4BAAF20448E5C7D169D12685577ADC60440556044B374436BFDAA22E6DF026FFBD77A
> PSK identity: None
> PSK identity hint: None
>

Re: fetch timeout

[Mark Brethen]

On the MacBook Air openssl is able to get the certificate

Downloads $ openssl s_client -connect wias-berlin.de:443
CONNECTED(0005)
depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
Center, CN = T-TeleSec GlobalRoot Class 2
verify return:1
depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
verify return:1
depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
verify return:1
depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU 
= Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN 
= www.wias-berlin.de
verify return:1
---
Certificate chain
 0 s:C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU = 
Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN = 
www.wias-berlin.de
   i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., 
OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  4 13:43:33 2021 GMT; NotAfter: Sep  4 13:43:33 2022 GMT
 1 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., 
OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
   i:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., 
OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May 24 11:38:40 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
 2 s:C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., 
OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
   i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust 
Center, CN = T-TeleSec GlobalRoot Class 2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 22 13:38:22 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
---
Server certificate
-BEGIN CERTIFICATE-

-END CERTIFICATE-
subject=C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU 
= Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN 
= www.wias-berlin.de
issuer=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5958 bytes and written 400 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID: 59F731F1CDD19B47E950494E9EE1B8A0550BF8AC10649DB3C7232926EEC1530A
Session-ID-ctx: 
Resumption PSK: 
A3FDED018305178A2940F1CC082F27F0BFD32592CA51C904C07E446B5B5EEDBC496CDC1711F7E87A9AED84131B1A790C
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
 - 04 c1 6f 8b 74 4d 64 1e-64 33 c2 af 4c 3d 57 07   ..o.tMd.d3..L=W.
0010 - b8 55 a9 29 03 a4 7c 58-7a 93 f8 48 f2 7a c6 a9   .U.)..|Xz..H.z..

Start Time: 1657903105
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID: 442D3ABED4D45BD62EA3B62E38EEE60BEE8D146EAC1B5549645F78E5AEC70D70
Session-ID-ctx: 
Resumption PSK: 
D32F86E1E5AE9DC8A3F551D4F4E4BAAF20448E5C7D169D12685577ADC60440556044B374436BFDAA22E6DF026FFBD77A
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
 - 5d 89 a2 5e 7a b3 18 13-89 f7 07 66 f7 52 5a d4   ]..^z..f.RZ.
0010 - 22 b4 f8 78 af 92 bf 39-16 9b 4c 63 8b fa 4d d9   "..x...9..Lc..M.

Start Time: 1657903105
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
closed

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 10:51 AM, Mark Brethen  wrote:
> 
> On the Imac (OS 11.6.7):
> 
> -rw-r--r--   1 root  wheel  346545 Jan  1  2020 cert.pem
> 
> ~ $ /usr/bin/curl --version
> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
> Release-Date: 2019-03-27
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
> pop3s rtsp smb smbs smtp smtps telnet tftp 
> F

Re: fetch timeout

[Mark Brethen]

On the Imac (OS 11.6.7):

-rw-r--r--   1 root  wheel  346545 Jan  1  2020 cert.pem

~ $ /usr/bin/curl --version
curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

Downloads $ /usr/bin/curl -L -v -o tetgen1.5.1.tar.gz 
https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 62.141.177.111...
* TCP_NODELAY set
* Connected to wias-berlin.de (62.141.177.111) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [228 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [104 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [5152 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [556 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=DE; ST=Berlin; L=Berlin; O=Forschungsverbund Berlin e.V.; 
OU=Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS); OU=RT; 
CN=www.wias-berlin.de
*  start date: Aug  4 13:43:33 2021 GMT
*  expire date: Sep  4 13:43:33 2022 GMT
*  subjectAltName: host "wias-berlin.de" matched cert's "wias-berlin.de"
*  issuer: C=DE; O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. 
V.; OU=DFN-PKI; CN=DFN-Verein Global Issuing CA
*  SSL certificate verify ok.
> GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
> Host: wias-berlin.de
> User-Agent: curl/7.64.1
> Accept: */*
> 
  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 0< 
HTTP/1.1 200 OK
< Date: Fri, 15 Jul 2022 15:43:03 GMT
< Server: Apache-Coyote/1.1
< Strict-Transport-Security: max-age=63072000
< Accept-Ranges: bytes
< ETag: W/"282433-153486310"
< Last-Modified: Tue, 21 Aug 2018 14:51:40 GMT
< Content-Type: application/x-gzip
< Content-Length: 282433
< 
{ [7906 bytes data]
100  275k  100  275k0 0   156k  0  0:00:01  0:00:01 --:--:--  156k
* Connection #0 to host wias-berlin.de left intact
* Closing connection 0

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 10:18 AM, Chris Jones  wrote:
> 
> 
> 
> On 15/07/2022 4:16 pm, Mark Brethen wrote:
>> cert.perm has the same date
> 
> very surprised ...
> 
> and. does the curl fetch also fail ?
> 
>> Mark Brethen
>> mark.bret...@gmail.com
>>> On Jul 15, 2022, at 10:11 AM, Chris Jones  wrote:
>>> 
>>> 
>>> 
>>> On 15/07/2022 4:08 pm, Mark Brethen wrote:
>>>> I checked big sur on my iMac, which came installed with big sur. It also 
>>>> has version 7.64.1.
>>> 
>>> how old is the cert.pem file though ?
>>> 
>>> Does the fetch using /usr/bin/curl work there or not ?
>>> 
>>> I’m surprised macports is using the native curl. Apple is notorious for not 
>>> updating to the latest versions of software with each new OS.
>>>> Mark Brethen
>>>> mark.bret...@gmail.com
>>>>> On Jul 15, 2022, at 9:55 AM, Chris Jones  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 15/07/2022 3:49 pm, Mark Brethen wrote:
>>>>>> -rw-r--r--1 root  wheel  346545 Jan  1  2020 cert.pem
>>>>> 
>>>>> The above could be your problem, as that is very old, 2.5 years or so 
>>>>> now. It actually pre-dates the public release of macOS 11, which wasn't 
>>>>> until November that year, which makes it quite suspicious...
>>>>> 
>>>>> In comparison mine is from May this year, on macOS12. I would imagine the 
>>>>> same on macOS 11 to be much more up to date than the above.
>>>>> 
>>>&

Re: fetch timeout

[Mark Brethen]

cert.perm has the same date

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 10:11 AM, Chris Jones  wrote:
> 
> 
> 
> On 15/07/2022 4:08 pm, Mark Brethen wrote:
>> I checked big sur on my iMac, which came installed with big sur. It also has 
>> version 7.64.1.
> 
> how old is the cert.pem file though ?
> 
> Does the fetch using /usr/bin/curl work there or not ?
> 
> I’m surprised macports is using the native curl. Apple is notorious for not 
> updating to the latest versions of software with each new OS.
>> Mark Brethen
>> mark.bret...@gmail.com
>>> On Jul 15, 2022, at 9:55 AM, Chris Jones  wrote:
>>> 
>>> 
>>> 
>>> On 15/07/2022 3:49 pm, Mark Brethen wrote:
>>>> -rw-r--r--1 root  wheel  346545 Jan  1  2020 cert.pem
>>> 
>>> The above could be your problem, as that is very old, 2.5 years or so now. 
>>> It actually pre-dates the public release of macOS 11, which wasn't until 
>>> November that year, which makes it quite suspicious...
>>> 
>>> In comparison mine is from May this year, on macOS12. I would imagine the 
>>> same on macOS 11 to be much more up to date than the above.
>>> 
>>> This could be some relic of your big update from OSX10.13 to macOS11...
>>> 
>>> So, I am not sure how, but you need the above to be updated I believe...
>>> 
>>> Have you checked system update to make sure you are fully up to date ?
>>> 
>>> Chris
>>> 
>>>> ~ $ /usr/bin/curl --version
>>>> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
>>>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
>>>> Release-Date: 2019-03-27
>>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
>>>> pop3s rtsp smb smbs smtp smtps telnet tftp
>>>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
>>>> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>>>> Mark Brethen
>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>> On Jul 15, 2022, at 9:44 AM, Chris Jones >>>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>>>> 
>>>>> /etc/ssl/cert.pem

Re: fetch timeout

[Mark Brethen]

I checked big sur on my iMac, which came installed with big sur. It also has 
version 7.64.1. I’m surprised macports is using the native curl. Apple is 
notorious for not updating to the latest versions of software with each new OS.


Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 9:55 AM, Chris Jones  wrote:
> 
> 
> 
> On 15/07/2022 3:49 pm, Mark Brethen wrote:
>> -rw-r--r--1 root  wheel  346545 Jan  1  2020 cert.pem
> 
> The above could be your problem, as that is very old, 2.5 years or so now. It 
> actually pre-dates the public release of macOS 11, which wasn't until 
> November that year, which makes it quite suspicious...
> 
> In comparison mine is from May this year, on macOS12. I would imagine the 
> same on macOS 11 to be much more up to date than the above.
> 
> This could be some relic of your big update from OSX10.13 to macOS11...
> 
> So, I am not sure how, but you need the above to be updated I believe...
> 
> Have you checked system update to make sure you are fully up to date ?
> 
> Chris
> 
>> ~ $ /usr/bin/curl --version
>> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
>> Release-Date: 2019-03-27
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
>> pop3s rtsp smb smbs smtp smtps telnet tftp
>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
>> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> On Jul 15, 2022, at 9:44 AM, Chris Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> /etc/ssl/cert.pem

Re: fetch timeout

[Mark Brethen]

-rw-r--r--1 root  wheel  346545 Jan  1  2020 cert.pem

~ $ /usr/bin/curl --version
curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) 
LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz 
MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 9:44 AM, Chris Jones  wrote:
> 
> /etc/ssl/cert.pem

Re: fetch timeout

[Mark Brethen]

What about the system certificate trust policy? I don’t know what the default 
setting is.


Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 9:30 AM, Mark Brethen  wrote:
> 
> I was trying to say that I skipped versions and upgraded from high sierra to 
> big sur. As to the version, is it 10.16 or 11? System profiler says this:
> 
> System Software Overview:
> 
>   System Version: macOS 11.6.7 (20G630)
>   Kernel Version: Darwin 20.6.0
>   Boot Volume:Macintosh HD
>   Boot Mode:  Normal
>   Computer Name:      brethen-air
>   User Name:  Mark Brethen (marbre)
>   Secure Virtual Memory:  Enabled
>   System Integrity Protection:Enabled
>   Time since boot:10 days 18:45
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 15, 2022, at 9:23 AM, Chris Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> 
>> 
>> On 15/07/2022 3:20 pm, Mark Brethen wrote:
>>> I have big sur installed (In the ‘About This Mac’ it lists ‘Version11.6.7')
>> 
>> Sorry but you are being damn confusing. Why did you then mention 'High 
>> Sierra' as your OS below 
>> 
>> If you truly do have macOS11 installed, fully up to date, then I am very 
>> surprised you are seeing SSL issues can anyone else on this OS confirm 
>> if they see the same issue...
>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>> On Jul 15, 2022, at 9:14 AM, Chris Jones  wrote:
>>>> 
>>>> 
>>>> 
>>>> On 15/07/2022 3:08 pm, Mark Brethen wrote:
>>>>> ~ $ /usr/bin/curl -L -v -o tetgen1.5.1.tar.gz 
>>>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>>>>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>>>> Current
>>>>>  Dload  Upload   Total   SpentLeft  
>>>>> Speed
>>>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--  
>>>>>0*   Trying 62.141.177.111...
>>>>> * TCP_NODELAY set
>>>>> * Connected to wias-berlin.de <http://wias-berlin.de> (62.141.177.111) 
>>>>> port 443 (#0)
>>>>> * ALPN, offering h2
>>>>> * ALPN, offering http/1.1
>>>>> * successfully set certificate verify locations:
>>>>> *   CAfile: /etc/ssl/cert.pem
>>>>>   CApath: none
>>>>> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
>>>>> } [228 bytes data]
>>>>> * TLSv1.2 (IN), TLS handshake, Server hello (2):
>>>>> { [59 bytes data]
>>>>> * TLSv1.2 (IN), TLS handshake, Certificate (11):
>>>>> { [6122 bytes data]
>>>>> * TLSv1.2 (IN), TLS alert, handshake failure (552):
>>>>> { [2 bytes data]
>>>>> * error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake 
>>>>> failure
>>>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--  
>>>>>0
>>>>> * Closing connection 0
>>>>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>>>>> handshake failure
>>>>> Other than updating the system from High Sierra, nothing else. It sounds 
>>>>> like I may need to update my certificates?
>>>> 
>>>> Oh You said you where on macOS 11... I guess that was incorrect and 
>>>> you really mean OSX 10.11 or what ? High Sierra is OSX 10.13 ... 
>>>> Please try and be precise in your OS version as in this case it really 
>>>> makes a difference...
>>>> 
>>>> So, assuming you are on 10.11, or 10.13... That OS is indeed old and known 
>>>> to have SSL issues. The best solution is indeed to upgrade to a newer OS 
>>>> (for many many reasons...)
>>>> 
> 

Re: fetch timeout

[Mark Brethen]

I was trying to say that I skipped versions and upgraded from high sierra to 
big sur. As to the version, is it 10.16 or 11? System profiler says this:

System Software Overview:

  System Version:   macOS 11.6.7 (20G630)
  Kernel Version:   Darwin 20.6.0
  Boot Volume:  Macintosh HD
  Boot Mode:Normal
  Computer Name:brethen-air
  User Name:Mark Brethen (marbre)
  Secure Virtual Memory:Enabled
  System Integrity Protection:  Enabled
  Time since boot:  10 days 18:45

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 9:23 AM, Chris Jones  wrote:
> 
> 
> 
> On 15/07/2022 3:20 pm, Mark Brethen wrote:
>> I have big sur installed (In the ‘About This Mac’ it lists ‘Version11.6.7')
> 
> Sorry but you are being damn confusing. Why did you then mention 'High 
> Sierra' as your OS below 
> 
> If you truly do have macOS11 installed, fully up to date, then I am very 
> surprised you are seeing SSL issues can anyone else on this OS confirm if 
> they see the same issue...
> 
>> Mark Brethen
>> mark.bret...@gmail.com
>>> On Jul 15, 2022, at 9:14 AM, Chris Jones  wrote:
>>> 
>>> 
>>> 
>>> On 15/07/2022 3:08 pm, Mark Brethen wrote:
>>>> ~ $ /usr/bin/curl -L -v -o tetgen1.5.1.tar.gz 
>>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>>>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>>> Current
>>>>  Dload  Upload   Total   SpentLeft  
>>>> Speed
>>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--   
>>>>   0*   Trying 62.141.177.111...
>>>> * TCP_NODELAY set
>>>> * Connected to wias-berlin.de <http://wias-berlin.de> (62.141.177.111) 
>>>> port 443 (#0)
>>>> * ALPN, offering h2
>>>> * ALPN, offering http/1.1
>>>> * successfully set certificate verify locations:
>>>> *   CAfile: /etc/ssl/cert.pem
>>>>   CApath: none
>>>> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
>>>> } [228 bytes data]
>>>> * TLSv1.2 (IN), TLS handshake, Server hello (2):
>>>> { [59 bytes data]
>>>> * TLSv1.2 (IN), TLS handshake, Certificate (11):
>>>> { [6122 bytes data]
>>>> * TLSv1.2 (IN), TLS alert, handshake failure (552):
>>>> { [2 bytes data]
>>>> * error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake 
>>>> failure
>>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--   
>>>>   0
>>>> * Closing connection 0
>>>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>>>> handshake failure
>>>> Other than updating the system from High Sierra, nothing else. It sounds 
>>>> like I may need to update my certificates?
>>> 
>>> Oh You said you where on macOS 11... I guess that was incorrect and you 
>>> really mean OSX 10.11 or what ? High Sierra is OSX 10.13 ... Please try 
>>> and be precise in your OS version as in this case it really makes a 
>>> difference...
>>> 
>>> So, assuming you are on 10.11, or 10.13... That OS is indeed old and known 
>>> to have SSL issues. The best solution is indeed to upgrade to a newer OS 
>>> (for many many reasons...)
>>> 

Re: fetch timeout

[Mark Brethen]

I have big sur installed (In the ‘About This Mac’ it lists ‘Version11.6.7')


Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 9:14 AM, Chris Jones  wrote:
> 
> 
> 
> On 15/07/2022 3:08 pm, Mark Brethen wrote:
>> ~ $ /usr/bin/curl -L -v -o tetgen1.5.1.tar.gz 
>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>>  Dload  Upload   Total   SpentLeft  Speed
>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
>> 0*   Trying 62.141.177.111...
>> * TCP_NODELAY set
>> * Connected to wias-berlin.de <http://wias-berlin.de> (62.141.177.111) port 
>> 443 (#0)
>> * ALPN, offering h2
>> * ALPN, offering http/1.1
>> * successfully set certificate verify locations:
>> *   CAfile: /etc/ssl/cert.pem
>>   CApath: none
>> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
>> } [228 bytes data]
>> * TLSv1.2 (IN), TLS handshake, Server hello (2):
>> { [59 bytes data]
>> * TLSv1.2 (IN), TLS handshake, Certificate (11):
>> { [6122 bytes data]
>> * TLSv1.2 (IN), TLS alert, handshake failure (552):
>> { [2 bytes data]
>> * error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake 
>> failure
>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- >> 0
>> * Closing connection 0
>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>> handshake failure
>> Other than updating the system from High Sierra, nothing else. It sounds 
>> like I may need to update my certificates?
> 
> Oh You said you where on macOS 11... I guess that was incorrect and you 
> really mean OSX 10.11 or what ? High Sierra is OSX 10.13 ... Please try 
> and be precise in your OS version as in this case it really makes a 
> difference...
> 
> So, assuming you are on 10.11, or 10.13... That OS is indeed old and known to 
> have SSL issues. The best solution is indeed to upgrade to a newer OS (for 
> many many reasons...)
> 

Re: fetch timeout

[Mark Brethen]

~ $ /usr/bin/curl -L -v -o tetgen1.5.1.tar.gz 
https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 62.141.177.111...
* TCP_NODELAY set
* Connected to wias-berlin.de (62.141.177.111) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [228 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [59 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [6122 bytes data]
* TLSv1.2 (IN), TLS alert, handshake failure (552):
{ [2 bytes data]
* error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
handshake failure

Other than updating the system from High Sierra, nothing else. It sounds like I 
may need to update my certificates?

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 8:55 AM, Chris Jones  wrote:
> 
> 
> 
> On 15/07/2022 2:53 pm, Mark Brethen wrote:
>> Indeed, I get the same error
>> ~ $ /usr/bin/curl -L -o tetgen1.5.1.tar.gz 
>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz 
>> <https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz>
>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>>  Dload  Upload   Total   SpentLeft  Speed
>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- >> 0
>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
>> handshake failure
> 
> right. So this usually means your SSL certs are not up to date. Are you doing 
> anything 'special' in this regard, as I am a little surprised to see this on 
> macOS11, which isn't exactly an old OS, so I would expect it to work with an 
> up to date OS ?
> 
> Can someone on macOS11 or older give the above a try ? I only have access to 
> macOS12 and its fine there for me.
> 
> Chris
> 
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> On Jul 15, 2022, at 8:49 AM, Chris Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> 
>>> 
>>> :debug:fetch Fetching distfile failed: error:14008410:SSL 
>>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
>>> 
>>> that is your problem.
>>> 
>>> Can you reproduce the above by using the system curl (which is effectively) 
>>> what macports uses
>>> 
>>> /usr/bin/curl -L -o tetgen1.5.1.tar.gz 
>>> http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz>
>>> 
>>> On 15/07/2022 2:44 pm, Chris Jones wrote:
>>>> That is not what I asked...
>>>> You shouldn't have to override the fetch phase. I think you are probably 
>>>> looking in the wrong place for your issue, but without seeing the portfile 
>>>> and the exact error you get no one is going to be able to help you that 
>>>> much...
>>>> On 15/07/2022 2:39 pm, Mark Brethen wrote:
>>>>> 
>>>>> 
>>>>> Overriding fetch in the portfile does work.
>>>>> 
>>>>> Mark Brethen
>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 15, 2022, at 8:26 AM, Chris Jones  
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> OK, so next please post the portfile you are testing, and exactly what 
>>>>>> you get from the fetch phase when you run
>>>>>> 
>>>>>>> sudo port -d fetch xyz
>>>>>> 
>>>>>> On 15/07/2022 2:12 pm, Mark Brethen wrote:
>>>>>>> macOS 11.6.7
>>>>>>> Mark Brethen
>>>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>>>>> On Jul 15, 2022, at 8:10 AM, Mark Brethen >>>>>>> <mailto:mark.bret...@gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> ~ $ which curl
>>>>>>>> /opt/local/bin/

Re: fetch timeout

[Mark Brethen]

Indeed, I get the same error

~ $ /usr/bin/curl -L -o tetgen1.5.1.tar.gz 
https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert 
handshake failure


Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 8:49 AM, Chris Jones  wrote:
> 
> 
> :debug:fetch Fetching distfile failed: error:14008410:SSL 
> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
> 
> that is your problem.
> 
> Can you reproduce the above by using the system curl (which is effectively) 
> what macports uses
> 
> /usr/bin/curl -L -o tetgen1.5.1.tar.gz 
> http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz
> 
> On 15/07/2022 2:44 pm, Chris Jones wrote:
>> That is not what I asked...
>> You shouldn't have to override the fetch phase. I think you are probably 
>> looking in the wrong place for your issue, but without seeing the portfile 
>> and the exact error you get no one is going to be able to help you that 
>> much...
>> On 15/07/2022 2:39 pm, Mark Brethen wrote:
>>> 
>>> 
>>> Overriding fetch in the portfile does work.
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com
>>> 
>>> 
>>> 
>>>> On Jul 15, 2022, at 8:26 AM, Chris Jones  wrote:
>>>> 
>>>> 
>>>> OK, so next please post the portfile you are testing, and exactly what you 
>>>> get from the fetch phase when you run
>>>> 
>>>>> sudo port -d fetch xyz
>>>> 
>>>> On 15/07/2022 2:12 pm, Mark Brethen wrote:
>>>>> macOS 11.6.7
>>>>> Mark Brethen
>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>>> On Jul 15, 2022, at 8:10 AM, Mark Brethen >>>>> <mailto:mark.bret...@gmail.com>> wrote:
>>>>>> 
>>>>>> ~ $ which curl
>>>>>> /opt/local/bin/curl
>>>>>> 
>>>>>> Mark Brethen
>>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jul 15, 2022, at 8:09 AM, Chris Jones >>>>>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> what curl are you using ? System of macports version ?
>>>>>>> 
>>>>>>> What OS are you on ?
>>>>>>> 
>>>>>>> On 15/07/2022 2:01 pm, Mark Brethen wrote:
>>>>>>>> Have to follow a redirected file. This worked in terminal:
>>>>>>>> ~ $ curl -L -o tetgen1.5.1.tar.gz 
>>>>>>>> http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>>>>>>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz> 
>>>>>>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>>>>>>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz>>
>>>>>>>>% Total% Received % Xferd  Average Speed   TimeTime 
>>>>>>>> Time  Current
>>>>>>>>       Dload  Upload   Total   Spent
>>>>>>>> Left  Speed
>>>>>>>>0 00 00 0  0  0 --:--:-- --:--:-- 
>>>>>>>> --:--:-- 0
>>>>>>>> 100   273  100   2730 0534  0 --:--:-- --:--:-- 
>>>>>>>> --:--:--  0
>>>>>>>> 100  275k  100  275k0 0   187k  0  0:00:01  0:00:01 
>>>>>>>> --:--:--  187k
>>>>>>>> Unless there is a way to set this up in the portfile, I’ll need to 
>>>>>>>> override the fetch phase.
>>>>>>>> Mark Brethen
>>>>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> 
>>>>>>>> <mailto:mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>
>>>>>>>>> On Jul 15, 2022, at 7:21 AM, Mark Brethen >>>>>>>> <mailto:mark.bret...@gmail.com> <mailto:mark.bret...@gmail.com 
>>>>>>>>> <mailto:mark.bret...@gmail.com>>> wrote:
>>>>>>>>> 
>>>>>>>>> The next logical question is what agent do I use? Is there a Macports 
>>>>>>>>> user agent?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Mark Brethen
>>>>>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> 
>>>>>>>>> <mailto:mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Jul 14, 2022, at 8:19 PM, Joshua Root >>>>>>>>> <mailto:j...@macports.org> <mailto:j...@macports.org 
>>>>>>>>>> <mailto:j...@macports.org>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> fetch.user_agent
>>>>>>>>> 
>>>>>> 
>>> 

Re: fetch timeout

[Mark Brethen]

Portfile
Description: Binary data


main.log
Description: Binary data


Overriding fetch in the portfile does work.

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 8:26 AM, Chris Jones  wrote:
> 
> 
> OK, so next please post the portfile you are testing, and exactly what you 
> get from the fetch phase when you run
> 
> > sudo port -d fetch xyz
> 
> On 15/07/2022 2:12 pm, Mark Brethen wrote:
>> macOS 11.6.7
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> On Jul 15, 2022, at 8:10 AM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> ~ $ which curl
>>> /opt/local/bin/curl
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> 
>>> 
>>> 
>>>> On Jul 15, 2022, at 8:09 AM, Chris Jones >>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>>> 
>>>> 
>>>> what curl are you using ? System of macports version ?
>>>> 
>>>> What OS are you on ?
>>>> 
>>>> On 15/07/2022 2:01 pm, Mark Brethen wrote:
>>>>> Have to follow a redirected file. This worked in terminal:
>>>>> ~ $ curl -L -o tetgen1.5.1.tar.gz 
>>>>> http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>>>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz> 
>>>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>>>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz>>
>>>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>>>> Current
>>>>>  Dload  Upload   Total   SpentLeft  
>>>>> Speed
>>>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--  
>>>>>0
>>>>> 100   273  100   2730 0534  0 --:--:-- --:--:-- --:--:--  
>>>>> 0
>>>>> 100  275k  100  275k0 0   187k  0  0:00:01  0:00:01 --:--:--  
>>>>> 187k
>>>>> Unless there is a way to set this up in the portfile, I’ll need to 
>>>>> override the fetch phase.
>>>>> Mark Brethen
>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> 
>>>>> <mailto:mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>
>>>>>> On Jul 15, 2022, at 7:21 AM, Mark Brethen >>>>> <mailto:mark.bret...@gmail.com> <mailto:mark.bret...@gmail.com 
>>>>>> <mailto:mark.bret...@gmail.com>>> wrote:
>>>>>> 
>>>>>> The next logical question is what agent do I use? Is there a Macports 
>>>>>> user agent?
>>>>>> 
>>>>>> 
>>>>>> Mark Brethen
>>>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> 
>>>>>> <mailto:mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jul 14, 2022, at 8:19 PM, Joshua Root >>>>>> <mailto:j...@macports.org> <mailto:j...@macports.org 
>>>>>>> <mailto:j...@macports.org>>> wrote:
>>>>>>> 
>>>>>>> fetch.user_agent
>>>>>> 
>>> 

Re: fetch timeout

[Mark Brethen]

macOS 11.6.7

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 8:10 AM, Mark Brethen  wrote:
> 
> ~ $ which curl
> /opt/local/bin/curl
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 15, 2022, at 8:09 AM, Chris Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> 
>> what curl are you using ? System of macports version ?
>> 
>> What OS are you on ?
>> 
>> On 15/07/2022 2:01 pm, Mark Brethen wrote:
>>> Have to follow a redirected file. This worked in terminal:
>>> ~ $ curl -L -o tetgen1.5.1.tar.gz 
>>> http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz> 
>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz>>
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>>  Dload  Upload   Total   SpentLeft  
>>> Speed
>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>>>  0
>>> 100   273  100   2730 0534  0 --:--:-- --:--:-- --:--:--
>>>   0
>>> 100  275k  100  275k0 0   187k  0  0:00:01  0:00:01 --:--:--  
>>> 187k
>>> Unless there is a way to set this up in the portfile, I’ll need to override 
>>> the fetch phase.
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> 
>>> <mailto:mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>
>>>> On Jul 15, 2022, at 7:21 AM, Mark Brethen >>> <mailto:mark.bret...@gmail.com> <mailto:mark.bret...@gmail.com 
>>>> <mailto:mark.bret...@gmail.com>>> wrote:
>>>> 
>>>> The next logical question is what agent do I use? Is there a Macports user 
>>>> agent?
>>>> 
>>>> 
>>>> Mark Brethen
>>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> 
>>>> <mailto:mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>>
>>>> 
>>>> 
>>>> 
>>>>> On Jul 14, 2022, at 8:19 PM, Joshua Root >>>> <mailto:j...@macports.org> <mailto:j...@macports.org 
>>>>> <mailto:j...@macports.org>>> wrote:
>>>>> 
>>>>> fetch.user_agent
>>>> 
> 

Re: fetch timeout

[Mark Brethen]

~ $ which curl
/opt/local/bin/curl

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 8:09 AM, Chris Jones  wrote:
> 
> 
> what curl are you using ? System of macports version ?
> 
> What OS are you on ?
> 
> On 15/07/2022 2:01 pm, Mark Brethen wrote:
>> Have to follow a redirected file. This worked in terminal:
>> ~ $ curl -L -o tetgen1.5.1.tar.gz 
>> http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz 
>> <http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz>
>>   % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>>  Dload  Upload   Total   SpentLeft  Speed
>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- >> 0
>> 100   273  100   2730 0534  0 --:--:-- --:--:-- --:--:-- 
>>  0
>> 100  275k  100  275k0 0   187k  0  0:00:01  0:00:01 --:--:--  
>> 187k
>> Unless there is a way to set this up in the portfile, I’ll need to override 
>> the fetch phase.
>> Mark Brethen
>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> On Jul 15, 2022, at 7:21 AM, Mark Brethen >> <mailto:mark.bret...@gmail.com>> wrote:
>>> 
>>> The next logical question is what agent do I use? Is there a Macports user 
>>> agent?
>>> 
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>>> 
>>> 
>>> 
>>>> On Jul 14, 2022, at 8:19 PM, Joshua Root >>> <mailto:j...@macports.org>> wrote:
>>>> 
>>>> fetch.user_agent
>>> 

Re: fetch timeout

[Mark Brethen]

Have to follow a redirected file. This worked in terminal:

~ $ curl -L -o tetgen1.5.1.tar.gz 
http://www.tetgen.org/1.5/src/tetgen1.5.1.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100   273  100   2730 0534  0 --:--:-- --:--:-- --:--:-- 0
100  275k  100  275k0 0   187k  0  0:00:01  0:00:01 --:--:--  187k

Unless there is a way to set this up in the portfile, I’ll need to override the 
fetch phase.

Mark Brethen
mark.bret...@gmail.com



> On Jul 15, 2022, at 7:21 AM, Mark Brethen  wrote:
> 
> The next logical question is what agent do I use? Is there a Macports user 
> agent?
> 
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 14, 2022, at 8:19 PM, Joshua Root > <mailto:j...@macports.org>> wrote:
>> 
>> fetch.user_agent 
> 

Re: fetch timeout

[Mark Brethen]

The next logical question is what agent do I use? Is there a Macports user 
agent?


Mark Brethen
mark.bret...@gmail.com



> On Jul 14, 2022, at 8:19 PM, Joshua Root  wrote:
> 
> fetch.user_agent 

fetch timeout

[Mark Brethen]

Can the timeout be set for fetch? Reason I ask is the download URL works from a 
browser but not using 'port fetch’.

Thanks

Mark Brethen
mark.bret...@gmail.com

Re: compilers PortGroup

[Mark Brethen]

I have the compiler.setup so that gfortran is selected by default, however 
checking the build log I’m seeing these warning messages:

Warning: Fortran 2018 deleted feature: DO termination statement which is not 
END DO or CONTINUE with label 215 at (1)

Warning: Fortran 2018 deleted feature: Arithmetic IF statement at (1)


Those messages are only warnings. But to side-step these issues, do I need to 
add the -std option to specify which version of the fortran standard to use 
when compiling?

E.g. compiler.c_standard   2008

Thanks
Mark



> On Jul 4, 2022, at 9:36 AM, Mark Brethen  wrote:
> 
> Sorry for the confusion, 'sudo port build xyx'.
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jul 4, 2022, at 9:07 AM, Joshua Root  wrote:
>> 
>> On 2022-7-4 23:24 , Mark Brethen wrote:
>>> Here’s what I’ve observed:
>>> compilers.choose fc cc
>>> compiler.setup  require_fortran -g95 -clang
>>> If I issue sudo port xyz +gcc11, I get ${configure.cc} = /usr/bin/clang.
>> 
>> What is xyz? When are you reading the variable? If it's before the variants 
>> execute, you won't see the changes they make.
>> 
>> - Josh
> 

Re: tagging URLs?

[Mark Brethen]

master_siteshttp://www.dhondt.de/:ccx \
http://www.netlib.org/linalg/spooles/:spooles

distfiles   ${distname}.src.tar.bz2:ccx \
${distname}.htm.tar.bz2:ccx \
${distname}.test.tar.bz2:ccx \
spooles.2.2.tgz:spooles

A basic installation of ccx for multi-threading (MT) requires external solvers 
SPOOLES and ARPACK. An ARPACK port already exists but not SPOOLES. As for build 
requirements, g++ is required for the compilation of the c-routines and 
gfortran is required for the compilation of the Fortran-routines. Config does 
not exist in the sources; either the Makefiles have to patched or the 
environment has to be passed in build.args.

SPOOLES 2.2 is the last version released; it is no longer maintained so is not 
a good port candidate. Instead it will be static linked to ccx by default.

Right now I'm having issues with the compiler setup working.

Mark Brethen
mark.bret...@gmail.com



> On Jul 4, 2022, at 4:20 PM, Joshua Root  wrote:
> 
> On 2022-7-5 06:56 , Mark Brethen wrote:
>> How does one tag a URL using mirror:subdirectory:tag? For example: 
>> http://www.netlib/org/linalg/spooles. I can’t figure it out.
> 
> What are you trying to accomplish? When specifying a full URL like in your 
> example, it's only useful to use a tag so that multiple distfiles can be 
> downloaded from different places (any subdir will just be part of the URL).
> 
> For an example of using both a subdir and a tag with a mirror group, see 
> py-bootstrap-modules. The Guide has some relevant examples as well.
> 
> - Josh

Re: tagging URLs?

[Mark Brethen]

Doh! Only one colon is needed—not two.

Mark Brethen
mark.bret...@gmail.com



> On Jul 4, 2022, at 3:56 PM, Mark Brethen  wrote:
> 
> How does one tag a URL using mirror:subdirectory:tag? For example: 
> http://www.netlib/org/linalg/spooles. I can’t figure it out.
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 

tagging URLs?

[Mark Brethen]

How does one tag a URL using mirror:subdirectory:tag? For example: 
http://www.netlib/org/linalg/spooles. I can’t figure it out.

Mark Brethen
mark.bret...@gmail.com

Re: compilers PortGroup

[Mark Brethen]

Sorry for the confusion, 'sudo port build xyx'.

Mark Brethen
mark.bret...@gmail.com



> On Jul 4, 2022, at 9:07 AM, Joshua Root  wrote:
> 
> On 2022-7-4 23:24 , Mark Brethen wrote:
>> Here’s what I’ve observed:
>> compilers.choose fc cc
>> compiler.setup  require_fortran -g95 -clang
>> If I issue sudo port xyz +gcc11, I get ${configure.cc} = /usr/bin/clang.
> 
> What is xyz? When are you reading the variable? If it's before the variants 
> execute, you won't see the changes they make.
> 
> - Josh

Re: compilers PortGroup

[Mark Brethen]

Here’s what I’ve observed:

compilers.choose fc cc
compiler.setup  require_fortran -g95 -clang 

If I issue sudo port xyz +gcc11, I get ${configure.cc} = /usr/bin/clang.


 


Mark Brethen
mark.bret...@gmail.com



> On Jul 3, 2022, at 4:29 PM, David Strubbe  wrote:
> 
> Hello Mark,
> 
> Don't whitelist a particular one that you think works; blacklist ones that 
> you know don't work.
> Additionally, I wonder if you are actually using the result of the compilers 
> portgroup. You have to tell it to use the compiler from the variants for e.g. 
> CC. See examples on that. If you don't do this, it has no effect on what is 
> used. Yes there are also some subtleties about different versions of 
> compilers as stated here: 
> https://trac.macports.org/wiki/UsingTheRightCompiler 
> <https://trac.macports.org/wiki/UsingTheRightCompiler>
> 
> David
> 
> On Sun, Jul 3, 2022 at 2:16 PM Mark Brethen  <mailto:mark.bret...@gmail.com>> wrote:
> Having looked at the examples, this one is similar to what I tried (and fails 
> to build):
> 
> compilers.choosefc cc
> compilers.setup require_fortran -g95 -clang
> 
> :info:build make: *** [ccx_2.18.a] Error 1
> :info:build make: Leaving directory 
> `/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src'
> :info:build Command failed:  cd 
> "/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src"
>  && /usr/bin/make -j1 -w CC=/usr/bin/clang FC= CFLAGS="-O2 
> -I../../spooles-2.2/ -DARCH=Linux -DSPOOLES -DARPACK -DMATRIXSTORAGE 
> -DUSE_MT=1" DIR="../../spooles-2.2" 
> :info:build Exit code: 2
> :error:build Failed to build CalculiX-ccx: command execution failed
> :debug:build Error code: CHILDSTATUS 48534 2
> :debug:build Backtrace: command execution failed
> :debug:build while executing
> :debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
> :debug:build invoked from within
> :debug:build "command_exec -callback portprogress::target_progress_callback 
> build"
> :debug:build (procedure "portbuild::build_main" line 8)
> :debug:build invoked from within
> :debug:build "$procedure $targetname"
> 
> 
> whereas adding a whitelist succeeds (using gfortran):
> 
> compiler.whitelist  macports-gcc-11
> compilers.choosefc cc
> compilers.setup require_fortran -g95 -clang
> 
> Is this a difference between mp and apple gcc?
> 
> 
> Mark Brethen
> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> 
> 
> 
>> On Jul 3, 2022, at 2:50 PM, David Strubbe > <mailto:dstru...@macports.org>> wrote:
>> 
>> Hello Mark,
>> 
>> I think you may have a basic misunderstanding here. The compilers portgroup 
>> provides variants that select compilers, rather than being a way to select 
>> the compiler in the portfile. It will provide gcc/gfortran (in specific 
>> versions). If something like clang doesn't work, you remove it from the 
>> variants list. "active_variants" is about compatibility of compilers used by 
>> dependences. As far as I know, variants are definitely still the recommended 
>> way of handling compiler selection. I suggest you look at some examples to 
>> see how to use compilers portgroup. I made many in the science category, 
>> such as octopus, sparskit, berkeleygw, libxc.
>> 
>> David
>> 
>> On Sat, Jul 2, 2022 at 4:20 PM Mark Brethen > <mailto:mark.bret...@gmail.com>> wrote:
>> This port does not have config, so I’m having to pass the build args. How do 
>> I specify a gcc (gfortran) compiler? Clang doesn’t work.
>> 
>> Thanks,
>> Mark
>> 
>> 
>> 
>> > On Jul 2, 2022, at 2:21 PM, Mark Brethen > > <mailto:mark.bret...@gmail.com>> wrote:
>> > 
>> > Still not working…
>> > 
>> > 
>> > 
>> > Mark Brethen
>> > mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> > 
>> > 
>> > 
>> >> On Jul 2, 2022, at 2:15 PM, Mark Brethen > >> <mailto:mark.bret...@gmail.com>> wrote:
>> >> 
>> >> I should have looked at the active-variants tcl:
>> >> 
>> >> require_active_variants arpack accelerate mpich
>> >> 
>> >> should be
>> >> 
>> >> require_active_variants arpack "accelerate mpich"
>> >> 
>> >> Mark Brethen
>> >> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
>> >> 
>> >> 
>> >> 
>> >>> On Jul 2, 2022, at 1:48 PM, Mark Brethen > >>> <mailto:mark.bret...@gmail.com>> wrote:
>> >>> 
>> >>> Attaching log
>> >>> 
>> >>> 
>> >>> Mark
>> >>> 
>> >>> 
>> >>> 
>> >>>> On Jul 2, 2022, at 9:22 AM, Mark Brethen > >>>> <mailto:mark.bret...@gmail.com>> wrote:
>> >>>> 
>> >>>> I looked at the compilers PortGroup tcl but can’t figure out how to set 
>> >>>> up gcc (for gfortran). I tried setting "compilers.choose cc” and 
>> >>>> “compilers.setup require_fortran” but it continues to use clang.
>> >>>> 
>> >>>> Thanks
>> >>>> Mark
>> >>>> 
>> >>>> 
>> >>> 
>> >> 
>> > 
>> 
> 

Re: compilers PortGroup

[Mark Brethen]

Having looked at the examples, this one is similar to what I tried (and fails 
to build):

compilers.choosefc cc
compilers.setup require_fortran -g95 -clang

:info:build make: *** [ccx_2.18.a] Error 1
:info:build make: Leaving directory 
`/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src'
:info:build Command failed:  cd 
"/opt/local/var/macports/build/_Users_marbre_ports_cad_CalculiX-ccx/CalculiX-ccx/work/ccx_2.18/src"
 && /usr/bin/make -j1 -w CC=/usr/bin/clang FC= CFLAGS="-O2 -I../../spooles-2.2/ 
-DARCH=Linux -DSPOOLES -DARPACK -DMATRIXSTORAGE -DUSE_MT=1" 
DIR="../../spooles-2.2" 
:info:build Exit code: 2
:error:build Failed to build CalculiX-ccx: command execution failed
:debug:build Error code: CHILDSTATUS 48534 2
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback 
build"
:debug:build (procedure "portbuild::build_main" line 8)
:debug:build invoked from within
:debug:build "$procedure $targetname"


whereas adding a whitelist succeeds (using gfortran):

compiler.whitelist  macports-gcc-11
compilers.choosefc cc
compilers.setup require_fortran -g95 -clang

Is this a difference between mp and apple gcc?


Mark Brethen
mark.bret...@gmail.com



> On Jul 3, 2022, at 2:50 PM, David Strubbe  wrote:
> 
> Hello Mark,
> 
> I think you may have a basic misunderstanding here. The compilers portgroup 
> provides variants that select compilers, rather than being a way to select 
> the compiler in the portfile. It will provide gcc/gfortran (in specific 
> versions). If something like clang doesn't work, you remove it from the 
> variants list. "active_variants" is about compatibility of compilers used by 
> dependences. As far as I know, variants are definitely still the recommended 
> way of handling compiler selection. I suggest you look at some examples to 
> see how to use compilers portgroup. I made many in the science category, such 
> as octopus, sparskit, berkeleygw, libxc.
> 
> David
> 
> On Sat, Jul 2, 2022 at 4:20 PM Mark Brethen  <mailto:mark.bret...@gmail.com>> wrote:
> This port does not have config, so I’m having to pass the build args. How do 
> I specify a gcc (gfortran) compiler? Clang doesn’t work.
> 
> Thanks,
> Mark
> 
> 
> 
> > On Jul 2, 2022, at 2:21 PM, Mark Brethen  > <mailto:mark.bret...@gmail.com>> wrote:
> > 
> > Still not working…
> > 
> > 
> > 
> > Mark Brethen
> > mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> > 
> > 
> > 
> >> On Jul 2, 2022, at 2:15 PM, Mark Brethen  >> <mailto:mark.bret...@gmail.com>> wrote:
> >> 
> >> I should have looked at the active-variants tcl:
> >> 
> >> require_active_variants arpack accelerate mpich
> >> 
> >> should be
> >> 
> >> require_active_variants arpack "accelerate mpich"
> >> 
> >> Mark Brethen
> >> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>
> >> 
> >> 
> >> 
> >>> On Jul 2, 2022, at 1:48 PM, Mark Brethen  >>> <mailto:mark.bret...@gmail.com>> wrote:
> >>> 
> >>> Attaching log
> >>> 
> >>> 
> >>> Mark
> >>> 
> >>> 
> >>> 
> >>>> On Jul 2, 2022, at 9:22 AM, Mark Brethen  >>>> <mailto:mark.bret...@gmail.com>> wrote:
> >>>> 
> >>>> I looked at the compilers PortGroup tcl but can’t figure out how to set 
> >>>> up gcc (for gfortran). I tried setting "compilers.choose cc” and 
> >>>> “compilers.setup require_fortran” but it continues to use clang.
> >>>> 
> >>>> Thanks
> >>>> Mark
> >>>> 
> >>>> 
> >>> 
> >> 
> > 
> 

Compiler Selection

[Mark Brethen]

According to the wiki:

> The compiler is chosen with the following precedence:
> 
> If configure.compiler is set in the Portfile, then that is the compiler that 
> is used.
> If the user sets default_compilers, the compiler is chosen from that list 
> unless the compiler is blacklisted.
> If the Portfile sets compiler.whitelist, the compiler is chosen from that 
> list unless the compiler is blacklisted. 
> If the Portfile sets compiler.fallback, the compiler is chosen from that list 
> unless the compiler is blacklisted. 
> A compiler is chosen (Xcode compilers if possible) that
> is not blacklisted,
> is known to work on the particular version of the OS, and
> satisfies the requirements set in the Portfile.
CalculiX requires gcc + fortran. I used ‘configure.compiler macports-gcc-11’ 
(it will not build with clang). But this seems too rigid. My initial goal was 
to set the latest version as default with the option of trying earlier versions 
of macports-gcc. I tried using compilers PortGroup but could not get that to 
work—I haven’t figured out the proper setup. Is it possible? I read that 
variants are no longer recommended for this.

Thanks,
Mark

Re: compilers PortGroup

[Mark Brethen]

This port does not have config, so I’m having to pass the build args. How do I 
specify a gcc (gfortran) compiler? Clang doesn’t work.

Thanks,
Mark



> On Jul 2, 2022, at 2:21 PM, Mark Brethen  wrote:
> 
> Still not working…
> 
> 
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jul 2, 2022, at 2:15 PM, Mark Brethen  wrote:
>> 
>> I should have looked at the active-variants tcl:
>> 
>> require_active_variants arpack accelerate mpich
>> 
>> should be
>> 
>> require_active_variants arpack "accelerate mpich"
>> 
>> Mark Brethen
>> mark.bret...@gmail.com
>> 
>> 
>> 
>>> On Jul 2, 2022, at 1:48 PM, Mark Brethen  wrote:
>>> 
>>> Attaching log
>>> 
>>> 
>>> Mark
>>> 
>>> 
>>> 
>>>> On Jul 2, 2022, at 9:22 AM, Mark Brethen  wrote:
>>>> 
>>>> I looked at the compilers PortGroup tcl but can’t figure out how to set up 
>>>> gcc (for gfortran). I tried setting "compilers.choose cc” and 
>>>> “compilers.setup require_fortran” but it continues to use clang.
>>>> 
>>>> Thanks
>>>> Mark
>>>> 
>>>> 
>>> 
>> 
>