macOS (Monterey, 12.4) EGSnrc configuration failure

[walleludvig]

Hi all,

I am seeking help to install and configure EGSnrc on my mac running macOS 12.4 Monterey. I have followed the installation instructions rigorously and downloaded EGS using the first listed option (by cloning the git repository), however I am experiencing an issue with the configuration.

After accepting the automatically generated compiler/linker switches:

============================================================================================ Using the following compiler/linker switches for creating/linking against dynamic shared objects (DSO, also known as shared library or DLL), where $ (abs_dso) or $ (ABS_DSO) below will be replaced with the absolute path to the EGSnrc DSO directory at compile/link time:

1) Optimization options: -O2 -mtune=native 2) Generation of position independent code:
3) Preprocessor defines: -DOSX 4) Flag for creating shared libraries: -dynamiclib 5) Output/dlopen library: -o $@ 6) DSO path encoded in the executable: -L$(abs_dso) 7) Linking against library some_lib: -lsome_lib 8) Fortran libraries needed by C++ linker: -L/usr/local/Cellar/gcc/11.3.0_2/bin/../lib/gcc/11/gcc/x86_64-apple-darwin21/11 -L/usr/local/Cellar/gcc/11.3.0_2/bin/../lib/gcc/11/gcc -L/usr/local/Cellar/gcc/11.3.0_2/bin/../lib/gcc/11/gcc/x86_64-apple-darwin21/11/../../.. -lgfortran -lemutls_w -lquadmath -lm 9) Creating library bundles on OSX: -L/usr/local/Cellar/gcc/11.3.0_2/bin/../lib/gcc/11/gcc/x86_64-apple-darwin21/11 -L/usr/local/Cellar/gcc/11.3.0_2/bin/../lib/gcc/11/gcc -L/usr/local/Cellar/gcc/11.3.0_2/bin/../lib/gcc/11/gcc/x86_64-apple-darwin21/11/../../.. -lgfortran -lemutls_w -lquadmath -lm

I hit enter to proceed and get the following error:

============================================================================================ Creating C++ config file ... OK Building the IAEA phase space library ... Failed Building the EGSnrc C++ class library ... Failed

These settings did not work out. You may edit the source code (in case you can see where the problem is when building the C++ libraries from the configure.log file) and/or try different compiler/linker options.

============================================================================================

Additionally, ctcreate and dosxyz_show was skipped during compiling with the following message: "Skipping (no C compiler)"

Any help and tips that might get me closer to solving this issue is greatly appreciated!

[mxxo]

Hi @walleludvig,

Can you attach your configure.log from HEN_HOUSE/log/? It will have a different name depending on your system, on linux mine is called configure-linux.log.

[walleludvig]

Thanks for responding @mxxo,

my HEN_HOUSE/log/ directory appears to be empty, however I located a file, configure.log in HEN_HOUSE/scripts/.

Here is that file:

configure.log

[ftessier]

There is an issue with the C compilation linking step:

CC = gcc
C_FLAGS = -O2
Fortran compile OK
C compile OK
ld: warning: ignoring file c_conftest.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64

The following (new?) Fortran name mangling schemes are missing from the configure script: _junk_ and _junk_junk_, i.e., with a prepended _ symbol. Try the following patch on the configure script:

diff --git a/HEN_HOUSE/scripts/configure b/HEN_HOUSE/scripts/configure
index 18ba5fa9..591afcdb 100755
--- a/HEN_HOUSE/scripts/configure
+++ b/HEN_HOUSE/scripts/configure
@@ -1492,6 +1492,12 @@ void JUNK_JUNK_() {
 void JUNK_JUNK__() {
   printf("JUNK_JUNK__\n");
 }
+void _junk_() {
+  printf("_junk_");
+}
+void _junk_() {
+  printf("_junk_junk_");
+}
 _ACEOF
     if { (eval $testc_compile) 2>&5; test_status=$?; (exit $test_status); }; then
       echo "C compile OK" >&5
@@ -1530,6 +1536,11 @@ _ACEOF
             f77_function2="#define F77_OBJ_(fname,FNAME) FNAME##__"
             print_scheme="upper case, _ and __"
             ;;
+          _junk__junk_junk_)
+            f77_function1="#define F77_OBJ(fname,FNAME) _fname##_"
+            f77_function2="#define F77_OBJ_(fname,FNAME) _fname##_"
+            print_scheme="lower case, enclosing _"
+            ;;
           *) found_scheme=no
         esac
       else

