Dear Kay,
Sorry, I hadn't yet had my first coffee of the day, and of course I
mixed up the two libraries. The basic message is of course the same: "If
it ain't broke, don't fix it" ;-)
Regards,
Peter.
On 09/10/2019 11:44, Kay Diederichs wrote:
Dear Peter,
-static-libgcc would statically link the compiler's library
/lib64/libgcc_s.so.1 . The version of that is 4.8.5 on my CentOS-7 machine.
Newer distros have a newer version of that, but on all Linux machines there
appears to exist such a library (because the system-provided tools also need
it) which is why it's typically not necessary to use -static-libgcc on Linux.
This library is different from what you write about, which is the system's
glibc library /lib64/libc.so.6 , the version of which is 2.17 on my CentOS-7
machine. There is no specific compiler flag like -static-libc to statically
link that. Binaries that I produce on this machine don't run on old distros
which have a lower glibc version, e.g. 2.12 in case of CentOS-6.
I use a CentOS-6 virtual machine to produce binaries for others, Wolfgang Kabsch a SuSe
distro of similar "age".
Best,
Kay
On Wed, 9 Oct 2019 10:08:39 +0100, Peter Keller <pkel...@globalphasing.com>
wrote:
Dear Kay, all,
On 09/10/2019 09:19, Kay Diederichs wrote:
Dear George,
I don't see a need for static binaries.
We link the XDS package dynamically with
ifort -static-intel -qopenmp-link=static
on a rather old system, and this seems to work for all XDS users.
Indeed:
% ldd xds_par
linux-vdso.so.1 (0x00007fffcbfc6000)
libm.so.6 => /lib64/libm.so.6 (0x00007f17a142a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f17a120c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f17a1008000)
libc.so.6 => /lib64/libc.so.6 (0x00007f17a0c4e000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f17a0a36000)
/lib64/ld-linux-x86-64.so.2 (0x00007f17a1762000)
One could add -static-libgcc but apparently this is not necessary.
In your case it might be harmful to do this. If the version of libgcc
provided by your system is older than 2.15 (very likely), you might hit
exactly the same problem with Debian 10 as we are now discussing. I'm
not 100% sure of this because your executables are not static, but if I
were you I would keep things as they are.
Regards,
Peter.
best wishes,
Kay
On Tue, 8 Oct 2019 12:21:07 +0200, George Sheldrick <gshe...@uni-goettingen.de>
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
--
Prof. George M. Sheldrick FRS
Dept. Structural Chemistry
University of Goettingen
Tammannstr. 4
D37077 Goettingen
Germany
Tel: +49 551 3933021 or +49 5594 227312
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
--
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
--
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
