This is not a Fortran programming question, but using gfortran to
build a 100% statically linked app on Linux. I thought someone
here might know.
I am trying to make 100% statically build app using gfortran
with gfortran opengl (i.e a GUI Fortran) So that anyone can
download the Linux executable and run it without needing to
have any libraries on their end. (no openGL installed, no
Fortran etc..)
I got the static link done, but unable to get rid of the following
warnings from the linker:
--------------------------
>./build_static_opengl_client.sh
/usr/lib/i386-linux-gnu/mesa/libGL.a(dlopen.o): In function `_mesa_dlopen':
(.text+0x9): warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/i386-linux-gnu/libX11.a(xim_trans.o): In function `_XimXTransSocketUNIXConnect':
(.text+0xe87): warning: Using 'getaddrinfo' in statically linked
applications requires at runtime the shared libraries from the glibc version used for linking
------------------------------------------
The above script just contain the gfortran command and all the .a
libraries needed in the correct order. I do not think it is
important to show the script. But the final command is
So, before I waste more time trying to make a fortran programs
using openGL that are 100% static linked (I spend few hrs already
to get this far), I thought to check with the experts here who might
work on linux if they can confirm this.
btw, I did test the Fortran opengl static linked small app, by copying
it to another linux system (another VM machine), and it come up
OK, GUI and all.
So, I guess that is becuase the other linux system had the
glibc there. But since all Linux systems will have glibc.so
(it will be strange to have Linux without glibc?) do I need to
really worry about this warning?
It is really bad that one can't make 100% pure static linked
app on Linux if it is true. I assume on windows this is not
the case? I need to look more into this. I want to try gfortran on
windows also (may be using cygwin) and see if I can do the same on windows
and get 100% static linked there).
> This is not a Fortran programming question, but using gfortran to
> build a 100% statically linked app on Linux. I thought someone
> here might know.
> I am trying to make 100% statically build app using gfortran
> with gfortran opengl (i.e a GUI Fortran) So that anyone can
> download the Linux executable and run it without needing to
> have any libraries on their end. (no openGL installed, no
> Fortran etc..)
> I got the static link done, but unable to get rid of the following
> warnings from the linker:
> /usr/lib/i386-linux-gnu/mesa/libGL.a(dlopen.o): In function `_mesa_dlopen':
> (.text+0x9): warning: Using 'dlopen' in statically linked applications
> requires at runtime the shared libraries from the glibc version used for linking
> /usr/lib/i386-linux-gnu/libX11.a(xim_trans.o): In function `_XimXTransSocketUNIXConnect':
> (.text+0xe87): warning: Using 'getaddrinfo' in statically linked
> applications requires at runtime the shared libraries from the glibc version used for linking
> ------------------------------------------
> The above script just contain the gfortran command and all the .a
> libraries needed in the correct order. I do not think it is
> important to show the script. But the final command is
> But can show the full script if needed. In the above MODULE and LIBS
> are just a list of all the .o and .a files needed in the correct order.
> I googled around, and it seems this is a known issue, and that it
> is NOT possible to actually make a 100% statically link program on
> linux? example:
> So, before I waste more time trying to make a fortran programs
> using openGL that are 100% static linked (I spend few hrs already
> to get this far), I thought to check with the experts here who might
> work on linux if they can confirm this.
> btw, I did test the Fortran opengl static linked small app, by copying
> it to another linux system (another VM machine), and it come up
> OK, GUI and all.
> So, I guess that is becuase the other linux system had the
> glibc there. But since all Linux systems will have glibc.so
> (it will be strange to have Linux without glibc?) do I need to
> really worry about this warning?
> It is really bad that one can't make 100% pure static linked
> app on Linux if it is true. I assume on windows this is not
> the case? I need to look more into this. I want to try gfortran on
> windows also (may be using cygwin) and see if I can do the same on windows
> and get 100% static linked there).
> --Nasser
Have you tried to check the dependencies of the executable you created yousing the ldd command?
ldd name_of_the_executable
it will list the eventual libraries the executable depends on.
> Have you tried to check the dependencies of the executable you created yousing the ldd command?
> ldd name_of_the_executable
> it will list the eventual libraries the executable depends on.
Sorry, I do not understand this suggestion.
It is a statically build executable? library boundaries
disappear in the image after the link step. Hence there is
no way to find what libraries were linked into the image
by looking at the image.
ldd will not work on statically linked image. I have all the
libraries linked in, that is not the issue. The issue is that
it does not seem possible to make an executable that is free
from glibc shared library dependency at run-time. I am worried
about the version number also.
fyi, these are the libraries to build openGL fortran program
on linux, obtained from the dynamic image
If you try the same command on the static image, there is an error:
>ldd simple3_static_build
/usr/bin/ldd: line 161: /lib64/ld-linux-x86-64.so.2: cannot execute binary file
not a dynamic executable
Because it is static linked. One can use nm command to find all symbols.
But you will not get a listing of what libraries were used to build the image
like with dynamic one.
I could be wrong, since I have little experience with Linux development
but this is what I know so far.
On 2012-07-24, Nasser M. Abbasi <n...@12000.org> wrote:
> I googled around, and it seems this is a known issue, and that it
> is NOT possible to actually make a 100% statically link program on
> linux? example:
You might, or might not, agree with the above, but consider that it's
written by Ulrich Drepper who used to be the glibc maintainer for many
many years, and thus glibc sort of follows that philosophy as well.
> So, I guess that is becuase the other linux system had the
> glibc there. But since all Linux systems will have glibc.so
> (it will be strange to have Linux without glibc?)
There's plenty of Linux systems that do not use glibc, but AFAIK they
tend to be targeted at embedded systems. In particular, one very
popular Linux-based embedded system, Android, does not use glibc but
rather its own libc called "Bionic".
Unlikely to matter for your present use case, though.
> do I need to
> really worry about this warning?
You can probably be quite safe in the assumption that all Linux
systems where one may want to run your program have glibc. However, I
suspect libGL can be an issue, since each graphics driver provides
it's own version of it (libGL being the thing responsible for
interpreting OpenGL function calls and sending appropriate
card-specific commands down to the hardware). For instance, on this
system here, ldd of an OpenGL-using application shows:
where as one might guess from the path, libGL.so.1 is provided by the
NVIDIA driver. Now, if I'd make a statically linked version of this
application and copy it to another system with, say, an AMD graphics
card, how is this supposed to work? In fact, my system doesn't even
have a libGL.a anywhere.
> I googled around, and it seems this is a known issue, and that it
> is NOT possible to actually make a 100% statically link program on
> linux? example:
> So, before I waste more time trying to make a fortran programs
> using openGL that are 100% static linked (I spend few hrs already
> to get this far), I thought to check with the experts here who might
> work on linux if they can confirm this.
There's a number of reasons to not use statically linked binaries anymore. In
your case you should keep in mind that /usr/lib/libGL.so is a hardware vendor
provided library that will simply fail or give abysmal performance at least if
you try to use e.g. the AMD variant on an nvidia card or vice-versa.
Since shared libraries also provide for some documentation of what requirements
a program has (at least if -Wl,-rpath was properly used), I'd always recommend
to go the dynamic route even if it seems harder to get right.
> where as one might guess from the path, libGL.so.1 is provided by the
> NVIDIA driver. Now, if I'd make a statically linked version of this
> application and copy it to another system with, say, an AMD graphics
> card, how is this supposed to work? In fact, my system doesn't even
> have a libGL.a anywhere.
I might be missing something. Why would you need libGL.a ? If I give
you a statically linked openGL app? It will come with libGL.a
in it? That is why the static build is much larger than the dynamic
build image:
----------------------
>ls -l simple3*
-rwxrwxrwx 1 me me 25274 Jul 24 01:32 simple3_dynamic_build
-rwxrwxrwx 1 me me 6602394 Jul 24 01:37 simple3_static_build
-----------------------
btw, I am using mesa implementation of openGL. I understand that graphics
drivers now come build-in with their own openGL implementation (DRI,
or direct rendering). So I think what will happen is that openGL calls
(linked in) will just do a 'pass through' to DRI if it is on
the system somehow. of if hardware accerlation is enabled, not sure,
not my area, but it should work.
But the point is, you would not need to have any openGL stuff on
your system to run the fortran openGL image on your linux system if
is statically linked (other than needing libgc). That is the whole
point.
I am making 3 small fortran/openGL apps now, and they are all
statically linked. I'll post them at my web page and post a link
for others to try running them. I'd like to find if they will run
on other linux systems. I am trying them on other linux's using
VM and also using another PC with linux on it, so far, no problem.
They run ok. They are all made with 100% pure Fortran :) with the
2003 openGL binding. Build with gfortran.
Should be done with them very soon. Just making some documenation
and testing. They are VERY simple openGL apps. I am newbie in this.
> It is really bad that one can't make 100% pure static linked
> app on Linux if it is true. I assume on windows this is not
> the case? I need to look more into this. I want to try gfortran on
> windows also (may be using cygwin) and see if I can do the same on windows
> and get 100% static linked there).
In Windows everything is dynamically linked via *.dll files. It
has already been pointed out that it would make no sense to
statically link to any vendor's OpenGL code. You can test some
of these dynamically linked OpenGL program on Windows for yourself.
Just download them from my website
http://home.comcast.net/~kmbtib/Fortran_stuff/example2.zip http://home.comcast.net/~kmbtib/Fortran_stuff/example3.zip http://home.comcast.net/~kmbtib/Fortran_stuff/gridview.zip http://home.comcast.net/~kmbtib/Fortran_stuff/avl.zip The above should just run on any Windows system. This one:
http://home.comcast.net/~kmbtib/Fortran_stuff/glut_test.zip uses GLUT so it needs the (included) freeglut64.dll files to
run. Put the examples on a thumb drive and take them to a
store that sells (hopefully 64-bit) Windows computers and
usually the clerk is OK with your running test programs on
their computers. I have not found a computer where they did
not work, except the 64-bit executables obviously don't run
on 32-bit versions of Windows. Also I have been converting
some of the NeHe tutorial codes to gfortran and if there is
any interest I could put these on my website.
-- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
> This is not a Fortran programming question, but using gfortran to
> build a 100% statically linked app on Linux. I thought someone
> here might know.
> Nasser M. Abbasi <n...@12000.org> wrote:
>> This is not a Fortran programming question, but using gfortran to
>> build a 100% statically linked app on Linux. I thought someone
>> here might know.
Thanks. Looked at it. very interesting. In a way, it it similar
of building a 100% static image for compiled applications. For
none compiled apps, like python and such, the whole env. needs to
be copied over, which is what CDE seems to be doing.
Actually this idea is not new. When I build Java app, I put
the JRE and all other needed files in the JAR file, all in one
folder, including a startup script that points the classpath to
the JAR file and the included JRE, So the application is all self
contained in one folder (it has it own Java run-time, and the
startup script will only point a new classpath to things in this folder).
Oracle is now working on native Java installer (now it is for
JavaFX only, but I understand in future version of the JDK will
be part of standard JDK)
"A Wrapper for your JavaFX application that makes it into a
platform-specific application bundle Each Bundle is self-contained"
I seem to read somewhere that on mac, applications install on
their own folders including all needed libraries and resources
as one self contained bundle/folder. I do not use the mac, so I do
not more about it.
Linux packaging and libraries are a big mess if you ask me. Even
within 2 distributions, I see things in different places, .so's in
different places, ldconfig mess, alternatives path, so's with different
versions, missing header files or in different places. I open the
package manager on linux, and see 30 listing of the same package with
slightly different descriptions and versions, and I have no idea which
one to click on.
That is why static building is the better solution. I do not understand
those who say it is better to dynamic link. Ok, I dynamic link something,
send it to someone and then they spend a week trying to update their
packages and libraries to match what I have on my box. Is this
supposed to be better?
I hope this CDE becomes a success, something like it is needed for Linux.