You can save this content in a patch file under your EGSnrc directory and run git apply patch from there.

[walleludvig]

Thank you for your response @ftessier,

I attempted your suggestion and applied the patch file, however the C compilation linking still seem to fail:

Looking for available C compilers ...             found: gcc cc c89

Input C compiler:                                 [gcc] 
Input C compiler flags to use:                    [-O2]             
Checking for fortran name mangling scheme ...     C compilation fails
failed to determine

Here is also all of the output generated when I run the configuration script (in case it might be useful): configure_output.txt

I greatly appreciate your help.

[ftessier]

@walleludvig can you share your configure.log file again? The other issue is building for macOS-x86_64 but attempting to link with file built for unknown-arm64, but I don't understand from your initial configure.log why it is building for unknown-arm64 (Apple M1 chip?).

[walleludvig]

@ftessier here is the configure.log file: configure.log

The issue might be due to the processor as you suggest, I have got the M1 pro chip if that may be relevant.

[ftessier]

Oh wait, there was a mistake in my patch! Try this instead:

diff --git a/HEN_HOUSE/scripts/configure b/HEN_HOUSE/scripts/configure
index 810cf3b4..21bfc351 100755
--- a/HEN_HOUSE/scripts/configure
+++ b/HEN_HOUSE/scripts/configure
@@ -1490,6 +1490,12 @@ void JUNK_JUNK_() {
 void JUNK_JUNK__() {
   printf("JUNK_JUNK__\n");
 }
+void _junk_() {
+  printf("_junk_");
+}
+void _junk_junk_() {
+  printf("_junk_junk_");
+}
 _ACEOF
     if { (eval $testc_compile) 2>&5; test_status=$?; (exit $test_status); }; then
       echo "C compile OK" >&5
@@ -1528,6 +1534,11 @@ _ACEOF
             f77_function2="#define F77_OBJ_(fname,FNAME) FNAME##__"
             print_scheme="upper case, _ and __"
             ;;
+          _junk__junk_junk_)
+            f77_function1="#define F77_OBJ(fname,FNAME) _fname##_"
+            f77_function2="#define F77_OBJ_(fname,FNAME) _fname##_"
+            print_scheme="lower case, enclosing _"
+            ;;
           *) found_scheme=no
         esac
       else

[walleludvig]

Thanks for the update @ftessier,

Unfortunately I am still experiencing the same issue that building the IAEA phase space library and EGSnrc C++ class library fails. However, the search for C compilers section look slightly different (it does not say that C compilation fails):

Looking for available C compilers ...             found: gcc cc c89

Input C compiler:                                 [gcc] 
Input C compiler flags to use:                    [-O2] 
Checking for fortran name mangling scheme ...     failed to determine

Here's the current configure.log: configure.log

[ftessier]

Ok, that is (very small) progress. I don't have an M1 on hand, so thanks for reporting quickly!

[ftessier]

Ok never mind my patches, red herring. The issue seems to lie with the compiling target differences for the Fortran vs C conftest programs.

[ftessier]

@walleludvig can you run gfortran -v and gcc -v and report what the Target: lines are?

[walleludvig]

@ftessier,

Apologies for the delayed message. I live in Australia so the time differences are presumably pretty bad.

Regarding your most recent message, the target lines are:

gfortran: x86_64-apple-darwin21

gcc: arm64-apple-darwin21.5.0

[ftessier]

So this explains the issue! gcc is building for arm-64 and gfortran for x86_64. Linking those two objects does not work. I presume your gcc is in fact calling clang (you can confirm this with the output of gcc -v). You have to use gcc-11 (or equivalent for your version) to use the Homebrew installed GNU compiler. As far as I can tell, gcc started supporting arm64 in version 12 only.

So I see two potential solutions, let me know how it pans out:

Use the GNU compilers throughout

Set your C and C++ compilers to gcc-11 and g++-11 (or whatever version you have) during configuration:

