This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A completely different approach to EH runtime


"H . J . Lu" <hjl@valinux.com> writes:

> Say I build a DSO, libfoo.so, with $prefix/bin/gcc. And I do
> 
> 	handle = dlopen ("libfoo.so", ...);
> 
> from an executable, bar, built by /usr/bin/gcc. When I start bar,
> /lib/libgcc_s.so is loaded into memory. Now when dlopen comes, which
> libgcc_s.so should be used by libfoo.so? Since bar has already loaded
> libgcc_s.so from /lib, it won't load $prefix/lib/libgcc_s.so. Now
> libfoo.so is very upset unless /lib/libgcc_s.so is 100% compatible
> with $prefix/lib/libgcc_s.so.

Yes, indeed.  But why are you worrying about this case?

There are two cases:
(1) /lib/libgcc_s.so is compatible with $prefix/lib/libgcc_s.so,
so no problem.  (This is of course what we're hoping for!)
(2) /lib/libgcc_s.so is not compatible with $prefix/lib/libgcc_s.so.
In that case, the problem is using /usr/bin/gcc to compile bar which
is using a library compiled by an incompatible compiler.  Well, don't
do that!

In other words:  This is not a problem for distributors, it is
not a problem for developers using the pre-installed gcc in /usr/bin,
it is not a problem either you or the gcc maintainers should worry about.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]