As for the static build, this:

/Users/mathomp4/installed/Compiler/nag-7.0_7062/openmpi/4.1.1-static/bin/mpicc
~/MPITests/helloWorld.c  -lopen-orted-mpir

does work, but there is no way I could change all our model scripting to
add that flag all over the place. Is there a way to "stuff"
-lopen-orted-mpir into the main wrappers:

❯
/Users/mathomp4/installed/Compiler/nag-7.0_7062/openmpi/4.1.1-static/bin/mpicc
-show
gcc
-I/Users/mathomp4/installed/Compiler/nag-7.0_7062/openmpi/4.1.1-static/include
-L/Users/mathomp4/installed/Compiler/nag-7.0_7062/openmpi/4.1.1-static/lib
-lmpi -lopen-rte -lopen-pal -lm -lz

so that I don't need to remember it every time?

On Fri, Oct 29, 2021 at 10:32 AM Matt Thompson <fort...@gmail.com> wrote:

> So, an update. Nothing I seem to do with libtool seems to help, but I'm
> trying various things. For example, I tried editing libtool to use:
>
> -Wl,-Wl,,-dynamiclib
>
> and also:
>
> -Wl,-Wl,,-install_name -Wl,-Wl,,\$rpath/\$soname
>
> as that also threw an error (not a NAG flag). And when I did that, I get
> this:
>
> clang: error: no such file or directory:
> '/Users/mathomp4/installed/Compiler/nag-7.0_7048/openmpi/4.1.1-basic-gilles/lib/libmpi_usempi.40.dylib'
>
> Somehow it's looking for a file in the install path and I think it's
> because of an extra space. When I run with make V=1:
>
> ,-Wl,,-install_name -Wl,-Wl,,
> /Users/mathomp4/installed/Compiler/nag-7.0_7048/openmpi/4.1.1-basic-gilles/lib/libmpi_usempi.40.dylib
>
> That space between the -Wl,, and the /Users... install path is causing
> issues.
>
> Sigh. I guess it's time to try and figure out how to get the static build
> to work.
>
> On Fri, Oct 29, 2021 at 8:24 AM Matt Thompson <fort...@gmail.com> wrote:
>
>> Gilles,
>>
>> I tried both NAG 7.0.7062 and 7.0.7048. Both fail in the same way. And I
>> was using the official tarball from the Open MPI website. I downloaded it
>> long ago and then kept it around.
>>
>> And I didn't run autogen.pl, no, but I could try that.
>>
>> And...I do see CC=nagfor in the libtool file. But, why would libtool
>> *ever* use CC="nagfor"? I mean, I see it in the file, but I specifically
>> told configure that CC=gcc (or CC=clang). Only FC should be nagfor.
>>
>> On Thu, Oct 28, 2021 at 8:51 PM Gilles Gouaillardet via users <
>> users@lists.open-mpi.org> wrote:
>>
>>> Matt,
>>>
>>> did you build the same Open MPI 4.1.1 from an official tarball with the
>>> previous NAG Fortran?
>>> did you run autogen.pl (--force) ?
>>>
>>> Just to be sure, can you rerun the same test with the previous NAG
>>> version?
>>>
>>>
>>> When using static libraries, you can try manually linking with
>>> -lopen-orted-mpir and see if it helps.
>>> If you want to use shared libraries, I would try to run configure,
>>> and then edit the generated libtool file:
>>> look a line like
>>>
>>> CC="nagfor"
>>>
>>> and then edit the next line
>>>
>>>
>>> # Commands used to build a shared archive.
>>>
>>> archive_cmds="\$CC -dynamiclib \$allow_undef ..."
>>>
>>> simply manually remove "-dynamiclib" here and see if it helps
>>>
>>>
>>> Cheers,
>>>
>>> Gilles
>>> On Fri, Oct 29, 2021 at 12:30 AM Matt Thompson via users <
>>> users@lists.open-mpi.org> wrote:
>>>
>>>> Dear Open MPI Gurus,
>>>>
>>>> This is a...confusing one. For some reason, I cannot build a working
>>>> Open MPI with NAG 7.0.7062 and clang on my MacBook running macOS 11.6.1.
>>>> The thing is, I could do this back in July with NAG 7.0.7048. So my fear is
>>>> that something changed with macOS, or clang/xcode, or something in between.
>>>>
>>>> So here are the symptoms, I usually build with a few extra flags that
>>>> I've always carried around but for now I'm going to go basic. First, I try
>>>> to build Open MPI in a basic way:
>>>>
>>>> ../configure FCFLAGS"=-mismatch_all -fpp" CC=clang CXX=clang++
>>>> FC=nagfor
>>>> --prefix=$HOME/installed/Compiler/nag-7.0_7062/openmpi/4.1.1-basic |& tee
>>>> configure.log
>>>>
>>>> Note that the FCFLAGS are needed for NAG since it doesn't preprocess
>>>> .F90 files by default (so -fpp) and it can be *very* strict with interfaces
>>>> and any slight interface difference is an error so we use -mismatch_all.
>>>>
>>>> Now with this configure line, I then build and:
>>>>
>>>> Making all in mpi/fortran/use-mpi-tkr
>>>> make[2]: Entering directory
>>>> '/Users/mathomp4/src/MPI/openmpi-4.1.1/build-basic/ompi/mpi/fortran/use-mpi-tkr'
>>>>   FCLD     libmpi_usempi.la
>>>> NAG Fortran Compiler Release 7.0(Yurakucho) Build 7062
>>>> Option error: Unrecognised option -dynamiclib
>>>> make[2]: *** [Makefile:1966: libmpi_usempi.la] Error 2
>>>> make[2]: Leaving directory
>>>> '/Users/mathomp4/src/MPI/openmpi-4.1.1/build-basic/ompi/mpi/fortran/use-mpi-tkr'
>>>> make[1]: *** [Makefile:3555: all-recursive] Error 1
>>>> make[1]: Leaving directory
>>>> '/Users/mathomp4/src/MPI/openmpi-4.1.1/build-basic/ompi'
>>>> make: *** [Makefile:1901: all-recursive] Error 1
>>>>
>>>> For some reason, the make system is trying to pass a clang option,
>>>> -dynamiclib, to nagfor and it fails. With verbose on:
>>>>
>>>> libtool: link: nagfor -dynamiclib -Wl,-Wl,,-undefined
>>>> -Wl,-Wl,,dynamic_lookup -o .libs/libmpi_usempi.40.dylib  .libs/mpi.o
>>>> .libs/mpi_aint_add_f90.o .libs/mpi_aint_diff_f90.o
>>>> .libs/mpi_comm_spawn_multiple_f90.o .libs/mpi_testall_f90.o
>>>> .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o .libs/mpi_waitsome_f90.o
>>>> .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o .libs/mpi-tkr-sizeof.o...
>>>>
>>>> As a test, I tried the same thing with NAG 7.0.7048 (which worked in
>>>> July) and I get the same issue:
>>>>
>>>> Option error: Unrecognised option -dynamiclib
>>>>
>>>> Note, that Intel Fortran and Gfortran *do* support this flag, but NAG
>>>> has something like:
>>>>
>>>>        -Bbinding Specify  static  or  dynamic binding.  This only has
>>>> effect if specified during the link phase.  The default is dynamic binding.
>>>>
>>>> but maybe the Open MPI system doesn't know NAG?
>>>>
>>>> So I say to myself, okay, dynamiclib is a shared library sounding
>>>> thing, so let's try static library build! So, following the documentation I
>>>> try:
>>>>
>>>> ../configure --enable-static -disable-shared FCFLAGS"=-mismatch_all
>>>> -fpp" CC=gcc CXX=g++ FC=nagfor
>>>> --prefix=$HOME/installed/Compiler/nag-7.0_7062/openmpi/4.1.1-static |& tee
>>>> configure.log
>>>>
>>>> and it builds! Yay! And then I try to build helloworld.c and it fails!
>>>> To wit:
>>>> ❯ cat helloworld.c
>>>> /*The Parallel Hello World Program*/
>>>> #include <stdio.h>
>>>> #include <mpi.h>
>>>>
>>>> int main(int argc, char **argv)
>>>> {
>>>>    int node;
>>>>
>>>>    MPI_Init(&argc,&argv);
>>>>    MPI_Comm_rank(MPI_COMM_WORLD, &node);
>>>>
>>>>    printf("Hello World from Node %d\n",node);
>>>>
>>>>    MPI_Finalize();
>>>> }
>>>> ❯
>>>> /Users/mathomp4/installed/Compiler/nag-7.0_7062/openmpi/4.1.1-static/bin/mpicc
>>>> helloworld.c
>>>> Undefined symbols for architecture x86_64:
>>>>   "_MPIR_Breakpoint", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_attach_fifo", referenced from:
>>>>       _orte_submit_finalize in libopen-rte.a(orted_submit.o)
>>>>       _orte_submit_job in libopen-rte.a(orted_submit.o)
>>>>       _open_fifo in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_being_debugged", referenced from:
>>>>       _ompi_rte_wait_for_debugger in libmpi.a(rte_orte_module.o)
>>>>       _orte_submit_job in libopen-rte.a(orted_submit.o)
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>       _attach_debugger in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_debug_state", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_executable_path", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>       _setup_debugger_job in libopen-rte.a(orted_submit.o)
>>>>       _run_debugger in libopen-rte.a(orted_submit.o)
>>>>       _attach_debugger in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_forward_output", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>       _setup_debugger_job in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_i_am_starter", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_partial_attach_ok", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_proctable", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_proctable_size", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>   "_MPIR_server_arguments", referenced from:
>>>>       _orte_debugger_init_after_spawn in libopen-rte.a(orted_submit.o)
>>>>       _setup_debugger_job in libopen-rte.a(orted_submit.o)
>>>>       _run_debugger in libopen-rte.a(orted_submit.o)
>>>> ld: symbol(s) not found for architecture x86_64
>>>> clang: error: linker command failed with exit code 1 (use -v to see
>>>> invocation)
>>>>
>>>> So...yeah. ¯\_(ツ)_/¯ Maybe this needs -Bstatic??
>>>>
>>>> But again, all this worked with shared a few months ago (I've never
>>>> tried static until now) and NAG has *never* supported -dynamiclib as far as
>>>> I know.
>>>>
>>>> I do see references to -Bstatic and -Bdynamic in the source code, but
>>>> apparently I'm not triggering the configure step to use them?
>>>>
>>>> Anyone else out there encounter this?
>>>>
>>>> NOTE: I did try doing an Intel Fortran + Clang shared build today and
>>>> that seemed to work. I think that's because Intel Fortran recognizes
>>>> -dynamiclib so it can get past that FCLD step.
>>>> --
>>>> Matt Thompson
>>>>    “The fact is, this is about us identifying what we do best and
>>>>    finding more ways of doing less of it better” -- Director of Better
>>>> Anna Rampton
>>>>
>>>
>>
>> --
>> Matt Thompson
>>    “The fact is, this is about us identifying what we do best and
>>    finding more ways of doing less of it better” -- Director of Better
>> Anna Rampton
>>
>
>
> --
> Matt Thompson
>    “The fact is, this is about us identifying what we do best and
>    finding more ways of doing less of it better” -- Director of Better
> Anna Rampton
>


-- 
Matt Thompson
   “The fact is, this is about us identifying what we do best and
   finding more ways of doing less of it better” -- Director of Better Anna
Rampton

Reply via email to