This is a Linux question.

We have built an application which uses OpenGL and it runs just fine.
However when it starts we get the error message

/usr/lib/libGL.so.1: no version information available (required by <our program>)

The shared library is there on the system, albeit as a symbolic link
to a file of the same name in /usr/X11R6/lib; the application runs OK
and the OpenGL graphics work just fine.

However it is occasionally run in batch and we trap errors sent to
<stderr> and terminate immediately if any are found, so this is
causing a problem.

The system is the top node of a 32 node cluster, running RedHat 7.3 (Valhalla).

I have tried rebuilding the runtime loader's cache using "/sbin/ldconfig".

I have tried removing the link in /usr/lib, and rebuilding the loader
cache, but I get the same message when it accesses the file in
/usr/X11R6/lib directly.

So I'm a bit stumped.  Here is the question:

What does the message "no version information available" mean in this
context? (And no brownie points for telling me that it means no
information about versions is available!)

Supplementary question: what do I do to get rid of the message?

Possible clues: an earlier version of the software using the same
libraries does not produce this message. It was built some years ago
on - I think - PGI compilers, whereas this version was built on the
Intel 9.1 compilers.  

I've done some extensive searching on Google which reveals that this
message is quite common, but nowhere can I find what it actually
means!

---

Request for Question Clarification by maniac-ga on 28 Nov 2006 17:50 PST

Hello Christopher_bell,

I am posting this as a Request for Question Clarification because I
want to be sure you have an acceptable solution for your problem.

The cause according to
  http://www.vmware.com/community/thread.jspa?messageID=480361
appears to be a library mismatch between the system used to create the
executable program and the system you are running the program on. [see
below for a more explicit reference]

There are a few possible solutions (scroll down about 1/4 to 1/3rd of
the way down) such as
  - static linking the program
  - using "local" copies of the libraries / force the application to
use those (compatible) versions
  - defining LD_PRELOAD to force the correct versions to be used

A script that sets up the environment properly & then runs your
application may also help as well.

For the specific condition / code that causes this error message, go to
  ://www.google.com/codesearch
and enter the phrase (with double quotes)
  "no version information available"
and select the first file. You should see the error message
highlighted and scroll up a little if needed for the if statements
that cause the error to be generated.

A review of that code also suggests another option - suppress
"verbose". Unfortunately, a codesearch for
  _dl_check_all_versions
brings up calling code that unconditionally sets verbose to 1. There
would be another option to rebuild the code (with that set to 0), but
I doubt you are interested in that kind of solution.

Please provide feedback on one or more of these solutions. If
acceptable, I will produce a complete answer. If not, let me know what
additional information you need.

Good luck.

  --Maniac

---

Clarification of Question by christopher_bell-ga on 30 Nov 2006 05:38 PST

Thanks "maniac"

You've got about as far as I did, and at least you've identified the
problem in the run-time loader code.


Taking your proposed solutions in turn:

(1) Build the application on the machine on which it is running to
ensure compatibility.  (Or force it to pick up the right library by
setting an explicit path.)

Unfortunately that won't work.  Firstly our Linux cluster is reserved
for crunching, not compiling.  Granted I could sneak the compilers
onto there, but that wouldn't be a complete solution because ...

... we sell this software, and we have no control over the platforms
on which clients ultimately run it.  Therefore defining an explicit
path won't help either.

To add to my perplexity we built this on a RedHat Linux 7.3 machine,
and our cluster is running - supposedly - the same operating system.


(2) Link that library statically.

Again, a good suggestion.  However OpenGL libraries cannot be linked
statically because the actual run-time library used depends on the
graphics card installed in the machine running the application.  So a
machine with (say) an NVidia card will have a different run-time
library to one with an ATI card, and obviously we have to be
compatible with whatever card the client has installed. In fact a
static (libGL.a) library is usually not provided in the first place.

This may give a clue: the OpenGL run-time library on the machine in
question will have been installed with its graphics card (ATI Mach_64)
drivers, so any incompatibility is probably between the machine on
which ATI built their drivers and us.


(3) Turn off "verbose".

I'm not sure what you mean by this - possibly during the link phase
when building the application?



I'm reasonably certain that there is a solution since, as I said
previously, older versions of the same software don't exhibit this
problem.

I'm hoping that you will come up with something like:

- An option I can add during compiling and/or linking to suppress this
message. (Preferred, since no client intervention required)

- A way of amending the "as built" executable on a target system to
make it compatible with that system. (Not too bad: once-off operation
not requiring privileged access)

- A way of amending/adding version information in the troublesome
runtime library file. (Not great, because I'd have to explain it to
clients. they would need root privileges to do it, and any future
graphics driver update would probably re-introduce the problem; but
better than nothing.)


I hope that clarifies the question sufficiently.

(Sorry about the delayed response: I'm in the UK, and also Google
didn't notify me of your answer - probably our [deleted] corporate
firewall killed the email!)

Christopher Bell