This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Issues for libtool and/vs egcs (was: Re: can't resolve symbol '__register_frame_info')
On Thu, 4 June 1998, 13:03:59, korbb@datadesign.com wrote:
> Manfred Hollstein wrote:
>
> > To fix the problem, you should
> >
> > 1. Add all directories which contain _your_ private shared libs
> > to LD_RUN_PATH prior to linking your executables, and/or
> > 2. Add a -Wl,-rpath,<dir> for all these directories, or
> > 3. Remove all your own lib*.so files from your private directories.
> >
> > Since I didn't want to use KDE4's libjpeg.so, I removed libjpeg.so
> > (and libgdbm.so) from my private installation directory and re-linked
> > the particular applications; now ImageMagick is running like a charm.
>
> Excuse me? What happened to LD_LIBRARY_PATH?
> Are there *two* ways of specifying the same information?
> Also, for the particular application, I am using :
>
> ltmain.sh (GNU libtool) 1.2
>
> which builds a shared lib for me and a magical shell script that
> is supposed to do the right thing when invoking the uninstalled
> program. So, does libtool need updating to work with egcs?
>
>
Yep, some days ago the libtool maintainer asked about details what
need to be done in this area.
I guess, the main reason for the problems is inconsistent usage of
`-Wl,-rpath,somedir' vs. LD_RUN_PATH; AFAIK, `-Wl,-rpath,...' disables
LD_RUN_PATH at linktime and LD_LIBRARY_PATH at runtime.
I don't know, which way libtool is using, but I tend to strongly
recommend against using -Wl,-rpath.
Other thoughts?
manfred