Looking for available C compilers ...             found: gcc cc c89
Input C compiler:                                 [gcc] gcc-11
...
Found the following C++ compilers in your search path:
g++ CC KCC
Input C++ compiler:                               [g++]: g++-11

I am guessing If you want arm64 support, you may try to install gcc version 12 with brew install gcc@12 and set gfortran-12, gcc-12 and g++-12 in the configuration? See if gfortran-12 -v and gcc-12 -v report an arm64 target on your machine.

Set clang target

Set an explicit target for the clang compilation, by entering -O2 -march=x86-64 when prompted for the C compiler flags:

Input C compiler flags to use:                    [-O2] -O2 -march=x86-64 

You will probably need the same thing for the g++ compiler options:

1) Optimization options:                          -O2 -march=x86-64 -mcmodel=medium -std=c++14

[walleludvig]

Hi @ftessier,

Thanks again,

I have tried both of your suggestions. When attempting to use the GNU compilers throughout it solve one issue at the start, because now ctcreate compiled, however dosxyz_show still fails as well as IAEA phase space library and C++ class library fails. Here's my terminal output from configuration run: GNU_compile.txt

When attempting to set clang target I still experience the same original issue. It may seems as it didn't affect the configuration, however I may still have missed something. This is the configuration run from that: clang_target.txt

[mchamberland]

@walleludvig can you share the configure log, please?

[walleludvig]

Here's my configure-osx.log @mchamberland configure-osx.log

[ftessier]

Thanks for trying that. There is still a mismatch with the targets, hugh:

ld: warning: ignoring file c_conftest.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
Undefined symbols for architecture x86_64:

Small progress here: the target is now macOS-x86_64, instead of arm64. At this point you can try to remove the -mtune=native flag and set the target explicitly for gfortran as well. The name of the game here is to match the targets from gfortran and clang so that they can be linked by the llvm linker. You can run gfortran --target to see a list of possible targets.

By the way, for expediency you may want to test directly with small c and fortran codes instead of running the configuration, e.g.,

c_test.c

#include <stdio.h>

void foo_() {
  printf("foo_");
}

void foo_foo_() {
  printf("foo_foo_\n");
}

f_test.f

      program test
      call foo
      call foo_foo
      end

Compile and (try to) link

gfortran -c f_test.f
gcc -c c_test.c
gfortran -o test f_test.o c_test.o
./test

Then you can test various compilation flags to gfortran and gcc until that works?

@mchamberland do you have an M1 cpu on hand by any chance?

[mchamberland]

@ftessier Hang in there, next week I will have an M2.... ;)

[mchamberland]

@ftessier M2 MacBook Air acquired!

Out of the box and with the Homebrew tools (gcc-11, g++-11), egs++ compilation fails because it passes the wrong option to the c++ compiler. Somehow, it passes -qmkshrobj, which comes from here.

My workaround was just to change that line to -bundle because I cannot figure out how it ends up there in the configure script.

Working on compiling egs_view now, which is very tricky... any tips to force QT to use the Homebrew stuff instead of the Apple Clang tools?

[ftessier]

Thanks for testing. Arrgh, I don't know how to coerce QT to use the (real) gcc. I presume it will prove saner (in the long run) to figure out how to adjust the EGSnrc configuration scripts so that they work out-of-the-box on (arm64) macOS.

[mchamberland]

@ftessier Well, I got egs_view compiled. Now let's see if it actually works... If it does, I'll share what I did.

[mchamberland]

Success!

[mchamberland]

@ftessier For the record:

1. I added:

   export QTDIR="/opt/homebrew/Cellar/qt@5/5.15.5_1"
   export QMAKESPEC="/opt/homebrew/Cellar/qt@5/5.15.5_1/mkspecs/macx-g++"

   to my .zshrc file.

2. In /opt/homebrew/Cellar/qt@5/5.15.5_1/mkspecs/common/macx.conf, I added: QMAKE_APPLE_DEVICE_ARCHS = arm64

3. And in /opt/homebrew/Cellar/qt@5/5.15.5_1/mkspecs/common/g++-base.conf, I specified the Homebrew versions of gcc and g++ (gcc-11 and g++-11 respectively on my system) to QMAKE_COMPILER, QMAKE_CC, and QMAKE_CXX. So it looks like this:

   
   QMAKE_COMPILER          = gcc-11

