LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 10-26-2009, 12:13 PM   #1
threepointonefour
LQ Newbie
 
Registered: Oct 2009
Posts: 22

Rep: Reputation: 15
Strange linking errors, libstdc++ versions, libs not found?


My apologies if this post runs too verbose... but if there's one thing I
hate, it's when people ask for help, post a vague error message, and scamper off. I've tried to post as much as I can without going overboard, as well as detailing what I know that I don't know, so...

Alright, let me be straight up honest from the get go about a few
important things:

1. I'm absolutely HORRIBLE with make files. HORRIBLE. I've been spoiled
by years of Visual Studio / Netbeans / Codeblocks / foo-ide programming.
So forgive whatever idiocy I convey in that category.

2. I didn't write the program I'm trying to build (although I know most
of it, have been working on it for a while, OpenGL over C++ mostly) or the
makefile (reference 1).

3. I'm not GREAT with Linux yet. I love it from what I've done seen of
it thus far, but I've still got a long ways to go.

Okay. So onto the bizarre story of the program which currently exists in
two versions.. old version and new version, both of which have a major
linking problem...

OLD VERSION LINKING PROBLEM

Had a working version of the program. Worked fine. Built a new version
of the app in a completely separate directory of the HD to work on some
new features. Had issues getting that new app to build (that's part two
below... ). Anyway, came back to run old version of the app and it won't
run. The error message and ldd say it's trying to link against
libstdc++.so.5, when version 6 is the only one on the drive, and
previously the program... well, ran fine. No rebuilds, no updates (the
machine is on a server which isn't connected to the internet to be able to
pull updates), nothing. I'd been working on that new version of the
program on a separate location on the drive, that's the ONLY thing I can
think of that had been going on between when it worked and when it
didn't.. but I can't imagine how it would have changed which library it
linked against.

I have a copy of the program on three other machines, they all show ldd as
linking against libstdc++.so.6 as well. I'm horribly confused and
frustrated. I hadn't ever run ldd on it before, so I don't know what it
pointed to in the past, but it currently wants libstdc++.so.5 and I have
ZERO idea why.

NEW VERSION LINKING PROBLEM

I can't get the $*#%@ thing to build properly. libGl.so is included in
the makefile via -lGL, when it gets to that phase, I start getting the
following errors:

warning: libGLcore.so.1, needed by /usr/lib64/libGL.so, not found (try
using -rpath or -rpath-link)
warning: libnvidia-tls.so.1, needed by /usr/lib64/libGL.so, not found
(try using -rpath or -rpath-link)
warning: every frigging library on your hard drive, needed by
/usr/lib64/libGL.so, not found (try using -rpath or -rpath-link)

I've checked, double checked, quintuple checked, and checked some more,
and every library that it says it can't find reside in /usr/lib64/. I've
tried adding /usr/lib64 to my ld.so.conf, ran ldconfig, tried adding
-L/usr/lib64 to the makefile. Tried asking nicely and threatening
menacingly. Nothing going. Why in the world can't it find these
libraries, particularly if it can find /usr/lib64/libGL.sl?

-------

Any advice at this point is welcome... other than remaking the old one
until I can prove I can make the new one, because as badly as that's
going, I'm too paranoid to even TRY to make the old one again...


---------------------------------------------------------------------------
 
Old 10-26-2009, 12:34 PM   #2
paulsm4
LQ Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Hi -

The problem appears to be that your "libGL.so" needs a bunch of other stuff, and it's the "other stuff" your linker can't find.

SUGGESTION:
1. Tell us what Linux distro and what version of Gnu C++ you're using.

2. As it happens, both "libnvidia-tls.so.1" and "libGLcore.so.1" are part of the NVidia X windows GLX driver:

http://www.rpmfind.net/linux/rpm2htm...%29%2864bit%29

Q: Is your video card actually NVidia?

3. Please cut/paste specific error messages when you post back
 
Old 10-29-2009, 01:38 PM   #3
threepointonefour
LQ Newbie
 
