[petsc-dev] p4est configure error

[Tobin Isaac]

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