1 (edited by JohnWasilewski 2016-08-09 14:11:32)

Topic: SF/Linux static linking difficulty

With:
  Linux Mint 18
  64-bit
  SF 2.9

I have a large program, which compiles and links, apparently successfully.

It I try

DYNAMIC LINKING

(1) linking with Options > Project > Linker :
     [ ]  All static
     [ ]  Static Fortran runtime
     [ ]  Static C runtime
     [ ]  Static C++ runtime

  [x] Build import library

or

(2) linking with Options > Project > Linker :
     [ ]  All static
     [x]  Static Fortran runtime
     [ ]  Static C runtime
     [ ]  Static C++ runtime

  [ ] Build import library

..then linking succeeds both times, but I can't run the executable.  The console reports an error when loading shared object files, specificaly that it can't find libdislin.so.10.     
I believe I can fix this by using ldconfig to add shared library libdislin.so.10 to the cached list of shared object files.
This is not what I'm asking about.

STATIC LINKING

(3) linking with Options > Project > Linker :
     [x]  All static
     [ ]  Static Fortran runtime
     [ ]  Static C runtime
     [ ]  Static C++ runtime

  [ ] Build import library

..then linking fails, giving a three warnings about statically linked applications requiring at runtime the shared libraries from the glibc version used for linking, plus a large number of errors due to undefined references.

I have searched briefly for information about this.  Here is some of what I've found:

- glibc uses libnss to support a number of different providers for address
   resolution services. Unfortunately, you cannot statically link libnss, as exactly
   what providers it loads depends on the local system's configuration

- there is a solution: you can use musl library to replace glibc. To use musl,
   you can either install it and build your software using musl-gcc, or you can
   use a Linux distribution that uses musl, e.g. Alpine Linux.c
.

- a lot of stuff about hoiw to solve static linking, which I did not understand.

Any suggestions, anyone?
---
John

Re: SF/Linux static linking difficulty

John,

Can you post the actual error? 

Static linking as an option should probably be off by default on the Linux version.  Most Linux distributions don't even provide the static libraries for the Fortran and C runtime libraries by default.  I have no idea what Linux Mint provides.

I would strongly recommend disabling static linking on Linux for your projects.  There is very little reason to use it on those systems.  It becomes necessary on Windows because the paths to the compiler runtime shared libraries are problematic.

Jeff Armstrong
Approximatrix, LLC

Re: SF/Linux static linking difficulty

Since you replied, Jeff, I've added a bit more to my original post, if you'd care to re-read it.
My aim is to provide a standalone executable, becauseI think it rather inelegant to have to supply various .so libraries plus instructions on where to put them, and how to edit system files before running ldconfig, to add them to the cache.
Is this really what one has to do with Linux?  Is it really impractical to create statically-linked standalone executables?
---
John

4 (edited by JohnWasilewski 2016-08-06 15:32:16)

Re: SF/Linux static linking difficulty

Here are just a few of the many screenfuls of errors when I try STATIC linking:


Generating Instruct64
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(Xmos.o): In function `XmeGetHomeDirName':
(.text+0xb0e): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(Xmos.o): In function `XmeGetHomeDirName':
(.text+0xb59): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(xim_trans.o): In function `_XimXTransSocketINETConnect':
(.text+0xf07): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(Label.o): In function `Redisplay':
(.text+0xef8): undefined reference to `XftDrawSetClip'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(LabelG.o): In function `_XmRedisplayLabG':
(.text+0x3543): undefined reference to `XftDrawSetClip'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(XmString.o): In function `ComputeMetrics':
:
:
:
(.text+0xc1af): undefined reference to `XftTextExtents16'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(XmString.o): In function `SubStringPosition':
(.text+0xc243): undefined reference to `XftTextExtents16'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(XmString.o): In function `_render':
(.text+0xe2c5): undefined reference to `XftDrawSetClip'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(TextF.o): In function `FindPixelLength.part.6':
(.text+0x1dbe): undefined reference to `XftTextExtentsUtf8'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(TextF.o): In function `FindPixelLength.part.6':
(.text+0x1f15): undefined reference to `XftTextExtentsUtf8'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(TextF.o): In function `FindPixelLength.part.6':
(.text+0x1fa5): undefined reference to `XftTextExtentsUtf8'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(TextF.o): In function `PrintableString':
:
:
:
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(EditresCom.o): In function `DoGetGeometry':
(.text+0x1fbf): undefined reference to `_XEditResPutString8'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(EditresCom.o): In function `DoGetGeometry':
(.text+0x1fe9): undefined reference to `_XEditResPutWidgetInfo'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(EditresCom.o): In function `DoSetValues':
(.text+0x2126): undefined reference to `_XEditResPut16'
:
:
:
(.text+0x22f6): undefined reference to `_XEditResResetStream'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(EditresCom.o): In function `_XmEditResCheckMessages':
(.text+0x2305): undefined reference to `_XEditResPut8'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(Jpeg.o): In function `load_jpeg':
(.text+0x6c): undefined reference to `jpeg_std_error'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXm.a(Jpeg.o): In function `load_jpeg':
:
:
:
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXt.a(Threads.o): In function `AppUnlock':
(.text+0x2fd): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXt.a(Threads.o): In function `AppUnlock':
(.text+0x313): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXt.a(Threads.o): In function `AppLock':
(.text+0x371): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXt.a(Threads.o): In function `ProcessUnlock':
(.text+0x3c1): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXt.a(Threads.o):(.text+0x3d6): more undefined references to `pthread_mutex_unlock' follow
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(ClDisplay.o): In function `XCloseDisplay':
(.text+0xd3): undefined reference to `xcb_disconnect'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o): In function `open_library':
(.text+0x32): undefined reference to `dlopen'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o): In function `fetch_symbol':
(.text+0x61): undefined reference to `dlsym'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o): In function `fetch_symbol':
(.text+0x85): undefined reference to `dlsym'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(OpenDis.o): In function `OutOfMemory':
(.text+0x444): undefined reference to `xcb_disconnect'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(OpenDis.o): In function `XOpenDisplay':
(.text+0x87c): undefined reference to `xcb_get_setup'
:
:
:
/usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.a(unit.o): In function `close_unit_1':
(.text.close_unit_1+0x11a): undefined reference to `pthread_mutex_destroy'
/usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.a(unit.o): In function `_gfortrani_close_units':
:
:
:
(.text._gfortrani_find_file+0x8a): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.a(unix.o): In function `_gfortrani_find_file':
(.text._gfortrani_find_file+0x92): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.a(unix.o): In function `_gfortrani_find_file':
:
:
:
/usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.a(random.o): In function `_gfortrani_random_seed_i8':
(.text._gfortrani_random_seed_i8+0x132): undefined reference to `pthread_mutex_unlock'
:
:
:
/usr/lib/gcc/x86_64-linux-gnu/5/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `_Unwind_Find_FDE':
(.text+0x19c6): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-linux-gnu/5/libgcc_eh.a(unwind-dw2-fde-dip.o): In function `_Unwind_Find_FDE':

Re: SF/Linux static linking difficulty

John,

OpenSUSE actually allows and provides explicitly static versions of the glibc libraries for static linking, and Simply Fortran requires them by default.  Other platforms are quite a bit more vague, but it seems to work on Debian and Ubuntu.  Again, I don't know the specifics of Linux Mint's libraries and configurations.  I would strongly suggest, though, that you just not use static linking.  It appears that Linux Mint is not supplying many statically link-able libraries at all.

The musl libc is designed with static linking in mind, but it certainly will not fix the errors you're seeing above.  It provides all the normal C runtime library functions.  However, you'd have to recompile the Fortran runtime libraries to make use of musl.  It would not be pleasant. 

I would symbolically link dislin's runtime libraries somewhere sensible, like /usr/lib or /usr/local/lib, and simply stick to dynamic linking.  If you do eventually want a statically linked version, you'll have to compile it on something that supports all the underlying libraries in static form, such as Debian, Ubuntu, or OpenSUSE.

Jeff Armstrong
Approximatrix, LLC

6 (edited by JohnWasilewski 2016-08-09 14:23:43)

Re: SF/Linux static linking difficulty

That is very interesting, Jeff, thank you.

Pretty disappointing about Linux Mint, though, because it means I've backed the wrong horse, and should have put my money on (or rather. all the time I have spent in installing and sculpting, into)
Open SUSE, instead of Linux Mint.

Oh well. at some point when I have many hours to waste, I can start again with the OS, 'OS'.
Until then, I'll take your advice and just build dynamically linked projects.

In case anyone needs help in how to do that:

Add the following line to the end of the text file, /etc/ld.so.conf file:
     /usr/local/dislin
    (don't add "include /usr/local/dislin")
Rebuild the shared object files cache:
   sudo ldconfig

In SF, Options -> Project -> Linking
   un-tick 'All static'
   Then, build.

---
John

Re: SF/Linux static linking difficulty

John,

I wouldn't go so far as to say you've "backed the wrong horse" with Linux Mint.  It's a relatively popular distribution.  The issue really surrounds how each project packages their compiler and related libraries.  There's good reasons not to support static linking, but it does make moving an executable between systems problematic (Simply Fortran for GNU/Linux, for example, is quite tedious to build for all its supported configurations). Additionally, while Debian and Ubuntu do provide static versions of their C and Fortran runtime libraries, OpenSUSE requires a specific package to be installed that isn't present by default.

Jeff Armstrong
Approximatrix, LLC