Registered: Oct 2009
Posts: 22

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by paulsm4 View Post
Hi -

The problem appears to be that your "libGL.so" needs a bunch of other stuff, and it's the "other stuff" your linker can't find.

SUGGESTION:
1. Tell us what Linux distro and what version of Gnu C++ you're using.

2. As it happens, both "libnvidia-tls.so.1" and "libGLcore.so.1" are part of the NVidia X windows GLX driver:

http://www.rpmfind.net/linux/rpm2htm...%29%2864bit%29

Q: Is your video card actually NVidia?

3. Please cut/paste specific error messages when you post back
----------------------------------------------------------

Sorry for the slow response. Been a very busy week working on other projects. The libGL issue.. that's half the problem, the other half being the libstdc++.so.5 / .6 problems. Here's as much specifics as I can get together:

1. Fedora Core 5. The code's being compiled by a g++ command in the makefile, g++ --version returns "g++ (GCC) 3.3.3". I've just realized that any of the machines which end up linking against the wrong stdc++ version are running version 4.1.1. I hadn't considered checking this before but is this probably the issue? (And potentially why the linker has trouble finding libGL's dependencies even though they're residing in the same folder as libGL?

2. Yes. Quadro FX 4500.

3. I don't know how much more specific I can come up with than I did in my first post, I cut a lot out for the sake of brevity because it was just a lot of repetition.

3a. The first problem is one project compiles and builds, works fine on two machines, fails on two others with the following error:

"error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory."

Checking the /lib, /lib64, /usr/lib, and /usr/lib64 directories, I've verified that libstdc++.so.6 is the only one available on all four machines... is this being caused by what I noticed above, the different compiler versions on different machines? It seems consistent. v3.3.3 on the ones that don't work, v4.1.1 on the ones that do.

3b. The second problem is the libGL / libGLEW problem, where it isn't finding libGL's / libGLEW's dependency libraries. I've verified that all the libs are there in /usr/lib64, in the same directory as libGL. Is this probably a version issue as well? I wouldn't think it just being an older compiler version would prevent it from being able to locate / link libraries but... I don't know.

The errors that get generated at this stage are:
warning:

"libXmu.so.6, needed by /usr/lib64/libGLEW.so, not found (try using -rpath or -rpath-link"

[Says the same thing for libXi.so.6, libGLU.so.1, libXext.so.6, libX11.so.6]

"libGLcore.so.1, needed by /usr/lib64/libGL.so, not found (try using -rpath or -rpath-link"

"libnvidia-tls.so.1, needed by /usr/lib64/libGL.so, not found (try using -rpath or -rpath-link"

-----------

Thanks in advance for your help. I'm starting to think I just need to get the compiler version on the other machines to version 4.1.1 as well, do you think?
 
Old 10-30-2009, 11:36 AM   #4
threepointonefour
LQ Newbie
 
Registered: Oct 2009
Posts: 22

Original Poster
Rep: Reputation: 15
Minor update, I was looking at updating GCC, but I've noticed ld are different versions as well.
On the machines where everything goes smoothly, ld is v. 2.15.90.0.1.1
On the machines where there are problems in the linking / execution, ld is v. 2.16.91.0.6

This seems like a small version change but given the crash occurs in the ld stage of the build of the program, and the one that's already built fails because it's linked against a non-existent library, should I maybe try to update ld on the machines where it isn't working?

I was looking at updating GCC on the other two machines, but that looks... intensive and dangerous and I'm paranoid about potentially blowing up everything. Hahaha.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
dynamically linking libstdc++ in mingw entz Programming 2 11-17-2007 03:16 AM
linking with a previous version of libstdc++ jjstokes Programming 1 06-28-2006 11:08 AM
Problems with libstdc versions 5 and 6 mainemike Linux - Software 1 05-03-2006 08:42 AM
implication of statically linking to libstdc++ zero79 Linux - General 3 04-08-2006 01:03 PM
mismatched rpm versions of libstdc++ and libstdc++-devel pcweirdo Linux - Software 8 11-29-2004 09:30 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 03:57 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration