<div>Yes. the LIBS way will certainly work. Thanks!</div><div>Our previous solution to this is to combine all mkl .a libraries I want to use into a single mkl.a library. Looks stupid but works fine. </div><div><br></div><div>
I'm posting the question in the devep list, because I wish to looking beyond a quick fix.</div><div>I am setting up an automatic building system in the company, and with it, we want to build many variants of Petsc and our application program for benchmarking/testing/release. That's why I become interested in the internals Petsc build system, and start thinking how it can work better.</div>
<div><br></div><div>I'll read this part of the code a bit more, and dig deeper in the past discussions in this list...</div><div><br></div><div>regards,</div><div>shenchen</div><div><div><br><div class="gmail_quote">On Mon, Apr 11, 2011 at 10:29 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Currently things specified with LIBS option remain untouched by<br>
configure..<br>
<br>
so you could try<br>
<br>
LIBS="$(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a  -Wl,--start-group \<br>
<div class="im">$(MKLROOT)/lib/intel64/libmkl_intel_lp64.a \<br>
$(MKLROOT)/lib/intel64/libmkl_sequential.a \<br>
$(MKLROOT)/lib/intel64/libmkl_core.a \<br>
$(MKLROOT)/lib/intel64/libmkl_blacs_intelmpi_lp64.a -Wl,--end-group \<br>
</div>-lpthread " --with-scalapack=1<br>
<font color="#888888"><br>
Satish<br>
</font><div><div></div><div class="h5"><br>
On Mon, 11 Apr 2011, Chen Shen wrote:<br>
<br>
> Hi all,<br>
><br>
> Currently, there is an option to specify the blas/lapack library<br>
> files --with-scalapack-lib=[<list of .a files>]. This is indeed necessary,<br>
> because MKL provides a large choice of libraries to link against.<br>
><br>
> However, MKL static libraries have object inter-dependencies, and requires<br>
> --start-group/--end-group linker options. All libraries in the group are<br>
> searched repeatedly until all inter-dependencies resolved.<br>
> For example, the following options is suggested for a configuration (<br>
> <a href="http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/" target="_blank">http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/</a>):<br>
><br>
> $(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a  -Wl,--start-group<br>
> $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a<br>
> $(MKLROOT)/lib/intel64/libmkl_sequential.a<br>
> $(MKLROOT)/lib/intel64/libmkl_core.a<br>
> $(MKLROOT)/lib/intel64/libmkl_blacs_intelmpi_lp64.a -Wl,--end-group<br>
> -lpthread<br>
><br>
> I'd like to propose an extension to the --with-scalapack-lib syntax to<br>
> support start/end group. Consider the following example:<br>
> --with-blas-lapack-lib=[ /xxx/scalapack_lp64.a,   [/xxx/libmkl_intel_lp64.a,<br>
> /xxx/libmkl_sequential.a, libmkl_core.a, /xxx/libmkl_blacs_intelmpi_lp64.a]<br>
> ]<br>
><br>
> The embedded list indicates a set of libraries to be grouped up. Would this<br>
> be possible?<br>
><br>
> This isn't a problem if we link to dynamic libraries, because -l for dynamic<br>
> libraries doesn't have to be ordered as in the case of static libraries.<br>
> I hate the wicked order rule for .a libraries, but have to live with it...<br>
><br>
> Further, I guess -Bstatic options are dropped somewhere (I haven't checked<br>
> it in detail). The final PACKAGES_LIBS macro never contains -Bstatic, so end<br>
> application will always link to the static libraries.<br>
><br>
><br>
> Regards,<br>
> Shen Chen<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>