Re: internal compiler error for lapack 3.4.2 build

[Loris Bennett]

Hi Yasha,

Yasha Karant  writes:

> I am attempting to build VASP 5.3.3 for a X86-64 SL6, with Nvidia GPUs
> and Nvida CUDA 6, compute engine.
>
> VASP requires lapack 3.4.2
>
> As I was building lapack,
>
> the following failure was reported:
>
> gfortran -O2 -c stbt05.f -o stbt05.o
> stbt05.f: In function ‘stbt05’:
> stbt05.f:189: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[2]: *** [stbt05.o] Error 1
> make[2]: Leaving directory `/dt0/vasp/lapack-3.4.2/TESTING/LIN'
> make[1]: *** [xlintsts] Error 2
> make[1]: Leaving directory `/dt0/vasp/lapack-3.4.2/TESTING'
> make: *** [lapack_testing] Error 2
>
> full output of all relevant make commands available if needed. Up to this
> failure,
> everything seems normal in the make output.
>
> Has anyone seen this error, and if so, what is the workaround?
>
> Is there an installable RPM of this package available so that I do not
> have to build from source?
>
> We have the appropriate VASP license -- does anyone have a set of
> makefiles (or binaries, currently CUDA 6) for the environment we need?
>
> Any information would be appreciated.
>
> Yasha Karant
>

With a similar setup but without GPU support and using Intel's MKL, a
colleague of mine has successfully compiled VASP 5.3.3.  Perhaps you
should try a different LAPACK implementation.

Cheers,

Loris

-- 
This signature is currently under construction.

Re: Finding the files in a package

[Loris Bennett]

Bruno Pereira 
writes:

> Please notice that apt-file is not installed by default on a clean Debian
> system.
>
> dpkg -S foo_file will give you the necessary package name without installing
> further software.

Yes, but only for installed packages, whereas apt-file will search in
all packages in the configured sources.

Regards

Loris

> Regards
>
>
> On Wed, Oct 2, 2013 at 3:13 PM, Loris Bennett 
> wrote:
>
> Francesco Minafra
>  writes:
> 
> > Hi Loris,
> >  you can use the command:
> >
> > yum provides */libmpi_cxx.so.1
> >
> > Cheers,
> > Francesco.
> >
> >
> > On Wed, Oct 2, 2013 at 1:01 PM, Loris Bennett
> 
> > wrote:
> >
> >     Dear List,
> >
> >     I would like to know which version of the package "openmpi" contains
> the
> >     library "libmpi_cxx.so.1".
> >
> >     On the Debian website, the information about individual packages
> >     includes a link to a file list for each available architecture.
> >
> >     How would I go about finding this information for SL?
> >
> >     Cheers,
> >
> >     Loris
> >
> >     --
> >     This signature is currently under construction.
> >
> >
> 
> Thanks Francesco (small world ;-)) and Bluejay,
> 
> It seems that "provides" and "whatprovides" are synonyms.
> 
> BTW, instead of messing about on the website, on Debian
> 
> apt-file search libmpi_cxx.so
> 
> is possible.
> 
> Cheers,
> 
> Loris
> 
> --
> This signature is currently under construction.
> 
>

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de

Re: Finding the files in a package

[Loris Bennett]

Francesco Minafra
 writes:

> Hi Loris,
>  you can use the command:
>
> yum provides */libmpi_cxx.so.1
>
> Cheers,
> Francesco.
>
>
> On Wed, Oct 2, 2013 at 1:01 PM, Loris Bennett 
> wrote:
>
> Dear List,
> 
> I would like to know which version of the package "openmpi" contains the
> library "libmpi_cxx.so.1".
> 
> On the Debian website, the information about individual packages
> includes a link to a file list for each available architecture.
> 
> How would I go about finding this information for SL?
> 
> Cheers,
> 
> Loris
> 
> --
> This signature is currently under construction.
> 
>

Thanks Francesco (small world ;-)) and Bluejay,

It seems that "provides" and "whatprovides" are synonyms.

BTW, instead of messing about on the website, on Debian

apt-file search libmpi_cxx.so

is possible.

Cheers,

Loris

-- 
This signature is currently under construction.

Finding the files in a package

[Loris Bennett]

Dear List,

I would like to know which version of the package "openmpi" contains the
library "libmpi_cxx.so.1".

On the Debian website, the information about individual packages
includes a link to a file list for each available architecture.

How would I go about finding this information for SL?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: rpm repository and distribution concordance

[Loris Bennett]

Yasha Karant  writes:

> I have appended to what is hopefully a new topic (lest I dare modify an 
> existing
> topic and thus contaminate proper list thread indexing) the reason for this 
> post
> -- that is hence a top post (new topic).
>
> We too have found similar issues when we leave SL6x and obtain compiled RPMs
> (binaries) from other repositories, usually requiring the enablement of that
> repository in the list of repositories from which to seek the dependency RPMs.
> I am not asking for a strict resolution of this issue from the SL providers.
>
> Rather, is there a way to get a list of conflicts between repositories? Is 
> there
> a way to do an accurate "dry run" so that one can discover dynamically (at the
> time when one is contemplating the installation of a RPM) of the conflicts?  
> Is
> there a way to automatically select the precedence of repositories?
>
> To be clear, here is my meaning of "precedence".  Each repository can be
> regarded as a set (possibly ordered), with overlaps by package content
> functionality although not necessarily identical revision level of said
> functionalities; e.g., library x.rev(n) versus x.rev(m), m .ne. n. One might
> want a precedence resolution rule.  To be concrete, suppose there are three
> repositories, SL 6x, A, and B.  The rule might be:  use RPMs from SL 6x; if 
> the
> functionality exists in A and B but not SL 6x, use A and replace all SL6x
> dependencies with A; otherwise, use whichever RPMs from SL6x, A, or B, that
> support the maximum number of other requested packages and, in the event of a
> multimodal distribution (ties in the integer maxima),  pick SL6x first, next 
> A,
> and lastly B (thus, in the event of such ties, B would never be chosen).   The
> above would be deterministic.  If the resulting system does not in fact 
> support
> full functionality (use of B "breaks" more important functionalities supplied
> by, say, SL6x), modify the rules, automatically remove the offending RPMs from
> the system that were provided by, say, B, and re-update.
>
> If using the order of precedence methodology above seems too automatic for 
> some,
> then again -- a means to determine dependency conflicts and do a manual
> evaluation before committing.
>
> Yasha Karant

You might like to have a look at the priorities plugin for yum, which is
available as yum-plugin-priorities from the EPEL repo.

Cheers,

Loris

-- 
no sig is good sig