Re: runtime failure at the start of a job with gfortran-mp-14
Good morning Paolo, good morning all, How are you? I hope all is well with you. Please find below a quote from an Apple engineer from the article I recommended to you yesterday (https://developer.apple.com/forums/thread/655588): > Given the above reality, the libraries in /usr/lib are no longer needed: > Developer tools should be looking at the stub libraries in the appropriate > SDK. > The runtime doesn’t use these libraries because they’ve been rolled into the > dynamic linker shared cache [4]. > And that’s why they were removed. > > This is fine if you’re using Xcode, or Apple’s command-line tools, because > they know how to look inside an SDK for headers and stub libraries. If you’re > using third-party tools then you need to consult the support resources for > those tools to find out how they’ve adjusted to this new reality. In your > case the critical point is the linker. If your third-party tools use the > Apple linker then you should just be able to point the tools at the > usr/include directory within the appropriate SDK. Our linker will > automatically use any stub libraries that it finds. According to this the physical libraries on your system (*.dylib) files became stub libraries (*.tbd). Apple-native tools, C and C++ compilers from Xcode Command Line Tools will know how to work with these stub libraries. Third-party tools (the GNU compilers) will need adapting to this new reality of the Apple-world and learn how to work with the stub libraries. Paolo, can you check with ‘tool -L ’ and ‘dyld_info -dependents ’ what are the dependencies of your executable? Here is another good article on Apple Developer Forums on libraries and linking: https://developer.apple.com/forums/thread/715385 > The dynamic linker loads Mach-O images at runtime. Its path is /usr/lib/dyld, > so it’s often referred to as dyld, dyld, or DYLD. Personally I pronounced > that dee-lid, but some folks say di-lid and others say dee-why-el-dee. > IMPORTANT Third-party executables must use the standard dynamic linker. Paolo, can you double check and make sure your compilation procedure uses Apple’s dynamic linker (/usr/lib/dyld)? All in all, as a rule of thumb, to obtain less problems during compilation and streamline general research and development work use native, vendor-provided toolchains. For example, on Apple try to use Apple toolchain, on Intel—Intel toolchain, on AMD—the AMD, on ARM—the ARM. This is also extremely important to achieve the highest possible performance on a given CPU. I cannot stress this enough, this seems to be a common problem in the research world (this is where my background lies too). Researchers naively use GNU and believe it will result in the best performance. No. Use vendor compilers and libraries to have the highest performance mathematical operations. For example, on Intel architectures, use Intel compilers, Intel OpenMPI library, Intel MPI library and Intel MKL. Returning to our topic, Apple notoriously does not support Fortran and has no native Fortran compiler. The route to using a __native__ Fortran compiler is closed to us. A possible solution may be to use ‘flang’, a Fortan compiler from an LLVM suite (https://flang.llvm.org/docs/). As I understand it, it is in active development, but may not yet be ready for a production use. Another option may be commercial Fortran compilers for Mac. For example, NAG’s Fortran compiler: https://nag.com/fortran-compiler/ Finally, we have our beloved GNU Fortran compiler. I don’t know, what is the status of the latest ‘gfortran’ to support Apple’s stub libraries. Maybe more experienced MacPorts users would complement my answer here? The fact that GNU toolchain needs to be compiled for your iMac with M3 is probably due to the absence of pre-compiled binaries of the ‘gcc14’ and ‘libgcc14’ ports for your platform (Sequoia) and architecture (Apple M3). My basic understanding of MacPorts is that, if your platform and architecture are well established, there will be a pre-compiled binary of the port that you can simply download and install. There will be to compilation from sources. On the other hand, if your platform + architecture are new, no pre-compiled binaries exist in the online repositories of MacPorts and these ports will be compiled from source. Experienced MacPorts users, please correct me, if I'm wrong. I hope all of this was helpful. Thank you all and have a wonderful day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 1 Oct 2024, at 10:26, Maxim Abalenkov wrote: > > Hello Paolo, > > How are you? A quick search on the Internet results in the following links: > > https://stackoverflow.com/questions/74909796/missing-libsystem-b-dylib-file-on-macos > https://stackoverflow.com/questions/70549365/why-are-my-system-libraries-an
Re: rust port complaint at time of selfupdate
Hello Kenneth et al., How are you? There is a ticket. Please see: https://trac.macports.org/ticket/70573 This issue is relevant for me too. But it seems no-one is working on its resolution. Because of it I cannot clean my MacPorts installation for a few weeks now. Thank you! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 1 Oct 2024, at 16:49, Kenneth Wolcott wrote: > > Hi; > > I don't see a ticket for the Rust issue, I guess I will create one. > > Ken Wolcott > > On Fri, Sep 20, 2024 at 12:04 PM Christopher Jones via macports-users > wrote: >> >> >> You should learn to check trac tickets. Or just check >> >> https://trac.macports.org/wiki/SequoiaProblems >> >> for the known problems. >> >> R will not work on macOS15 until its maintainers bumps ints gcc and clang >> versions to those support on this OS >> >> https://trac.macports.org/ticket/70799 >> >> Chris >> >> On 20 Sep 2024, at 7:55 pm, Kenneth Wolcott wrote: >> >> >> Hi; >> >> So how do I fix the problem? >> >> I have a similar problem with R now... >> >> Failed to parse file R/R-pbdMPI/Portfile: can't read "mpi_port": no >> such variable >> Failed to parse file lang/rust-bootstrap/Portfile: rust_build.version >> (1.77.0) must be newer than rust_build.stage0_versions (1.80.1 1.80.0) >> >> On Wed, Sep 18, 2024 at 4:33 PM Austin Ziegler wrote: >> >> >> I think that the `rust-bootstrap` port is supposed to track the `rust` port >> and only the `rust` port has been updated recently. >> >> -a >> >> On Wed, Sep 18, 2024 at 6:22 PM Kenneth Wolcott >> wrote: >> >> >> Hi; >> >> Just did a selfupdate, there's an issue with the rust port... >> >> Creating port index in >> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports >> Failed to parse file lang/rust-bootstrap/Portfile: rust_build.version >> (1.77.0) must be newer than rust_build.stage0_versions (1.80.1 1.80.0) >> >> >> Thanks, >> Ken Wolcott >> >> >> >> >> -- >> Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca >> http://www.halostatue.ca/ • http://twitter.com/halostatue >> >>
Re: runtime failure at the start of a job with gfortran-mp-14
Hello Paolo, How are you? A quick search on the Internet results in the following links: https://stackoverflow.com/questions/74909796/missing-libsystem-b-dylib-file-on-macos https://stackoverflow.com/questions/70549365/why-are-my-system-libraries-and-frameworks-not-visible-in-macos-monterey https://developer.apple.com/forums/thread/655588 The article on the Apple Developer forum may be most helpful for you. Thank you and have a great day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 1 Oct 2024, at 10:16, P. Denti via macports-users > wrote: > > Failure starting with OS Sonoma, now with Sequoia. > Processor is M3 on iMac. > > The following message in Sonoma: > > paolo in ~/Desktop/nisclue240 $ ./nisclue > dyld[78445]: dyld cache '(null)' not loaded: syscall to map cache into shared > region failed > dyld[78445]: Library not loaded: /usr/lib/libSystem.B.dylib > Referenced from: > /Users/paolo/Desktop/nisclue240/nisclue > Reason: tried: 'usr/lib/libSystem.B.dylib' (no such file), > '/System/Volumes/Preboot/Cryptexes/O/uS/usr/lib/libSystem.B.dylib' (no such > file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache) > Abort trap: 6 > > Analogous response in Sequoia. > > Additional information: > The same job runs until completion on a previous iMac with processor i7 with > OS Monterey. > > nisclue from nisclue.f is the only job in a dozen of similar jobs that > refuses to work; > a common feature of these jobs is dealing with large matrices. > > If this information is insufficient, and sources and data involved are > required, I will post.
Re: [unable to compile MPICH v4.2.1 with GNU toolchain v13.2.0 @ macOS Sonoma v14.4.1]
Hello Ryan et al.,
Thank you for your quick reply.
> If you want to build anything from source on macOS, use clang unless there is
> an extremely good reason to use gcc.
When you say clang, do you recommend using Apple’s clang or clang from
MacPorts? One extremely good reason to use gcc is the ability to have a Fortran
compiler. I need an MPICH distribution with Fortran compiler wrappers and
Fortran modules.
> You said in the subject line that you're using gcc 13.2.0 but that's not
> confirmed by the log. When I researched this error recently, I found that
> this bug was fixed in gcc 11.1 which makes me think you are actually trying
> to use a gcc version older than that. See
> https://trac.macports.org/ticket/69632
I set gcc to point to mp-gcc13 with a MacPorts command:
sudo port select --set gcc mp-gcc13
In my Perl script I ensure FC, CC and CXX environment variables point to
compilers in /opt/local/bin/{gcc,g++,gfortran}. Is there any other way to
verify that I’m using the right version of GNU compilers?
> In your script the flag -I /opt/local/include/unistring/cdefs.h will not help
> anything because /opt/local/include/unistring/cdefs.h is not a directory that
> contains headers.
This was my futile attempt to ‘include’ the correct ‘cdefs.h’ header file, that
was causing problems. Thank you for your help and have a great day ahead!
—
Best wishes,
Maxim
Maxim Abalenkov \\ maxim.abalen...@gmail.com
+44 7 486 486 505 \\ www.maxim.abalenkov.uk
> On 13 May 2024, at 14:51, Ryan Schmidt wrote:
>
> On May 13, 2024, at 05:36, Maxim Abalenkov wrote:
>>
>> Dear all,
>>
>> How are you? I hope all is well with you. I need help please. I’m struggling
>> to compile MPICH v4.2.1 (from source code) with the GNU toolchain v13.2.0 @
>> macOS Sonoma v14.4.1. Please see my configuration and installation Perl
>> script attached. I also attach a full log of the compilation errors. I
>> recently installed GNU toolchain via MacPorts. When the script proceeds to
>> compilation, it crashes with the following error messages:
>>
>> Compiling MPICH...
>> In file included from
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/_types.h:32,
>> from
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/_types.h:27,
>> from
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/pthread.h:55,
>> from ../../../modules/yaksa/src/util/yaksu_atomics.c:6:
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:30:
>> error: missing ')' after "__has_attribute"
>> 554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
>> | ^
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:31:
>> error: ':' without preceding '?'
>> 554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
>>
>> I suspect that Apple compilers’ header files are picked up erroneously. Is
>> this normal for GNU toolchain to rely on Apple SDK’s header files? I’m new
>> to Apple CPUs. Would you please educate me, what is the suggested way of
>> installing software on Apple M? processors from source? Or should I just
>> save the pain and install my code using Apple’s native toolchain? Thank you
>> for your help and have a productive week ahead!
>
> If you want to use mpich, the easiest solution is to use MacPorts to install
> it.
>
> If you want to build anything from source on macOS, use clang unless there is
> an extremely good reason to use gcc.
>
> You said in the subject line that you're using gcc 13.2.0 but that's not
> confirmed by the log. When I researched this error recently, I found that
> this bug was fixed in gcc 11.1 which makes me think you are actually trying
> to use a gcc version older than that. See
> https://trac.macports.org/ticket/69632
>
> In your script the flag -I /opt/local/include/unistring/cdefs.h will not help
> anything because /opt/local/include/unistring/cdefs.h is not a directory that
> contains headers.
[unable to compile MPICH v4.2.1 with GNU toolchain v13.2.0 @ macOS Sonoma v14.4.1]
Dear all,How are you? I hope all is well with you. I need help please. I’m struggling to compile MPICH v4.2.1 (from source code) with the GNU toolchain v13.2.0 @ macOS Sonoma v14.4.1. Please see my configuration and installation Perl script attached. I also attach a full log of the compilation errors. I recently installed GNU toolchain via MacPorts. When the script proceeds to compilation, it crashes with the following error messages:Compiling MPICH...In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/_types.h:32, from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/_types.h:27, from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/pthread.h:55, from ../../../modules/yaksa/src/util/yaksu_atomics.c:6:/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:30: error: missing ')' after "__has_attribute" 554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage) | ^/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:31: error: ':' without preceding '?' 554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)I suspect that Apple compilers’ header files are picked up erroneously. Is this normal for GNU toolchain to rely on Apple SDK’s header files? I’m new to Apple CPUs. Would you please educate me, what is the suggested way of installing software on Apple M? processors from source? Or should I just save the pain and install my code using Apple’s native toolchain? Thank you for your help and have a productive week ahead!—Best wishes,Maxim#!/usr/bin/env perl
## @brief Configures, compiles and installs MPICH with GNU compiler toolchain.
## @author Maksims Abalenkovs
## @email maksims.abalenk...@stfc.ac.uk
## @dateApr 22, 2023
## @version 0.5
use v5.38.2;
use autodie;
use strict;
use warnings;
use local::lib;
use Cwd qw(getcwd);
use File::Slurper qw(write_text);
use IPC::System::Simple qw(capturex);
my $rootdir = &getcwd();
my $gnubin= '/opt/local/bin';
my $prefix= '/opt/mpich-4.2.1';
my $np= 8;
my $build_dir = 'build';
printf "prefix:%s\n", $prefix;
printf "np:%s\n", $np;
printf "build_dir: %s\n", $build_dir;
print "Setting environment variables...\n";
$ENV{'FC'} = $gnubin . '/gfortran';
$ENV{'F77'} = $ENV{'FC'};
$ENV{'CC'} = $gnubin . '/gcc';
$ENV{'CXX'} = $gnubin . '/g++';
$ENV{'FFLAGS'} = '-fPIC -m64 -fallow-argument-mismatch -I /opt/local/include/unistring/cdefs.h';
$ENV{'CFLAGS'} = '-fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -I /opt/local/include/unistring/cdefs.h';
print "Environment variables were set to:\n";
printf " FC: %s\n", $ENV{'FC'};
printf " F77: %s\n", $ENV{'F77'};
printf " CC: %s\n", $ENV{'CC'};
printf " CXX: %s\n\n", $ENV{'CXX'};
printf " FFLAGS: %s\n", $ENV{'FFLAGS'};
printf " CFLAGS: %s\n", $ENV{'CFLAGS'};
mkdir $build_dir;
chdir $build_dir;
print "Configuring MPICH...\n";
my @conf_options = (
"--prefix=$prefix",
'--enable-shared=no',
'--enable-fast=O3,ndebug',
'--disable-error-checking',
'--enable-fortran=all',
'--enable-cxx',
'--enable-romio' );
my $log = capturex('../configure', @conf_options);
&write_text('c.txt', $log);
print "Compiling MPICH...\n";
$log = capturex('make', '-j', $np);
&write_text('m.txt', $log);
print "Installing MPICH into $prefix...\n";
$log = capturex('make', 'install');
&write_text('mi.log', $log);
print "Checking MPICH installation...\n";
$log = capturex('make', '-j', $np, 'installcheck');
&write_text('mc.txt', $log);
print "Testing MPICH installation...\n";
chdir $rootdir . '/test/mpi';
# Unset Fortran 90 compiler flags
$ENV{'F90'} = '';
$ENV{'F90FLAGS'} = '';
# Set Fortran compiler flags
$ENV{'FCFLAGS'} = $ENV{'FFLAGS'};
$log = capturex('./configure', "--with-mpi=$prefix");
&write_text('ct.txt', $log);
$log = capturex('make', '-j', $np, 'testing');
&write_text('mt.txt', $log);
## @eof mpich-install-gnu.pl
mpich-4.2.1-install.log
Description: Binary data
Maxim Abalenkov \\ maxim.abalen...@gmail.com+44 7 486 486 505 \\ www.maxim.abalenkov.uk
Re: work-around for Xcode 15 linker issue?
Dear Murray, Chris et al., How are you? I’m very sorry. I didn’t mean to mislead anybody. I’m also learning. What user does MacPorts run as? Maybe it would be possible to pass these environment variables to that ‘MacPorts’ user? — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 3 Oct 2023, at 21:25, Chris Jones wrote: > > Hi, > > Just incase any one else reads this, anything you add to your user profile > will nit have any effect on port builds, as these do not run as your user. So > don’t try this expecting it to fix port builds. > > Chris > >> On 2 Oct 2023, at 4:18 pm, Maxim Abalenkov wrote: >> >> Hello Murray, >> >> How are you? As mentioned in the previous posts on this list, please see >> Apple’s comments on the new linker issue: >> >> https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking >> >> For now, use Xcode 15 and its command line tools and try to enforce the old >> linker by defining the following environment variables: >> >> export MACOSX_DEPLOYMENT_TARGET=12 >> export OTHER_LDFLAGS=-Wl,-ld_classic >> >> You may place them into your ~/.profile file. I hope this helps. >> >> — >> Best wishes, >> Maxim >> >> Maxim Abalenkov \\ maxim.abalen...@gmail.com >> +44 7 486 486 505 \\ www.maxim.abalenkov.uk >> >>> On 2 Oct 2023, at 15:29, Murray Eisenberg wrote: >>> >>> As reported at grac.macports.org <http://grac.macports.org/>, a number of >>> ports will no longer install because configure fails with Xcode 15, which >>> apparently has a linker issues. >>> >>> Some have suggested reverting to Xcode 14.3.1, to work around those issues. >>> >>> But under macOS Sonoma, that does not seem to be an option: After replacing >>> Xcode 15 with Xcode 14.3.1, and similarly for the command-line tools, if I >>> open Xcode 14.3.1, I get an error that this version of Xcode will not work >>> with the OS (Sonoma). >>> >>> Is there some other work-around? >>> >>> --- >>> Murray Eisenbergmurrayeisenb...@gmail.com >>> Mobile (413)-427-5334 >>> 503 King Farm Blvd #101 >>> Rockville, MD 20850-6667 >>> >>> >>> >>
Re: work-around for Xcode 15 linker issue?
Hello Murray, How are you? As mentioned in the previous posts on this list, please see Apple’s comments on the new linker issue: https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking Xcode 15 Release Notes | Apple Developer Documentation developer.apple.com For now, use Xcode 15 and its command line tools and try to enforce the old linker by defining the following environment variables: export MACOSX_DEPLOYMENT_TARGET=12 export OTHER_LDFLAGS=-Wl,-ld_classic You may place them into your ~/.profile file. I hope this helps. — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 2 Oct 2023, at 15:29, Murray Eisenberg wrote: > > As reported at grac.macports.org <http://grac.macports.org/>, a number of > ports will no longer install because configure fails with Xcode 15, which > apparently has a linker issues. > > Some have suggested reverting to Xcode 14.3.1, to work around those issues. > > But under macOS Sonoma, that does not seem to be an option: After replacing > Xcode 15 with Xcode 14.3.1, and similarly for the command-line tools, if I > open Xcode 14.3.1, I get an error that this version of Xcode will not work > with the OS (Sonoma). > > Is there some other work-around? > > --- > Murray Eisenberg murrayeisenb...@gmail.com > Mobile (413)-427-5334 > 503 King Farm Blvd #101 > Rockville, MD 20850-6667 > > >
Re: [unable to compile and link C++ code with g++ 12.3]
Dear Dave et al., I’m unable to run the ‘xcodebuild —version’. It complains: xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance The version of Xcode reported by the ‘About Xcode’ graphical menu item is: Version 15.0 (15A240d) — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 20 Sep 2023, at 17:41, Dave Allured - NOAA Affiliate > wrote: > > Maxim, thank you for the detailed follow-up. What is the full output from > "xcodebuild -version"? > > > On Wed, Sep 20, 2023 at 10:36 AM Maxim Abalenkov <mailto:maxim.abalen...@gmail.com>> wrote: >> Dear all, >> >> I can compile and link the code with Clang C++ compiler from the MacPorts >> collection: >> >> clang version 15.0.7 >> Target: x86_64-apple-darwin22.6.0 >> Thread model: posix >> InstalledDir: /opt/local/libexec/llvm-15/bin >> >> To complement my previous email: my target system is macOS 13.5.2 (22G91) >> and the new command line tools version is: >> >> package-id: com.apple.pkg.CLTools_Executables >> version: 15.0.0.0.1.1694021235 >> volume: / >> location: / >> install-time: 1695112544 >> >> — >> Best wishes, >> Maxim >> >>> On 20 Sep 2023, at 17:11, Maxim Abalenkov >> <mailto:maxim.abalen...@gmail.com>> wrote: >>> >>> Dear all, >>> >>> How are you? I hope all is well with you. I need help please. I’m no longer >>> able to compile and link a C++ code on my Mac. I use the latest GNU C++ >>> compiler available via MacPorts: >>> >>> g++ (MacPorts gcc12 12.3.0_0+stdlib_flag) 12.3.0 >>> >>> Please find below the output of the make tool: >>> >>> g++ ifm.o Core/engine.o Core/filter.o Core/watershed.o >>> FileIO/interpolation.o FileIO/mapfile.o FileIO/netcdf_io.o >>> FileIO/rain_table.o -o ifm -fopenmp -O3 -lm -lz -lnetcdf_c++ -lnetcdf >>> -L/opt/local/lib >>> -macosx_version_min has been renamed to -macos_version_min >>> 0 0x109822f43 __assert_rtn + 64 >>> 1 0x109724f43 ld::AtomPlacement::findAtom(unsigned char, unsigned long >>> long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 >>> 2 0x109741431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header >>> const*) const + 19745 >>> 3 0x109751b71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) >>> block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + >>> 657 >>> 4 0x7ff810954066 _dispatch_client_callout2 + 8 >>> 5 0x7ff810965e09 _dispatch_apply_invoke + 213 >>> 6 0x7ff810954033 _dispatch_client_callout + 8 >>> 7 0x7ff8109640f6 _dispatch_root_queue_drain + 683 >>> 8 0x7ff810964768 _dispatch_worker_thread2 + 170 >>> 9 0x7ff810af1c0f _pthread_wqthread + 257 >>> ld: Assertion failed: (resultIndex < sectData.atoms.size()), function >>> findAtom, file Relocations.cpp, line 1336. >>> collect2: error: ld returned 1 exit status >>> make: *** [Makefile:58: ifm] Error 1 >>> >>> All this may be related to the update of Xcode command line tools that I >>> performed yesterday. Any help on how to debug and make it compile would be >>> most welcome. Thank you and have a great day ahead! >>> >>> — >>> Best wishes, >>> Maxim >>> >>> Maxim Abalenkov \\ maxim.abalen...@gmail.com >>> <mailto:maxim.abalen...@gmail.com> >>> +44 7 486 486 505 \\ www.maxim.abalenkov.uk <http://www.maxim.abalenkov.uk/>
Re: [unable to compile and link C++ code with g++ 12.3]
Dear all, I can compile and link the code with Clang C++ compiler from the MacPorts collection: clang version 15.0.7 Target: x86_64-apple-darwin22.6.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-15/bin To complement my previous email: my target system is macOS 13.5.2 (22G91) and the new command line tools version is: package-id: com.apple.pkg.CLTools_Executables version: 15.0.0.0.1.1694021235 volume: / location: / install-time: 1695112544 — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 20 Sep 2023, at 17:11, Maxim Abalenkov wrote: > > Dear all, > > How are you? I hope all is well with you. I need help please. I’m no longer > able to compile and link a C++ code on my Mac. I use the latest GNU C++ > compiler available via MacPorts: > > g++ (MacPorts gcc12 12.3.0_0+stdlib_flag) 12.3.0 > > Please find below the output of the make tool: > > g++ ifm.o Core/engine.o Core/filter.o Core/watershed.o FileIO/interpolation.o > FileIO/mapfile.o FileIO/netcdf_io.o FileIO/rain_table.o -o ifm -fopenmp -O3 > -lm -lz -lnetcdf_c++ -lnetcdf -L/opt/local/lib > -macosx_version_min has been renamed to -macos_version_min > 0 0x109822f43 __assert_rtn + 64 > 1 0x109724f43 ld::AtomPlacement::findAtom(unsigned char, unsigned long > long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 > 2 0x109741431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header > const*) const + 19745 > 3 0x109751b71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) > block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + > 657 > 4 0x7ff810954066 _dispatch_client_callout2 + 8 > 5 0x7ff810965e09 _dispatch_apply_invoke + 213 > 6 0x7ff810954033 _dispatch_client_callout + 8 > 7 0x7ff8109640f6 _dispatch_root_queue_drain + 683 > 8 0x7ff810964768 _dispatch_worker_thread2 + 170 > 9 0x7ff810af1c0f _pthread_wqthread + 257 > ld: Assertion failed: (resultIndex < sectData.atoms.size()), function > findAtom, file Relocations.cpp, line 1336. > collect2: error: ld returned 1 exit status > make: *** [Makefile:58: ifm] Error 1 > > All this may be related to the update of Xcode command line tools that I > performed yesterday. Any help on how to debug and make it compile would be > most welcome. Thank you and have a great day ahead! > > — > Best wishes, > Maxim > > Maxim Abalenkov \\ maxim.abalen...@gmail.com > +44 7 486 486 505 \\ www.maxim.abalenkov.uk
[unable to compile and link C++ code with g++ 12.3]
Dear all, How are you? I hope all is well with you. I need help please. I’m no longer able to compile and link a C++ code on my Mac. I use the latest GNU C++ compiler available via MacPorts: g++ (MacPorts gcc12 12.3.0_0+stdlib_flag) 12.3.0 Please find below the output of the make tool: g++ ifm.o Core/engine.o Core/filter.o Core/watershed.o FileIO/interpolation.o FileIO/mapfile.o FileIO/netcdf_io.o FileIO/rain_table.o -o ifm -fopenmp -O3 -lm -lz -lnetcdf_c++ -lnetcdf -L/opt/local/lib -macosx_version_min has been renamed to -macos_version_min 0 0x109822f43 __assert_rtn + 64 1 0x109724f43 ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 2 0x109741431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 19745 3 0x109751b71 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 657 4 0x7ff810954066 _dispatch_client_callout2 + 8 5 0x7ff810965e09 _dispatch_apply_invoke + 213 6 0x7ff810954033 _dispatch_client_callout + 8 7 0x7ff8109640f6 _dispatch_root_queue_drain + 683 8 0x7ff810964768 _dispatch_worker_thread2 + 170 9 0x7ff810af1c0f _pthread_wqthread + 257 ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. collect2: error: ld returned 1 exit status make: *** [Makefile:58: ifm] Error 1 All this may be related to the update of Xcode command line tools that I performed yesterday. Any help on how to debug and make it compile would be most welcome. Thank you and have a great day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk
Re: perl --version is not at perl5.36 but at perl5.34 yet both are listed as active
Dear gentlemen, How are you? It shouldn’t be that difficult to fix perl-select. Can we do that? Also if you are interested in using the _latest_ Perl, you would be pleased to find out that Perl v5.38 came out recently (in the early days of June). — Best wishes, Maxim > On 14 Aug 2023, at 06:01, Kenneth Wolcott wrote: > > HI Bill; > > Thanks for your reply. > > I'll point to /opt/local/bin/perl5.36 in my scripts. > > Thanks, > Ken
Re: Problem with binutils
Hello Christoph,
How are you? Have you tried to deactivate the ‘gdb’ first as the message
suggests?
port deactivate gdb
Then you may be able to install ‘binutils’ and activate the ‘gdb’ again.
—
Best wishes,
Maxim
Maxim Abalenkov \\ maxim.abalen...@gmail.com
+44 7 486 486 505 \\ www.maxim.abalenkov.uk
> On 7 Aug 2023, at 08:13, Christoph Kukulies wrote:
>
> Hi,
>
> I was trying to sudo port install binutils and got this:
>
> $ sudo port install binutils
> Password:
> ---> Computing dependencies for binutils
> ---> Fetching archive for binutils
> ---> Attempting to fetch binutils-2.39_1.darwin_20.x86_64.tbz2 from
> https://packages.macports.org/binutils
> ---> Attempting to fetch binutils-2.39_1.darwin_20.x86_64.tbz2.rmd160 from
> https://packages.macports.org/binutils
> ---> Installing binutils @2.39_1
> ---> Activating binutils @2.39_1
> Error: Failed to activate binutils: Image error:
> /opt/local/include/ansidecl.h is being used by the active gdb port. Please
> deactivate this port first, or use 'port -f activate binutils' to force the
> activation.
> while executing
> "throw registry::image-error $msg"
> ("foreach" body line 47)
> invoked from within
> "foreach file $imagefiles {
> set srcfile "${extracted_dir}${file}"
>
> # To be able to install links, we test if we can lst..."
> invoked from within
> "registry::write {
> foreach file $imagefiles {
> set srcfile "${extracted_dir}${file}"
>
> # To be able to instal..."
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_binutils/binutils/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets if you believe
> there is a bug.
> Error: Processing of port binutils failed
> $
>
> How can I get around?
>
> --
> Christoph
>
Re: [openssh: segmentation fault]
Dear Fabien, Thank you for your suggestion. I tried to remove the duplicates and temporarily renaming the ‘known_hosts’ into ‘known_hosts.old’, but I still experience the same issue. — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 8 Jun 2023, at 13:37, Fabien Auréjac wrote: > > Some say in Apple forums to clean known_hosts and known_hosts2 files by > removing all the duplicates... > > Will this be helpful for you ? > > Le 08/06/2023 à 14:28, Maxim Abalenkov a écrit : >> Dear all, >> >> How are you? I hope all is well with you. I need help please. This morning I >> ran into an issue of being unable to pull the latest changes from a GitLab >> repository. I checked the SSH keys, the URL and .ssh/config file. These >> appear to be correct. On the other hand, I notice that when I run pure ‘ssh’ >> command in a terminal it crashes with a ‘segmentation fault 11’. I tried >> re-installing openssh port. But it didn’t help. Would you please help me to >> debug this issue? Do I miss something obvious? Thank you and have a good day >> ahead! >> >> — >> Best wishes, >> Maxim >> >> Maxim Abalenkov \\ maxim.abalen...@gmail.com >> <mailto:maxim.abalen...@gmail.com> >> +44 7 486 486 505 \\ www.maxim.abalenkov.uk <http://www.maxim.abalenkov.uk/>
[openssh: segmentation fault]
Dear all, How are you? I hope all is well with you. I need help please. This morning I ran into an issue of being unable to pull the latest changes from a GitLab repository. I checked the SSH keys, the URL and .ssh/config file. These appear to be correct. On the other hand, I notice that when I run pure ‘ssh’ command in a terminal it crashes with a ‘segmentation fault 11’. I tried re-installing openssh port. But it didn’t help. Would you please help me to debug this issue? Do I miss something obvious? Thank you and have a good day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk
Re: vim update
Dear all, I experience the same issue. Updating Vim fails. Is there any resolution to this? The issue on GitHub is still open. Thank you and have a good day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 5 Jun 2023, at 21:45, Clemens Lang wrote: > > Hi, > > On Fri, Jun 02, 2023 at 04:07:05PM -0700, ppadil...@gmail.com > <mailto:ppadil...@gmail.com> wrote: >> Trying to update vim to the latest update that I saw today in macports. >> Unfortunately it fails to patch: >> >> Error: Failed to patch vim: command execution failed >> Error: See >> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/main.log >> for details. >> >> :info:patch Executing: cd >> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/work/vim-9.0.1499" >> && /usr/bin/patch -p0 < >> '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/editors/vim/files/patch-python3.diff' >> :debug:patch system: cd >> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_vim/vim/work/vim-9.0.1499" >> && /usr/bin/patch -p0 < >> '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/editors/vim/files/patch-python3.diff' >> :info:patch patching file 'src/configure.ac' >> :info:patch 1 out of 1 hunks failed--saving rejects to >> 'src/configure.ac.rej' > > It fails while applying patch-python3.diff. See > https://github.com/macports/macports-ports/pull/18934. > > -- > Clemens
Re: [mongodb: mongo command]
Dear all, Thank you for your replies so far. Would you please tell me, what Mac port contains the newer MongoDB shell ‘mongosh’? It’s not present in the ‘mongodb’ port. I couldn’t find ‘mongosh’ via the ‘port search’ command either. Thank you very much! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 16 May 2023, at 14:28, Felipe Gasper wrote: > > “mongos” is MongoDB’s proxy for sharded clusters. > > “mongo” is MongoDB’s legacy shell, which in newer MongoDB releases (6+) is no > longer distributed. > > “mongosh” is MongoDB’s new shell. Prefer it whenever possible. > > -FG > > >> On May 16, 2023, at 9:24 AM, David Herron wrote: >> >> mongod is the database server >> >> mongos is probably the shell - the CLI user interface to the database >> >> Look at MongoDB-dot-com for documentation >> >> + David Herron >> >> >> >> On Tue, May 16, 2023 at 1:11 PM Maxim Abalenkov >> wrote: >> Dear all, >> >> How are you? I hope all is well with you. I need your help please. I would >> like to access a MongoDB database using a command line similar to: >> >> mongo --host localhost --port 27018 --username ... --password ... >> --authenticationDatabase … >> >> I installed the ‘mongodb’ Mac port. However, I do not see a ‘mongo’ command. >> There are ‘mongod’ and ‘mongos’, but no ‘mongo’. Would you please tell me, >> what is the difference between the ‘d’ and ’s’ commands and how do I obtain >> the ‘mongo’ itself? Thank you and have a good day ahead! >> >> — >> Best wishes, >> Maxim >> >> Maxim Abalenkov \\ maxim.abalen...@gmail.com >> +44 7 486 486 505 \\ www.maxim.abalenkov.uk >
[mongodb: mongo command]
Dear all, How are you? I hope all is well with you. I need your help please. I would like to access a MongoDB database using a command line similar to: mongo --host localhost --port 27018 --username ... --password ... --authenticationDatabase … I installed the ‘mongodb’ Mac port. However, I do not see a ‘mongo’ command. There are ‘mongod’ and ‘mongos’, but no ‘mongo’. Would you please tell me, what is the difference between the ‘d’ and ’s’ commands and how do I obtain the ‘mongo’ itself? Thank you and have a good day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk
[gvim: vim variant?]
Dear all, How are you? I hope all is well with you. I need your help please. I mostly work in the terminal and use vim as my text editor. But occasionally I need a text editor with a graphical user interface. I have heard good things about ‘gvim’. Would you please tell me, how to install ‘gvim’ with MacPorts? Is it one of the ‘vim’ port’s variants? Executing port variants vim returns multiple options: * athena: Build GUI version using Athena widgets * gtk2: Build GUI version using GTK 2.x widgets * gtk3: Build GUI version using GTK 3.x widgets * motif: Build GUI version with Motif widgets Can you please tell me, how do they differ and which one would you recommend? Thank you for your help and have a good weekend ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk
Re: ruby
Dear all, How are you? I hope all is well with you. Sometime ago I was recommended to use rbenv script (https://github.com/rbenv/rbenv) to manage multiple installations and versions of Ruby. I followed that advice and have no problems since then. You just need to set it up properly. Read the installation guide on the GitHub page. I hope it helps you. Thank you and have a wonderful day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 20 Mar 2023, at 13:27, chilli.names...@gmail.com wrote: > > I am closer, but my $PATH is still messed up. > > This in .bash_profile > >> export >> PATH=$HOME/bin:/opt/local/bin:/opt/local/sbin:/opt/local/share/man:/usr/X11/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH > > > gets me this when I source it > >> env: bash: No such file or directory >> dude@mac:~/Extra/sand$ echo $PATH >> /Users/dude/bin:/opt/local/bin:/opt/local/sbin:/opt/local/share/man:/usr/X11/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin: > > notice the trailing ":" > removing it gets me a no such directory error for "/sbin$PATH" > > >> On Mar 20, 2023, at 09:04, Mark Anderson wrote: >> >> >> Yeah, this is the answer. You always want `/opt/local/bin/` to be near the >> start of your path. Only stuff that you specifically want to override >> MacPorts should be before it. (Examples of things you may want before: RVM >> or NVM or any of the version managers that put things in your home) >> >> Thanks, >> —Mark >> ___ >> Mark E. Anderson mailto:e...@emer.net>> >> Find me on LinkedIn <https://www.linkedin.com/in/markemer/> >> >> >> On Sat, Mar 11, 2023 at 5:57 PM Austin Ziegler > <mailto:halosta...@gmail.com>> wrote: >>> Change that to >>> >>> export >>> PATH=$HOME/bin:/opt/local/bin:/opt/local/sbin:/opt/local/share/man:/usr/X11/bin:$PATH >>> >>> -a >>> >>>> On Mar 11, 2023, at 14:03, chilli.names...@gmail.com >>>> <mailto:chilli.names...@gmail.com> wrote: >>>> >>>> >>>> Thank you, I will check that >>>> >>>> I have >>>> >>>>> export >>>>> PATH=$PATH:$HOME/bin:/opt/local/bin:/opt/local/sbin:/opt/local/share/man:/usr/X11/bin >>>> >>>> >>>> in my .bash_profile, but echo $PATH shows what you expected: >>>> >>>>> dude@mac:~$ echo $PATH >>>>> /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/dude/bin:/opt/local/bin:/opt/local/sbin... >>>> >>>> ok, I have something new to work out. >>>> >>>>> On Mar 11, 2023, at 13:49, Austin Ziegler >>>> <mailto:halosta...@gmail.com>> wrote: >>>>> >>>>> >>>>> No problem. The system ruby showing up instead of MacPorts-installed Ruby >>>>> would be *probably* because your $PATH has `/opt/local/bin` *after* >>>>> `/usr/bin`. Typically, one wants to have Macports (or other third-party >>>>> package systems) *before* /usr/local/bin and /usr/bin. >>>>> >>>>> -a >>>>> >>>>> On Sat, Mar 11, 2023 at 1:46 PM chilli.names...@gmail.com >>>>> <mailto:chilli.names...@gmail.com> >>>> <mailto:chilli.names...@gmail.com>> wrote: >>>>>> >>>>>> >>>>>>> root@mac:~$ ruby -S gem install coltrane >>>>>>> ERROR: Error installing coltrane: >>>>>>> activesupport requires Ruby version >= 2.7.0. >>>>>> >>>>>> >>>>>> Unfortunately, Mojave: >>>>>> ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18] >>>>>> >>>>>> So I install ruby 2.7.7 >>>>>> >>>>>>> root@mac:~$ port -vsN install ruby27 >>>>>>> >>>>>>> ---> Cleaning ruby27 >>>>>>> ---> Removing work directory for ruby27 >>>>>>> ---> Updating database of binaries >>>>>>> ---> Scanning binaries for linking errors >>>>>>> ---> No broken files found. >>>>>>> ---> No broken ports found. >>>>>>> ---> Some of the ports you installed have notes: >>>>>>> ruby27 has the following notes: &
[mysterious owner of 'libc++.1.dylib']
Dear all, I need help please. I’m compiling a C/C++ code base with clang++ compiler installed via MacPorts. When I look at the libraries my executable relies on I see: otool -L /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0) However, when I try to find out what package owns this library: sudo port provides "/usr/lib/libc++.1.dylib" /usr/lib/libc++.1.dylib does not exist. Further inquiry with ‘pkgutil’ doesn’t shed more light either: pkgutil --file-info "/usr/lib/libc++.1.dylib" volume: / path: /usr/lib/libc++.1.dylib Would you please tell me, who is the mysterious owner of the ‘libc++’? Looking for libc++ in the names of ports returns the following list: sudo port search libc++ gcc-devel-libcxx @13-20230226_1 (lang) libc++ header implementation to be used by gcc-devel gcc10-libcxx @10.4.0_5 (lang) libc++ header implementation to be used by gcc10 gcc11-libcxx @11.3.0_6 (lang) libc++ header implementation to be used by gcc11 gcc12-libcxx @12.2.0_4 (lang) libc++ header implementation to be used by gcc12 libcxx @5.0.1_5 (lang) libc++ is a new implementation of the C++ standard library with support for C++11 and portions of C++14. macports-libcxx @11.1.0 (lang) provides a newer libc++ from llvm for older systems Found 6 ports. — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk
[managing multiple Ruby installations]
Dear all, How are you? I hope all is well with you. I need help please. Can you please guide me, on how to use and manage multiple Ruby installations with MacPorts? I use Ruby primarily for static website generation with Jekyll. But every time a new Ruby version comes it, it is a little bit of a guesswork to make Jekyll work again. I thought I would ask the experts here. Issuing the `port search ruby` command I see `chruby, ruby31, ruby_select, rb-bundler` which should all be helpful for me. But how do I use them in an elegant way, switching between existing Ruby versions? I remember following the official Jekyll installation guide: https://jekyllrb.com/docs/installation/macos/ <https://jekyllrb.com/docs/installation/macos/> But I don’t like, that `ruby-install` installs everything, Ruby and gems, into my home directory. This is not the place for installation files. Thank you for your help and have a wonderful day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk
Re: [numpy @ bigsur: multithreading]
Dear all,
Thank you for all of your replies and suggestions! I have written my own matrix
multiplication script in order to test NumPy’s performance. Please find it
attached. I’m using the MKL variant of NumPy. Strangely enough the `port
variants py39-numpy` still returns:
port variants py39-numpy
py39-numpy has the variants:
atlas: Use MacPorts ATLAS Libraries
* conflicts with mkl openblas
gcc10: Build using the MacPorts gcc 10 compiler
* conflicts with gcc11 gcc8 gcc9 gccdevel gfortran gfortran
gcc11: Build using the MacPorts gcc 11 compiler
* conflicts with gcc10 gcc8 gcc9 gccdevel gfortran gfortran
gcc8: Build using the MacPorts gcc 8 compiler
* conflicts with gcc10 gcc11 gcc9 gccdevel gfortran gfortran
gcc9: Build using the MacPorts gcc 9 compiler
* conflicts with gcc10 gcc11 gcc8 gccdevel gfortran gfortran
gccdevel: Build using the MacPorts gcc devel compiler
* conflicts with gcc10 gcc11 gcc8 gcc9 gfortran gfortran
[+]gfortran: Build using the MacPorts gcc 11 Fortran compiler
* conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel
mkl: Use MacPorts MKL Libraries
* conflicts with atlas openblas
[+]openblas: Use MacPorts OpenBLAS Libraries
* conflicts with atlas mkl
universal: Build for multiple architectures
Either I don’t understand the expected behaviour or my `port variants` command
returns something else. I would expect it to show [+]gfortran and [+]mkl, not
the [+]openblas. On the other hand, command `port installed py39-numpy` shows:
port installed py39-numpy
The following ports are currently installed:
py39-numpy @1.21.5_1+gfortran+mkl
py39-numpy @1.22.0_0+gfortran+mkl (active)
Finally, I wasn’t able to specify 8 execution threads with `export
MKL_NUM_THREADS=8`. NumPy was still using 4, but the `htop` reported 350–380%
CPU load for the `/usr/bin/env python3 ./dgemm_numpy.py` process. I think this
is good news!
The `otool` command executed under
`/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/core`
shows that MKL backend is being used.
otool -L _multiarray_umath.cpy
_multiarray_umath.cpython-39-darwin.so:
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/libmkl_rt.2.dylib
(compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1311.0.0)
I think I still need to experiment with OpenBLAS and compare the performance
numbers. Thank you for your help!
—
Best wishes,
Maxim
#!/usr/bin/env python3
import numpy as np
import time
print(np.__version__)
print(np.show_config())
m = 2
k = 2
n = 2
t0 = time.time()
alpha = np.random.rand()
beta = np.random.rand()
A = np.random.rand(m, k)
B = np.random.rand(k, n)
C = np.random.rand(m, n)
t1 = time.time()
t = t1-t0
print('Generation time: {0:f}'.format(t))
print(' alpha: {0:f}, beta: {1:f}'.format(alpha, beta))
t0 = time.time()
C = alpha*np.matmul(A, B) + beta*C
t1 = time.time()
t = t1-t0
print('Multiplication time: {0:f}'.format(t))
## @eof dgemm_numpy.py
> On 29 Dec 2021, at 13:33, Joshua Root wrote:
>
> Maxim Abalenkov wrote:
>
>
>> Dear all,
>>
>> I’m looking for guidance please. I would like to make sure, that I use all
>> eight of my CPU cores, when I run Python’s 3.9.9 NumPy on my macOS BigSur
>> 12.1. When I run my NumPy code, I see in ‘htop’, that only one ‘python’
>> process is running and the core utilisation is 20–25%. I remember in the
>> past, stock MacPorts NumPy installation would use Apple’s Accelerate library
>> including the multithreaded BLAS and LAPACK (
>> https://developer.apple.com/documentation/accelerate
>> ). As I understand this is no longer the case.
>>
>> I run Python code using a virtual environment located under
>>
>> /opt/venv/zipfstime/lib/python3.9/site-packages/numpy/core
>>
>> When I change there and issue
>>
>> otool -L _multiarray_umath.cpython-39-darwin.so
>>
>> _multiarray_umath.cpython-39-darwin.so:
>> @loader_path/../.dylibs/libopenblas.0.dylib (compatibility version
>> 0.0.0, current version 0.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1281.100.1)
>>
>> In other words, NumPy relies on openBLAS. Command `port variants openblas`
>> returns
>>
>> OpenBLAS has the variants:
>> g95: Build using the g95 Fortran compiler
>> * conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel
>> gcc10: Build using the MacPorts gcc 10 compiler
>> * conflicts with g95 g95 gcc11 gcc8 gcc9 gccdevel
>> [+]gcc11: Build using the MacPorts gcc 11 compiler
>> * conflicts with g95 g95 gcc10 gcc8 gcc9 gccdevel
>> gcc8: Build using the MacPorts gcc 8 c
[numpy @ bigsur: multithreading]
Dear all, I’m looking for guidance please. I would like to make sure, that I use all eight of my CPU cores, when I run Python’s 3.9.9 NumPy on my macOS BigSur 12.1. When I run my NumPy code, I see in ‘htop’, that only one ‘python’ process is running and the core utilisation is 20–25%. I remember in the past, stock MacPorts NumPy installation would use Apple’s Accelerate library including the multithreaded BLAS and LAPACK (https://developer.apple.com/documentation/accelerate). As I understand this is no longer the case. I run Python code using a virtual environment located under /opt/venv/zipfstime/lib/python3.9/site-packages/numpy/core When I change there and issue otool -L _multiarray_umath.cpython-39-darwin.so _multiarray_umath.cpython-39-darwin.so: @loader_path/../.dylibs/libopenblas.0.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) In other words, NumPy relies on openBLAS. Command `port variants openblas` returns OpenBLAS has the variants: g95: Build using the g95 Fortran compiler * conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel gcc10: Build using the MacPorts gcc 10 compiler * conflicts with g95 g95 gcc11 gcc8 gcc9 gccdevel [+]gcc11: Build using the MacPorts gcc 11 compiler * conflicts with g95 g95 gcc10 gcc8 gcc9 gccdevel gcc8: Build using the MacPorts gcc 8 compiler * conflicts with g95 g95 gcc10 gcc11 gcc9 gccdevel gcc9: Build using the MacPorts gcc 9 compiler * conflicts with g95 g95 gcc10 gcc11 gcc8 gccdevel gccdevel: Build using the MacPorts gcc devel compiler * conflicts with g95 g95 gcc10 gcc11 gcc8 gcc9 [+]lapack: Add Lapack/CLapack support to the library native: Force compilation on machine to get fully optimized library universal: Build for multiple architectures I tried installing the “native” variant of OpenBLAS port with `sudo port install openblas +native` and setting the environment variable `OMP_NUM_THREADS=8`, but I didn’t see any improvement when running my Python code. I would welcome your help and guidance on this subject. — Best wishes, Maxim
[tcl installation]
Dear all, How are you? I hope all is well with you. I have a relatively simple question. I would like to install Tcl in order to compile the VMD code and its plugins from source (http://www.ks.uiuc.edu/Research/vmd/plugins/doxygen/compiling.html#compiling). So far I have installed the tcl port: tcl @8.6.11_0+corefoundation+threads (active) Commands ‘which tcl’ and ‘whereis tcl’ return nothing. I need to find Tcl’s ‘include' and ‘lib' directories in order to compile VMD’s plugins. The command sudo find /opt -name “tcl*” results in /opt/local/bin/tclsh8.6 /opt/local/bin/tclsh and /opt/local/include /opt/local/lib/tcl8 /opt/local/lib/tcl8.6 There I see some Tcl header and library files. Are these the files that I have to use? Is the main Tcl executable called “tclsh” instead of the bare “tcl”? When I set the TCLINC=/opt/local/include/ and TCLLIB=/opt/local/lib/tcl8.6/ and run the compilation as gmake MACOSX TCLINC=$TCLINC TCLLIB=$TCLLIB/lib_MACOSX it crashes with the following error: gmake[1]: Entering directory '/Users/mabalenk/install/vmd/plugins' gmake[2]: Entering directory '/Users/mabalenk/install/vmd/plugins/molfile_plugin' Building Molecule File Reader plugins c++: error: /opt/local/lib/tcl8.6//lib_MACOSX: No such file or directory gmake[2]: *** [Makefile:381: vtfplugin.so] Error 1 gmake[2]: Leaving directory '/Users/mabalenk/install/vmd/plugins/molfile_plugin' gmake[1]: *** [Makefile:154: molfilelibs] Error 1 gmake[1]: Leaving directory '/Users/mabalenk/install/vmd/plugins' gmake: *** [Make-arch:437: MACOSX] Error 2 What is this magical lib_MACOSX and where do I find it? Thank you for your help and have a great day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ http://mabalenk.gitlab.io
Re: [dc desk calculator]
Hello everybody, Thank you very much for all of your comments and suggestions. Learning the "rare RPN" is exactly the reason behind my interest in `dc`. Thank you and have a great day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ http://mabalenk.gitlab.io > On 13 Jul 2021, at 03:11, Richard L. Hamilton wrote: > > This might be true (that bc and dc are together) for historical reasons. > Commercial Unix source has bc as a front end to dc; only the rare RPN fan > used dc directly. The GNU version does not do that, their bc is not dependent > on dc. > >> On Jul 12, 2021, at 20:04, Richard L. Hamilton wrote: >> >> The bc port includes dc. >> >>> On Jul 12, 2021, at 19:27, raf via macports-users >>> wrote: >>> >>> On Mon, Jul 12, 2021 at 06:06:47PM +0300, Maxim Abalenkov >>> wrote: >>> >>>> Dear all, >>>> >>>> How are you? I hope all is well with you. Would you please tell me, if the >>>> dc (desk calculator) is available via MacPorts: >>>> >>>> https://en.wikipedia.org/wiki/Dc_%28computer_program%29 >>>> <https://en.wikipedia.org/wiki/Dc_(computer_program)> >>>> >>>> I wasn’t able to find via the `port search` command. On the other hand, I >>>> wasn’t able to find `dc` in source code either. If you have any hints or >>>> pointers, please let me know. Thank you and have a wonderful day ahead! >>>> >>>> — >>>> Best wishes, >>>> Maxim >>> >>> /usr/bin/dc is already present. >>> >>>> dc --version >>> dc (GNU bc 1.06) 1.3 >>> >>> Copyright 1994, 1997, 1998, 2000 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, >>> to the extent permitted by law. >>> >> >> >
[dc desk calculator]
Dear all, How are you? I hope all is well with you. Would you please tell me, if the dc (desk calculator) is available via MacPorts: https://en.wikipedia.org/wiki/Dc_%28computer_program%29 <https://en.wikipedia.org/wiki/Dc_(computer_program)> I wasn’t able to find via the `port search` command. On the other hand, I wasn’t able to find `dc` in source code either. If you have any hints or pointers, please let me know. Thank you and have a wonderful day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ http://mabalenk.gitlab.io
Re: gcc<10 on M1 Mac
Hello Franco et al., How are you? I’m not an expert on MacPorts dependencies, but you may/should be able to compile your Fortran code with the GNU11 toolchain. Potentially, you only need to specify the Fortran standard that your code supports. This is possible via the -std flag to gfortran, e.g. gfortran -std=f95 … -std=std Specify the standard to which the program is expected to conform, which may be one of ‘f95’, ‘f2003’, ‘f2008’, ‘f2018’, ‘gnu’, or ‘legacy’. The default value for std is ‘gnu’, which specifies a superset of the latest Fortran standard that includes all of the extensions supported by GNU Fortran, although warnings will be given for obsolete extensions not recommended for use in new code. The ‘legacy’ value is equivalent but without the warnings for obsolete extensions, and may be useful for old non-standard programs. The ‘f95’, ‘f2003’, ‘f2008’, and ‘f2018’ values specify strict conformance to the Fortran 95, Fortran 2003, Fortran 2008 and Fortran 2018 standards, respectively; errors are given for all extensions beyond the relevant language standard, and warnings are given for the Fortran 77 features that are permitted but obsolescent in later standards. The deprecated option ‘-std=f2008ts’ acts as an alias for ‘-std=f2018’. It is only present for backwards compatibility with earlier gfortran versions and should not be used any more. For more information please see: https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ http://mabalenk.gitlab.io > On 18 Jun 2021, at 18:06, VACCARI FRANCO wrote: > > I’ve a temporary access to a new MacBook Air with M1 processor, to test on > that Mac all our home made programs, mainly fortran. All external packages > needed by our workflow were successfully installed (gnuplot, ImageMagick, > gmt4 and many others), and I installed gcc11. > > Such modern compiler complains about some features in our code that are no > longer supported, and fails to produce the executable. Of course one day we > should update that code, but for the time being, and having to give back that > Mac, I wanted to try with an older compiler. I installed gcc10 but that > didn’t help. > > I know that gcc8 works with our codes, so I tried to install that but failed. > > The problem is that gcc8 requires libcc9, and that is marked as incompatible. > > % sudo port install gcc8 > ---> Computing dependencies for gcc8 > The following dependencies will be installed: > libgcc8 > libgcc9 > Continue? [Y/n]: > ---> Fetching archive for libgcc9 > ---> Attempting to fetch libgcc9-9.4.0_0.darwin_20.arm64.tbz2 from > https://fra.de.packages.macports.org/libgcc9 > ---> Attempting to fetch libgcc9-9.4.0_0.darwin_20.arm64.tbz2 from > http://fco.it.packages.macports.org/libgcc9 > ---> Attempting to fetch libgcc9-9.4.0_0.darwin_20.arm64.tbz2 from > https://packages.macports.org/libgcc9 > ---> Fetching distfiles for libgcc9 > Error: gcc9 9.4.0 is not supported on Darwin 20 arm > Error: Failed to fetch libgcc9: incompatible OS X version > Error: See > /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/libgcc9/main.log > for details. > Error: Follow https://guide.macports.org/#project.tickets if you believe there > is a bug. > Error: Processing of port gcc8 failed > locadmin@eAir ~ % > > Actually any version from 5 to 9 requires libcc9 > > sudo port install gcc5 > ---> Computing dependencies for gcc5 > The following dependencies will be installed: > isl18 > libgcc6 > libgcc7 > libgcc8 > libgcc9 > Continue? [Y/n]: > > and therefore fails to install. > > gcc49 is a different story, as it’s clearly declared unsupported for Xcode 9 > or greater: > > sudo port install gcc49 > Password: > ---> Fetching distfiles for gcc49 > Error: building gcc49 is not supported with Xcode 9 or greater > Error: Failed to fetch gcc49: unsupported platform > Error: See > /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc49/gcc49/main.log > for details. > Error: Follow https://guide.macports.org/#project.tickets if you believe there > is a bug. > Error: Processing of port gcc49 failed > > Is it really so that gcc9 and earlier will never be compatible with M1 Macs? > And why libgcc9 is needed by gcc5? > > Thanks > > Franco > >
Re: [Xfig hangs on start]
Hello Christopher et al., Thank you very much for your help! It worked. I’m very glad to see the familiar old-school look of Xfig. I had it on my mind that something may be wrong with X11 server, but forgot about it. Thank you! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ http://mabalenk.gitlab.io > On 17 May 2021, at 10:30, Christopher Jones wrote: > > Hi, > > fig is an X11 application, and thuis requires an X11 server to be installed > to work. Do you have one installed ? If you are not sure run > > sudo port install xorg-server > > and follow the instructions at the end to log out and back in again, and then > retry running xfig. > > Chris > >> On 17 May 2021, at 8:20 am, Maxim Abalenkov > <mailto:maxim.abalen...@gmail.com>> wrote: >> >> Dear all, >> >> How are you? I need help launching Xfig @ macOS BigSur 11.3.1. Yesterday I >> installed the Xfig port (xfig @3.2.8a_0). It installed successfully. But >> when I try to launch it from the terminal it hangs. Nothing happens. Would >> you please help me to find the problem? I tried to “clean" the port and >> install it again, but it didn’t help. Thank you and have a good day ahead! >> >> — >> Best wishes, >> Maxim >> >> Maxim Abalenkov \\ maxim.abalen...@gmail.com >> <mailto:maxim.abalen...@gmail.com> >> +44 7 486 486 505 \\ http://mabalenk.gitlab.io <http://mabalenk.gitlab.io/>
[Xfig hangs on start]
Dear all, How are you? I need help launching Xfig @ macOS BigSur 11.3.1. Yesterday I installed the Xfig port (xfig @3.2.8a_0). It installed successfully. But when I try to launch it from the terminal it hangs. Nothing happens. Would you please help me to find the problem? I tried to “clean" the port and install it again, but it didn’t help. Thank you and have a good day ahead! — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ http://mabalenk.gitlab.io
