There is now another alternative. There are platforms for packaging
software with necessary libraries. PyMOL for example is available using
"snap".
https://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg46623.html
On 2019-10-08 06:21, George Sheldrick wrote:
As explained in the attached email from Peter Keller, I was
deliberately preparing the binary Linux SHELX distribution using older
(2011) system libraries so that the programs would run on older
systems that many users are still using. Unfortunately this means that
they do not run on some recent cutting edge distributions including
Debian 10. This can be fixed with 'vsyscall=emulate' when installing
the OS but not all users may be allowed to do this. Dynamic binaries
would be smaller but would require the user to provide the right
libraries.
If I prepare statically linked binaries (using the latest ifort and
ubuntu) they appear to run on current systems but may have problems on
older systems. I may have to offer (e.g. in CCP4 and on the SHELX
server) two sets of Linux binaries in the future, one for 'vintage'
systems and one for current systems. Alternatively I could provide
both statically and dynamically linked versions. What do users think?
Best wishes, George
On 08.10.19 11:04, Peter Keller wrote:
HI Tim,
On Mon, 7 Oct 2019, Tim Gruene wrote:
Date: Mon, 07 Oct 2019 23:04:28 +0200
From: Tim Gruene <tim.gru...@univie.ac.at>
To: Peter Keller <pkel...@globalphasing.com>
Cc: CCP4BB@jiscmail.ac.uk
Subject: Re: [ccp4bb] Shelx and debian 10
@Peter: are you sure that without 'vsyscall=emulate' linux binaries
need to be
dynamically linked? I would be very surprised if the linux kernel would
disable statically linked binaries. I rather think that the vanilla
versions
of shelx c/d/e (from shelx.uni-goettingen.de) are compiled with an
obsolete
compiler / obsolete compiler options.
You're right, I wrote my reply to Bernhard too rapidly, and conflated
two separate issues. Debian 10 still supports static binaries of
course, but in its default configuration (without vsyscall=emulate),
those static binaries must be linked with a version of glibc that
doesn't require vsyscalls. OTOH, dynamic binaries don't suffer from
this problem, because they can use vDSO provided by the running
(rather than the build) system.
I think that part of the problem is that traditionally when we want
to build portable linux binaries, we tend to build on the oldest
distribution that we want to support, relying on backwards
compatibility to provide the portability that we are after. We often
build statically, because it is a robust way of including all the
required libraries and is less fiddly and error-prone than providing
them as dynamic libraries. There is also no danger of breakage caused
by rogue values of LD_LIBRARY_PATH (which users shouldn't be setting
of course, but we have no way of stopping them). The drawback of this
approach is that when backwards compatibility is broken, there is no
application-level fix.
These kinds of problems are rare, but when they do happen the onus is
on those of us who distribute binary applications to find solutions.
Some sysadmins may have good reasons for being reluctant to change
kernel parameters to get third-party applications to work.
Regards,
Peter.
On Monday, October 7, 2019 5:53:44 PM CEST Peter Keller wrote:
Dear Bernhard,
We had this issue drawn to our attention last year by an early adopter
of Debian 10 while it was still in testing. I thought that it was a
bug,
and submitted a report accordingly here:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889965>. I was told
that it is not a bug, but a feature ;-)
If you are able, you could try setting the kernel parameter
vsyscall=emulate. In the longer term, SHELXC/D/E will have to be
rebuilt
to support systems where the vsyscall has been disabled. This means
they
have to be dynamic executables that include the following in the
output
of 'ldd':
% ldd /bin/bash
linux-vdso.so.1 (0x00007fff50952000)
....
All current distros use vDSO, so this shouldn't cause portability
problems by itself, but handling dynamic executables can be trickier
than static ones.
For a little more background, see <https://lwn.net/Articles/446528/>
Finally, you have my commiserations: although this change has been a
long time coming, it hasn't attracted a lot of attention. It was bound
to catch users of static executables by surprise.
Regards,
Peter.
On 07/10/2019 16:05, Bernhard Rupp wrote:
Hi Fellows,
we updated to Debian 10 on the local workshop computers, and
reinstalled
Coot and ccp4. All fine.
Problem: Shelxc/d/e/ does not run, and
the call exits immediately sans any message.
This holds for the binaries included in ccp4 as well as for those
from
the SHELX site.
The executables from CCP4 and SHELX site – same file size, probably
same - run fine under Debian 9.
I suspect a library problem.
Does some kind soul have CDE binaries for Debian 10 to share?
Many thx in advance, BR
--------------------------------------------------------------------------
--------------
Bernhard Rupp
Department of Genetics and Pharmacology
Institute of Genetic Epidemiology
Medical University Innsbruck
Schöpfstrasse 41
A 6020 Innsbruck – Austria
+43 (676) 571-0536
bernhard.r...@i-med.ac.at
--------------------------------------------------------------------------
--------------
k.k. Hofkristallamt
San Diego, CA 92084
001 (925) 209-7429
b...@ruppweb.org
b...@hofkristallamt.org
http://www.ruppweb.org/
-----------------------------------------------------------------------
------------------------------------------------------------------------
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
--
=======================================================================
All Things Serve the Beam
=======================================================================
David J. Schuller
modern man in a post-modern world
MacCHESS, Cornell University
schul...@cornell.edu
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
