Installing RST on a Mac...once more!

[mtwalach]

BUG

I am trying to install RST on a new MacBook and seeing an error I have never seen before. When running make.code. The installation aborts upon the following error:
locate.c:190:31: error: incompatible function pointer types passing 'int (struct dirent *)' to parameter of type 'int (*)(const struct dirent *)' [-Wincompatible-function-pointer-types] status=scandir(dir,&dlist,dsel,alphasort); ^~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/dirent.h:150:11: note: passing argument to parameter here int (*)(const struct dirent *), int (*)(const struct dirent **, const struct dirent **)) __DARWIN_INODE64(scandir); ^ 10 warnings and 1 error generated. make: *** [locate.o] Error 1 Compilation Aborted.

I am guessing it's something to do with the C libraries or the compiler but it is not something I have ever encountered before, so I don't know how to fix it. Any ideas?

Priority

• Minor - typo, incorrect naming, fails in a specific uncommon situation
• Major - misrepresentation of data, failure in a common situation
• Urgent - failure in usage, large misrepresentation of data

RST version

Does the bug occur in an official RST release?

• Yes. RST version: 5.0
• No. Branch containing the bug (e.g. develop): ______

Example of the bug

The error above occurs when compiling the following:

`Compiling Binary:/Users/walach/Documents/rst/codebase/analysis/src.bin/cdf/istp_plot.1.11

make clean
rm -f *.o
rm -f version.h
rm -f errstr.h
rm -f hlpstr.h
rm -f istp_plot
make
make.version /Users/walach/Documents/rst/codebase/analysis/src.bin/cdf/istp_plot.1.11
make.help
./doc/istp_plot.doc.xml `

See log file here:
superdarn-rst.build.20240403.1717.txt

Attempts

What have you tried already to fix it?
I followed @billetd's instructions (#556 (comment)) for M chipped Macs and am still getting errors.

What have you tried to work around it?
N/A

Data Access

Please describe how to obtain the data needed to reproduce the bug (e.g. specific file, use make_fit on any rawacf file).
N/A

Potential Bug Location

No idea.

Potential Solution(s)

No idea.

Extra Notes

• Software: Sonoma 14.4.1
• Hardware: Apple M3
• Compiler:
  Apple clang version 15.0.0 (clang-1500.3.9.4)
  Target: x86_64-apple-darwin23.4.0
  Thread model: posix
  InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[egthomas]

@mtwalach normally I would just suggest tar'ing (or deleting) the problematic directories since they appear to be mostly older solar wind CDF-related binaries, but it appears this issue may also arise when compiling map_addmodel. I'm not a Mac user so unfortunately I can't offer any help - sorry!

[billetd]

I'm gonna take a closer look at this at some point. I believe the main issue is in compiling certain C libraries, but not all. I've had success installing RST on M-chipped Macs under Rosetta (like in the comment you linked), but then on a separate computer not everything worked correctly. For example, using the C libraries for map and fitacf reading in IDL worked, but none of the data processing libraries (mapaddmodel, rawtofit, fitspeckremoval, etc) did.

Ultimately I'm 90% the root cause is that there is a mismatch between the compiler and the code, i.e. trying to compile x86 architecture with ARM, or vice versa. Using Rosetta can force compatibility with code written for x86 (which RST is), but something underlying is still broken using that.

[mtwalach]

Thank you both for the replies to this. I have forced it to complete, using your method @egthomas. I had to zip a total of four directories, which is not ideal:
codebase/analysis/src.bin/cdf/istp_plot.1.11 codebase/analysis/src.bin/cdf/istp_text.1.24 codebase/superdarn/src.bin/tk/tool/imfdelay.1.7 codebase/superdarn/src.bin/tk/tool/map_addimf.1.18
I don't think I have ever used the istep-related codes but would be quite keen to get the imf functionalities back...
Do you think there is anything I can do to fix it in the short term?

[RemingtonRohel]

Similar issue described here. It looks like the culprit might be these lines (which also are in istp_text.1.24, imfdelay.1.7, and map_addimf.1.18), which depend on the -D_DARWIN flag defined in makebin.darwin and makelib.darwin. Does removing the -D_DARWIN in each of these two files and compiling again with make.code fix the problem? If you get an error with transform.c, isect.c, or poly.c, (the other places the _DARWIN flag is used) then we know the flag is still needed, but only in those places.