Closed ailingzeng closed 5 months ago
Thanks for reporting the issue. It is hard to say anything because of the lack of information about your environment. The only thing I can read is that your gcc
may not come from homebrew. It is usually gcc-<version>
for the one installed by homebrew and to be used to compile our brew formula. The pure gcc
means for some reasons the formula might use your system's gcc, which is not guaranteed to work for difmap.
Would you tell me your macOS version? Also, please consider (i) running brew update
twice, and (ii) running brew doctor
and fixing all warnings (usually for non-standard settings peculiar to your environment) showing up this command. Let me know if you still have an issue.
Thanks for checking this quickly! I am using M1 Mac with MacOS Sonoma v14.0. I have gcc-14 installed with homebrew. I get the following when I check the gcc version.
(base) ailing@ailings-MacBook-Pro ~ % whereis gcc
gcc: /usr/bin/gcc
(base) ailing@ailings-MacBook-Pro ~ % whereis gcc-14
gcc-14: /opt/homebrew/bin/gcc-14 /opt/homebrew/share/man/man1/gcc-14.1
(base) ailing@ailings-MacBook-Pro ~ % which gcc
gcc: aliased to gcc-14
(base) ailing@ailings-MacBook-Pro ~ % which gcc-14
/opt/homebrew/bin/gcc-14
(base) ailing@ailings-MacBook-Pro ~ % gcc --version
gcc-14 (Homebrew GCC 14.1.0) 14.1.0
Copyright (C) 2024 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.
I also tried brew update
twice and it is already updated. brew doctor
only gives the following warnings:
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libfastsumjulia.dylib
/usr/local/lib/libfftw3.3.dylib
/usr/local/lib/libfftw3_omp.3.dylib
/usr/local/lib/libfftw3_threads.3.dylib
/usr/local/lib/libnfctjulia.dylib
/usr/local/lib/libnfft3.4.dylib
/usr/local/lib/libnfft3_threads.4.dylib
/usr/local/lib/libnfftjulia.dylib
/usr/local/lib/libnfstjulia.dylib
After this, running the installation steps, I get the same error.
@ailingzeng
Hi, I also upgraded my homebrew + some packages in our local environment (macOS 14.4.1, Intel) and now I reproduced your issues. /Users/<user>/Library/Logs/Homebrew/difmap/01.configure
shows
./configure
intel-osx-gcc
./configure: line 97: -lpgplot: command not found
Configuration follows:
BINDIR = /private/tmp/difmap-20240514-29099-2aqtqz/uvf_difmap_2.5q
INCDIR = /private/tmp/difmap-20240514-29099-2aqtqz/uvf_difmap_2.5q/include
LIBDIR = /private/tmp/difmap-20240514-29099-2aqtqz/uvf_difmap_2.5q/lib
HELPDIR = /Users/<user>/local/homebrew/Cellar/difmap/2.5q_2
PGPLOT_LIB =
CC = gcc
CCLIB = /Users/<user>/local/homebrew/Cellar/gcc/14.1.0/bin/../lib/gcc/current/gcc/x86_64-apple-darwin23/14/libgcc.a /System/Library/Frameworks/Foundation.framework/Versions/Current/Resources/BridgeSupport/Foundation.dylib /System/Library/Frameworks/AppKit.framework/Versions/Current/Resources/BridgeSupport/AppKit.dylib
FC = gfortran
CFLAGS = $(OPT) -Dintel_osx
FFLAGS = -O
LDFLAGS =
LN = ln -s
RANLIB = ranlib
PAGER = more
PGBIND_FLAGS = bsd -lentype size_t
USE_TECLA = yes
HIDE_SCRATCH_FILES = yes
Configuring make files.
The problem here is that brew can't feed the correct GCC and also actually pgplot locations for some reasons. I actually don't know why this is happening as the formula uses brew's standard macro to do it (and it had been working ok for last few years). Let me dig into this today and tomorrow. I will get back to you soon.
Thanks so much for your help. I can use Difmap in the server of our group, so it's not urgent for me to install it in my laptop.
OK I think I figured it out. The problem is that DIFMAP has a minor issue inlibtecr_src/getline.c
. Previously GCC just warned like
gcc-13 -c -O -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DUSE_TERMINFO=1 -DHAVE_CURSES_H=1 -DHAVE_TERM_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SELECT=1 -o normal_obj/getline.o ./getline.c
./getline.c: In function 'gl_print_control_sequence':
./getline.c:3931:34: warning: passing argument 3 of 'tputs' from incompatible pointer type [-Wincompatible-pointer-types]
3931 | tputs((char *)string, nline, gl_tputs_putchar);
| ^~~~~~~~~~~~~~~~
| |
| TputsRetType (*)(TputsArgType) {aka void (*)(int)}
In file included from ./getline.c:74:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/term.h:773:54: note: expected 'int (*)(int)' but argument is of type 'TputsRetType (*)(TputsArgType)' {aka 'void (*)(int)'}
773 | extern NCURSES_EXPORT(int) tputs (const char *, int, int (*)(int));
| ^~~~~~~~~~~~
In the recent homebrew, this is flagged not as a warning (which won't stop compiling) but an error (which will halt compiling) regardless of the version of GCC (I reproduced this issue for both GCC 13 and 14).
Because of failures in compiling libtecr.a
, header files related to the library weren't copied in the ./include
directory, ultimately causing the errors in compiling other libraries using libtecr.a
.
I tentatively fixed this issue by adding -Wno-error=incompatible-pointer-types
to compile source codes in the libtecr_src
directory to ignore this issue. This doesn't solve the issue in the source code, but would work as an ad-hoc fix to compile Difmap without an error. Please consider reaching out to DIFMAP's developers (e.g. M. Shepherd) as I can't fix its source code.
Anyway, please try out the latest rev 3 formula fixed by the latest commit. You can do by
brew untap kazuakiyama/difmap
brew tap kazuakiyama/difmap
brew install difmap
I've closed the issue. Please feel free to reopen if you still have the issue.
I followed these steps:
And
brew install difmap
returns the following error: