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 > > >> > > > > > >> > > > >> > > >> > > > > > >
