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
