And here is the good configure on Cori, On Fri, Jul 8, 2016 at 8:23 AM, Mark Adams <[email protected]> wrote:
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 <[email protected]> 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 <[email protected]> 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 <[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