QMAKE_CC = $${CROSS_COMPILE}gcc-11

QMAKE_LINK_C = $$QMAKE_CC QMAKE_LINK_C_SHLIB = $$QMAKE_CC

QMAKE_CXX = $${CROSS_COMPILE}g++-11

[mchamberland]

@ftessier I have not compiled any of the other GUIs, which I do not typically use.

[ftessier]

Thanks a bunch, this information will prove extremely useful! 🙏🏻

[ftessier]

So, just to be clear, you did not encounter the linking issue reported by @walleludvig?

[ftessier]

Out of the box and with the Homebrew tools (gcc-11, g++-11), egs++ compilation fails because it passes the wrong option to the c++ compiler. Somehow, it passes -qmkshrobj, which comes from here.

Then we might want to adjust the configuration script so that it recognizes g++-*? In your case g++11 does not match the case pattern g++, so the default arm with -qmkshrobj is executed instead.

[mchamberland]

@ftessier I did not encounter the linking issue reported above.

[ftessier]

@walleludvig, any luck, any progress?

[mchamberland]

Out of the box and with the Homebrew tools (gcc-11, g++-11), egs++ compilation fails because it passes the wrong option to the c++ compiler. Somehow, it passes -qmkshrobj, which comes from here.

Then we might want to adjust the configuration script so that it recognizes g++-*? In your case g++11 does not match the case pattern g++, so the default arm with -qmkshrobj is executed instead.

Ah, that makes sense! Yes, for people installing gcc with Homebrew when the Apple tools are already present, I believe the default pattern will be gcc-*, with the latest version appended, e.g., gcc-11.

[walleludvig]

Hi @ftessier,

I have not made progress with this issue, however I may not quite understand your suggested method on how to compile and link with various flags for gfortran and gcc. I followed your instructions and get the following (expected) linking issue arose:

ld: warning: ignoring file c_test.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
Undefined symbols for architecture x86_64:
  "_foo_", referenced from:
      _MAIN__ in f_test.o
  "_foo_foo_", referenced from:
      _MAIN__ in f_test.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

I have tried this for several different compilation flags for gfortran from the list of possible gfortran targets. I've done this by trying one at a time by: (eg. with m64 as the target option)

gfortran -c -m64 f_test.f
gcc -c c_test.c
gfortran -o test f_test.o c_test.o

Is there something in your instructions that I have misunderstood?

[ftessier]

Ok, thanks for the update. To be honest I am flying blind here. What I know is that when you run gfortran --verbose and gcc --verbose you want the Target: lines to match (or be compatible). I am just surprised that it worked for Marc!? @mchamberland, care to share your Target: lines on the M2?

[walleludvig]

@ftessier Not quite sure if this is at all helpful but can it be related to any of the following warnings I get when running $brew doctor?

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
  /opt/anaconda3/bin/icu-config
  /opt/anaconda3/bin/krb5-config
  /opt/anaconda3/bin/freetype-config
  /opt/anaconda3/bin/xslt-config
  /opt/anaconda3/bin/libpng16-config
  /opt/anaconda3/bin/libpng-config
  /opt/anaconda3/bin/xml2-config
  /opt/anaconda3/bin/python3-config
  /opt/anaconda3/bin/curl-config
  /opt/anaconda3/bin/ncursesw6-config
  /opt/anaconda3/bin/pcre-config
  /opt/anaconda3/bin/python3.8-config

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/libtcl8.6.dylib
  /usr/local/lib/libtk8.6.dylib

Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected header files:
  /usr/local/include/fakemysql.h
  /usr/local/include/fakepq.h
  /usr/local/include/fakesql.h
  /usr/local/include/itcl.h
  /usr/local/include/itcl2TclOO.h
  /usr/local/include/itclDecls.h
  /usr/local/include/itclInt.h
  /usr/local/include/itclIntDecls.h
  /usr/local/include/itclMigrate2TclCore.h
  /usr/local/include/itclTclIntStubsFcn.h
  /usr/local/include/mysqlStubs.h
  /usr/local/include/odbcStubs.h
  /usr/local/include/pqStubs.h
  /usr/local/include/tcl.h
  /usr/local/include/tclDecls.h
  /usr/local/include/tclOO.h
  /usr/local/include/tclOODecls.h
  /usr/local/include/tclPlatDecls.h
  /usr/local/include/tclThread.h
  /usr/local/include/tclTomMath.h
  /usr/local/include/tclTomMathDecls.h
  /usr/local/include/tdbc.h
  /usr/local/include/tdbcDecls.h
  /usr/local/include/tdbcInt.h
  /usr/local/include/tk.h
  /usr/local/include/tkDecls.h
  /usr/local/include/tkPlatDecls.h

