On Thu, May 26, 2005 at 03:43:17PM +0300, Boris Gorelik wrote:
>
> On Thu May 26 2005 14:44, Yedidyah Bar-David wrote:
> > You compiled stuff, using shared libs from this new gcc. You somehow
> > made the execs find those libs (e.g. LD_LIBRARY_PATH or -rpath).
> > Then you deleted it, and they can't find the shared libs.
>
> Sorry. This is some more info: There is only one app that is compiled with
> gcc322. I write this app, since I use a third party library (static linking),
> and it's headers files do not compile with gcc3.4 (huge mess with
> templates) . The rest of the apps are standard ones that come with the
> distro (Mandriva).
> When the two versions of the compiler are installed, I experience the
> problems
> described in the original message. Removing gcc322 ("rm -fr gcc322") solves
> everything, except for the fact that I cannot continue working on my program
> (which is VERY important).
> [tmp]$ env | grep gcc322 | wc -l
> 0
> [tmp]$
>
> I didn't create any symlink to any file in /opt/gcc322
>
> Hope this clarifies the situation
Not enough.
You have a standard install of mandriva.
In addition, you compiled gcc322 with --prefix=pref1.
Up until now, nothing should have changed. Standard binaries continue
to use the standard shared libs, and if you compile an app it will use
the standard compiler and shared libs.
Now you want to compile app1 with gcc322. How do you do this? First, you
need to get to the compiler. You can either run it with the full path,
or add pref1/bin to your path. Any of these will allow compiling, but
not running, and standard binaries should not be affected. To run app1,
you also need to let it find gcc322 shared libs. You have two normal
options: either at link time (-rpath) or at runtime (LD_LIBRARY_PATH). If
you choose the latter, you also affect the standard apps, that will stop
running (because they can't run with gcc322 libs). If you then rm pref1,
app1 won't find its libs anymore, but standard apps will resume working
(as ld.so can't find libs there, and will use standard ones). Am I
describing what happaned? If yes, then you have two options: The easy one,
is to not change path and LD_LIBRARY_PATH globally, but use an alias for
that. Only in shells you run this alias, you can compile/run app1. This
won't work if you need to run both app1 and standard apps from the same
shell. So you can take the "harder" one - add to the gcc link command
-Xlinker -rpath pref1/lib. It's not that harder if you run it yourself,
but if its source downloaded from the net it will require changing some
of its files, as opposed to only changing an envvar. Then this exec will
run also from shells not defining LD_LIBRARY_PATH.
Now, if this does not describe your problem, please give more details.
How do you compile/run your app, env vars you changed, etc.
Maybe you added pref1 to /etc/ld.so.conf and did not tell us?
BTW, all this refers to C++ - C does not have gcc-specific shared libs,
only glibc.
--
Didi
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
