[petsc-dev] ugliness due to missing lapack routines

Karl Rupp rupp at mcs.anl.gov
Thu Feb 7 11:55:11 CST 2013


Hi Barry,

>>    In fact Matt can also generate the appropriate zdot_() when needed so ugly crap like
>> /* handle complex dot() with special code */
>>
>> How are you going to avoid a namespace collision here? The problem isn't that the function doesn't exist, it's that we can't determine its binary interface.
>
>     Crap you are right. We'll need to come up with some other solution UNLESS the BLAS library version of them are in their separate .o files so we can pick up the generated one in libpetsc.a and it won't ever load the one in the blas library.

Since this is only BLAS-related, we should move all the BLAS-calls to a 
separate package with the sole purpose of providing a unified (binary) 
interface for the PETSc core. This will allow us to keep the PETSc core 
clean and put all the ugly stuff in that 'unification sublibrary'. This 
should eliminate any BLAS-related CPP usage from the PETSc core.

>     Sometime I will send a detailed email explaining why I wish to totally eradicate CPP.

This is a noble goal with my full support, yet very hard to achieve. How 
do we want to tackle CHKERRQ for example? I don't know of any other way 
of extracting file names and line numbers without blowing up the code 
base. If you are aiming towards compiler-driven code 
development/generation by having the full AST available, we could still 
play a few compatibility-tricks to make this work for a handful of macros.

Best regards,
Karli



More information about the petsc-dev mailing list