Warning: Unbrewed '.pc' files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected '.pc' files:
  /usr/local/lib/pkgconfig/tcl.pc
  /usr/local/lib/pkgconfig/tk.pc

Warning: Unbrewed static libraries 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 static libraries:
  /usr/local/lib/libtclstub8.6.a
  /usr/local/lib/libtkstub8.6.a

[ftessier]

I doubt it. The EGSnrc script is not related to the typical autoconf ./configure script often found in software packages. It does not rely on any of the files listed above, which all relate to python or tcl/tk (dev files). All we care about is what specific gfortran or gcc executable is invoked. I mean it is not a bad idea to address the Homebrew message, but it is unlikely it is the source of the issue here.

[mchamberland]

Here's what I get for the verbose output:

~ » gfortran --verbose                                                                 marc@Moridin
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.3.0_2/bin/../libexec/gcc/aarch64-apple-darwin21/11/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 11.3.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --build=aarch64-apple-darwin21 --with-system-zlib --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Homebrew GCC 11.3.0_2)
(base) ---------------------------------------------------------------------------------------------
~ » gcc-11 --verbose                                                                   marc@Moridin
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.3.0_2/bin/../libexec/gcc/aarch64-apple-darwin21/11/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 11.3.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --build=aarch64-apple-darwin21 --with-system-zlib --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Homebrew GCC 11.3.0_2)
(base) ---------------------------------------------------------------------------------------------
~ » g++-11 --verbose                                                                   marc@Moridin
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.3.0_2/bin/../libexec/gcc/aarch64-apple-darwin21/11/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 11.3.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --build=aarch64-apple-darwin21 --with-system-zlib --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Homebrew GCC 11.3.0_2)
(base) ---------------------------------------------------------------------------------------------

@walleludvig Can you share the content of /opt/Homebrew/bin ?

[mchamberland]

@walleludvig Also, please run and share the output of:

>which gfortran
>which gcc
>which g++

[walleludvig]

Hi @mchamberland,

the contents showing up from '''ls''' in '''/opt/Homebrew/bin''' is only '''brew'''.

'''

which gfortran /usr/local/bin/gfortran

which gcc /usr/bin/gcc

which g++ /usr/bin/g++ '''

[mchamberland]

@walleludvig Hmm... None of those look like they came from brew. Can you try installing gcc from brew again?

>brew install gcc

When I did that earlier this week, it installed version 11 of gcc, and it placed gfortran-11, gcc-11, and g++-11 in /opt/Homebrew/bin. Then in the EGSnrc configure script, you would specify those compilers.

But you'll need to change the configure_c++ script in HEN_HOUSE/scripts/ with the change I referred to above, which is replacing -qmkshrobj with -bundle on this line.

[mchamberland]

@walleludvig and if you want to compile egs_view, you'll want to install QT5 with brew:

>brew install qt@5

And make the changes I mentioned further above.

If instead you're working with BEAMnrc and the other GUIs, then I haven't tried those yet.

[mchamberland]

@walleludvig oooh, I noticed you have /usr/local/Cellar in your first post above. I think this might be from an older version of brew or an older version macOS. Nowadays, brew puts everything under /opt/Homebrew.

So, here's my recommendation: uninstall brew completely. You can look up instructions online. Then, reinstall brew and gcc.

Hopefully, this helps resolve some of your issues.

[walleludvig]

Hi @mchamberland and @ftessier,

First of all, thank you so much for sticking through with this and not giving up. I greatly appreciate your aptitude at getting this issue solved.

After following @mchamberland most recent guidelines I have finally got EGSnrc configured successfully, what a relief! :)

