[petsc-dev] Configure LD flags

[Smith, Barry F.]

   I think the configure variables such as LIBS LDFLAGS never get passed directly over to the PETSc make system. For example they are not saved in PETSC_ARCH/lib/petsc/conf/petscvariables instead the PETSc make system (separate from configure) constructs needed link etc information.

   Perhaps the configure only variables should be labeled as such to be clear: CFG_..... or something

   Barry


> On Sep 16, 2019, at 9:31 AM, Balay, Satish <balay at mcs.anl.gov> wrote:
> 
> The notation here is:
> 
> LINKER ${LDFLAGS} -o foo foo.o ${PETSC_LIB} ${LIBS}
> 
> 
> The reason I needed ${LIBS} is - as I needed something at the end for passing in some system compiler libraries etc.. I could not use:
> 
> LDFLAGS='-lc -lstdc++ -lgfortran'
> 
> 
> So on this context 'LIBS=-dynamic' does not make sense. It should be 'LDFLAGS=-dynamic'
> 
> [And I don't think LDFLAGS gets used with SHARED_LINKER]
> 
> Satish
> 
> On Sun, 15 Sep 2019, Smith, Barry F. via petsc-dev wrote:
> 
>> 
>> 
>>> On Sep 15, 2019, at 4:11 AM, Stefano Zampini via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
>>> 
>>> I don't understand the separation of concerns for the configure variables LDFLAGS LIBS
>> 
>>  Nor do the rest of us. They probably need even more specialization.
>> 
>>> 
>>> Also, are LDFLAGS for the shared linker only, or for creating the final executable
>>> How one can specify flags for the shared linker that are not used for creating the dynamic executable (and viceversa)?
>> 
>>  I think we've survived with common LDFLAGS LIBS for all these years (survived, but maybe not thrived) 
>> 
>>  We might need/want to have two sets. LDFLAGS/LIBS_EXECUTABLE and LDFLAGS/LIBS_LIBRARY (better names?)
>> 
>> 
>>> 
>>> This is because, with Cray wrappers, we need to pass LDFLAGS=-dynamic at configure time.
>>> Then, when configuring HYPRE, LDFLAGS are passed and used for the shared linker, resulting in an error when creating libHYPRE.so
>>> 
>>> cc -shared -o libHYPRE.so ...a bunch of .o files.... ...libraries.... -dynamic
>>> 
>>> The -dynamic at the end makes cc think it is creating an executable,  and fail for missing main.\
>> 
>>   Here I think the short time fix is to filter the LDFLAGS before passing to the hypre package (we do lots of this filtering already for packages, but probably not as consistently as we should, it is ad hoc based on what works). If hypre simultaneously needs LDFLAGS to both contain -dynamic and not then that is either a bug in hypre's configure or we are not digging deeply into the hypre configure arguments to set the correct specialized ones.
>> 
>> 
>>> 
>>> -- 
>>> Stefano
>> 
>