As I said, I need two passes to get this to work, here is the first (failed) configure on Cori.  With any luck my current configure will work and I can send that along.

Note, this used to work on Edison, so it might be something not worth, or even possible, to fix with NERSC's help.

Thanks, 

On Thu, Jul 7, 2016 at 9:12 PM, Tobin Isaac <tisaac@uchicago.edu> wrote:

I'd be happy to help some more if you send a successful log from Cori.

On July 7, 2016 7:18:30 PM CDT, Mark Adams <mfadams@lbl.gov> wrote:
>Yes, if fails on debug=0. This used to work on Edison and it does work
>now
>on Cori.
>
>On Fri, Jul 8, 2016 at 1:07 AM, Mark Adams <mfadams@lbl.gov> wrote:
>
>> whoops, that did not have p4est
>>
>>
>> On Fri, Jul 8, 2016 at 1:04 AM, Mark Adams <mfadams@lbl.gov> wrote:
>>
>>>
>>>
>>> On Fri, Jul 8, 2016 at 12:18 AM, Tobin Isaac <tisaac@uchicago.edu>
>wrote:
>>>
>>>> Interesting, you'd think that --disable-shared would be all that
>>>> matters.  Could you please send that configure.log for comparison?
>>>>
>>>> On July 7, 2016 5:14:13 PM CDT, Mark Adams <mfadams@lbl.gov> wrote:
>>>> >Well, this did not work as you suspected ... FYI, it seems to work
>>>> >with-debugging=0.
>>>> >
>>>> >On Thu, Jul 7, 2016 at 11:13 PM, Satish Balay <balay@mcs.anl.gov>
>>>> >wrote:
>>>> >
>>>> >>
>>>> >>
>>>> >> >>>>>>>
>>>> >> /bin/sh ./libtool  --tag=CC   --mode=link cc  -no-ipo -g -O0
>-o
>>>> >> libb64/sc_b64enc libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la
>>>> >-lgomp
>>>> >> libtool: link: cc -no-ipo -g -O0 -o libb64/sc_b64enc
>>>> >> libb64/libb64_sc_b64enc-b64enc.o  ./src/.libs/libsc.a
>>>> >> /opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so -lrt -ldl -Wl,-rpath
>>>> >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64 -Wl,-rpath
>>>> >> -Wl,/opt/gcc/5.2.0/snos/lib/../lib64
>>>> >> <<<<<<<
>>>> >>
>>>> >> For some reason libtool is converting "-lgomp" into
>>>> >> "/opt/gcc/5.2.0/snos/lib/../lib64/libgomp.so" - and giving an ld
>>>> >error.
>>>> >>
>>>> >> On my linux box - I see:
>>>> >> >>>>>>>
>>>> >> /bin/sh ./libtool  --tag=CC   --mode=link mpicc  -g3   -o
>>>> >libb64/sc_b64enc
>>>> >> libb64/libb64_sc_b64enc-b64enc.o ./src/libsc.la -lgomp -lpthread
>-lz
>>>> >-lm
>>>> >> libtool: link: mpicc -g3 -o libb64/sc_b64enc
>>>> >> libb64/libb64_sc_b64enc-b64enc.o  ./src/.libs/libsc.a -lgomp
>>>> >-lpthread -lz
>>>> >> -lm
>>>> >> <<<<<<
>>>> >>
>>>> >> I don't really understand libtool - or this error..
>>>> >>
>>>> >> Satish
>>>> >>
>>>> >> On Thu, 7 Jul 2016, Tobin Isaac wrote:
>>>> >>
>>>> >> > Nope, different error: p4est autotools found an openmp library
>and
>>>> >tried
>>>> >> to link it, but there's a shared/static mismatch.  I'll try to
>get to
>>>> >the
>>>> >> bottom of this.
>>>> >> >
>>>> >> >
>>>> >> > On July 7, 2016 3:27:23 PM CDT, Mark Adams <mfadams@lbl.gov>
>wrote:
>>>> >> > >I nuked and ran this twice:
>>>> >> > >
>>>> >> > >1013  rm -fr arch-xc30-dbg64-intel
>>>> >> > > 1014  ../arch-xc30-dbg64-intel.py
>>>> >> > > 1015  h
>>>> >> > > 1016  ../arch-xc30-dbg64-intel.py
>>>> >> > >
>>>> >> > >Same error.
>>>> >> > >
>>>> >> > >
>>>> >> > >On Thu, Jul 7, 2016 at 9:36 PM, Satish Balay
><balay@mcs.anl.gov>
>>>> >wrote:
>>>> >> > >
>>>> >> > >> perhaps configure was not rerun - so a stale p4est was
>being
>>>> >used..
>>>> >> > >>
>>>> >> > >> Satish
>>>> >> > >>
>>>> >> > >> On Thu, 7 Jul 2016, Tobin Isaac wrote:
>>>> >> > >>
>>>> >> > >> > p4est.py automatically pulls from whatever p4est branch I
>call
>>>> >> > >'petsc'
>>>> >> > >> > in my repo, so I don't see how this problem persists if
>you
>>>> >really
>>>> >> > >> > nuked it.
>>>> >> > >> >
>>>> >> > >> > - Did you nuke the right directory?
>>>> >> > >> > - Did you send me the right configure.log?
>>>> >> > >> > - Is the new failure the same (the same stale p4est
>commit is
>>>> >being
>>>> >> > >> >   used)?
>>>> >> > >> >
>>>> >> > >> > On Thu, Jul 07, 2016 at 08:33:57PM +0200, Mark Adams
>wrote:
>>>> >> > >> > > It sounds like I have not merged your fix.  Should I
>pull
>>>> >from
>>>> >> > >master?
>>>> >> > >> > >
>>>> >> > >> > > I have nuked this many times.
>>>> >> > >> > >
>>>> >> > >> > > On Thu, Jul 7, 2016 at 4:26 PM, Tobin Isaac
>>>> ><tisaac@uchicago.edu>
>>>> >> > >> wrote:
>>>> >> > >> > >
>>>> >> > >> > > >
>>>> >> > >> > > > On Thu, Jul 07, 2016 at 03:16:40PM +0200, Mark Adams
>>>> >wrote:
>>>> >> > >> > > > > p4est on Edison configures in w/o debugging,
>although I
>>>> >have
>>>> >> > >to run
>>>> >> > >> > > > > configure twice.
>>>> >> > >> > > > > But with debugging it fails.  I can not see any
>>>> >difference
>>>> >> > >between
>>>> >> > >> the
>>>> >> > >> > > > two
>>>> >> > >> > > > > configures other than debugging.
>>>> >> > >> > > > > Mark
>>>> >> > >> > > >
>>>> >> > >> > > > The log shows that you are configuring a p4est commit
>>>> >(3d3e1)
>>>> >> > >that is
>>>> >> > >> > > > before the one I pushed specifically to avoid the
>fortran
>>>> >> > >> > > > configuration error (f54bb3).  Please clear the
>git.p4est
>>>> >> > >directory,
>>>> >> > >> > > > and confirm that you are configuring with the current
>>>> >'petsc'
>>>> >> > >branch
>>>> >> > >> > > > of p4est (`grep 'checking Point version'
>configure.log`
>>>> >should
>>>> >> > >show
>>>> >> > >> > > > X.XXX-a9f22).
>>>> >> > >> > > >
>>>> >> > >> > > > Cheers,
>>>> >> > >> > > >   Toby
>>>> >> > >> > > >
>>>> >> > >> >
>>>> >> > >>
>>>> >> > >>
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>>
>>>>
>>>
>>