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 <[email protected]> wrote: > whoops, that did not have p4est > > > On Fri, Jul 8, 2016 at 1:04 AM, Mark Adams <[email protected]> wrote: > >> >> >> On Fri, Jul 8, 2016 at 12:18 AM, Tobin Isaac <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> >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 <[email protected]> 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 <[email protected]> >>> >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 >>> ><[email protected]> >>> >> > >> 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 >>> >> > >> > > > >>> >> > >> > >>> >> > >> >>> >> > >> >>> >> > >>> >> > >>> >> >>> >> >>> >>> >> >