However, during the configuration it was reported that ctcreate Failed and dosxyz_show Failed. Moreover, I do struggle with compiling egs_view. For reference this is the config.log files (total 2):

configure-osx-ludvigwalle.log configure-osx.log

I tried to do as @mchamberland suggested in the above thread above on how to solve egs_view compilation issues however when attempting to run egs_view I am still told that the "command is not found". I have also tried to with the more recent qt version (i.e. qt 6.3.1_1).

Any suggestions as to what is going wrong/what I may have done wrong?

[mchamberland]

@walleludvig Great news! For dosxyz_show, you need extra libraries installed, but there are more modern options to display your dose distributions from dosxyz, so I wouldn't bother with it for now.

For ctcreate, it looks like you're running into the same problem as before. Weird. Maybe go to $EGS_HOME/ctcreate, then do make clean and try make again.

For egs_view, here's what I do:

1. Go to $HEN_HOUSE/[your config name]/bin using the Finder.
2. Right-click on egs_view and choose Show package contents.
3. Go down the folders to Contents --> MacOS. You should find another egs_view executable in there. Copy it to the $HEN_HOUSE/[your config]/bin folder.
4. This should now work. Maybe you'll need to restart your terminal session. (You can also delete the egs_view package; you just need the executable that you copied for it to work.)

[mchamberland]

@walleludvig The other solution to opening egs_view is to do open -a egs_view instead of just typing egs_view in the terminal.

[walleludvig]

Thanks for quick response @mchamberland,

It appears as if I do not have neither of the directories your pointing at here.

For ctcreate <$EGS_HOME/ctcreate> returns "no such file or directory", and I cannot locate it through finder either.

I also cannot find a directory with my config name in HEN_HOUSE but can go directly to a bin folder, which in turn contains a subfolder named osx. However, this does not contain any egs_view folder or file either. Lastly, <open -a egs_view> returns the following: <Unable to find application named 'egs_view'>.

[mchamberland]

Thanks for quick response @mchamberland,

It appears as if I do not have neither of the directories your pointing at here.

For ctcreate <$EGS_HOME/ctcreate> returns , and I cannot locate it through finder either.

I also cannot find a directory with my config name in HEN_HOUSE but can go directly to a bin folder, which in turn contains a subfolder named osx. However, this does not contain any egs_view folder or file either. Lastly, <open -a egs_view> returns the following: <Unable to find application named 'egs_view'>.

Oops, right, my mistake! I should have written $HEN_HOUSE/bin/[your config]

And I bet you just did not compile egs_view yet. It does not get compiled automatically with EGSnrc.

Go to $HEN_HOUSE/egs++/view, then type make and cross your fingers. This one is tricky to get right!

[walleludvig]

You are indeed correct @mchamberland, I had not compiled egs_view earlier, but when attempting now I get error code 1 as follows:

`

make /bin/qmake mymachine= MAKEFILE=Makefile hhouse= make: /bin/qmake: No such file or directory make: *** [Makefile_] Error 1 `

[mchamberland]

Looks like a bunch of environment variables are missing.

Does echo $EGS_CONFIG return anything? My first guess is you may have missed those couple of lines at the end of your .bashrc or .zshrc (if you're on a modern Mac, you may be using the default zsh shell):

export EGS_HOME=/Users/marc/dev/EGSnrc/egs_home/
export EGS_CONFIG=/Users/marc/dev/EGSnrc/HEN_HOUSE/specs/macos.conf
source /Users/marc/dev/EGSnrc/HEN_HOUSE/scripts/egsnrc_bashrc_additions

[walleludvig]

@mchamberland echo $EGS_CONFIG returns /Users/ludvigwalle/EGSnrc/HEN_HOUSE/specs/osx.conf . I am on a modern Mac and am using the default zsh shell yes

[mchamberland]

Hmm... How about echo $QTDIR ?

Also, make sure you've sourced the EGSnrc bashrc additions:

source $HEN_HOUSE/scripts/egsnrc_bashrc_additions

We'll get you there because I'm on a brand new M2 and got everything working!

[mchamberland]

@walleludvig oh and ctcreate is under $HEN_HOUSE/omega/progs/ctcreate.