Re: [petsc-dev] p4est configure error
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
participants (1)
-
Mark Adams